HTTP キャッシュメカニズムの詳細(xì)な説明

HTTP キャッシュは、サーバーの負(fù)荷を軽減し、クライアントの応答を高速化し、ネットワーク帯域幅を節(jié)約することにより、Web ページのパフォーマンスを向上させるテクノロジーです。 HTTP キャッシュは主に、強(qiáng)制キャッシュ と ネゴシエート キャッシュ の 2 つのタイプに分類されます。

強(qiáng)制キャッシュ

強(qiáng)制キャッシュを使用すると、クライアントはサーバーにリクエストを送信せずに、指定された期間內(nèi)でローカルにキャッシュされたリソースを直接使用できます。強(qiáng)制キャッシュは、主に Cache-Control と Expires の 2 つのフィールドを通じて、サーバーによって指定された応答ヘッダーによって制御されます。

キャッシュ制御

Cache-Control は、リソースの最大有効期間 (max-age)、キャッシュを共有できるかどうか (パブリックまたはプライベート)、および変更が許可されるかどうか (no-age) を指定する一般的なヘッダーです。キャッシュまたは -store なし)。

例:

<code>Cache-Control: max-age=3600</code>

上記は、リソースが 3600 秒間有効であり、キャッシュできることを意味します。

期限切れ

Expires は、キャッシュの絶対有効期限を指定する非推奨のフィールドです。

例:

<code>Expires: Wed, 23 Aug 2024 03:36:26 GMT</code>

これは、リソースが 2024 年 8 月 23 日の午前 3:36:26 に期限切れになることを意味します。

Cache-Control と Expires の両方が存在する場(chǎng)合は、Cache-Control が優(yōu)先されます。

ネゴシエーションキャッシュ

キャッシュのネゴシエーションでは、クライアントはリクエストごとにサーバー リソースが更新されたかどうかを確認(rèn)する必要があります。更新されない場(chǎng)合、サーバーは 304 ステータス コードと空の応答本文を返し、クライアントはローカル キャッシュを使用し続けることができます。更新されると、サーバーはステータス コード 200 と新しいリソースを返し、ローカル キャッシュを置き換えます。キャッシュのネゴシエーションには、サーバーとクライアントのヘッダー、主に Last-Modified/If-Modified-Since と ETag/If-None-Match が関係します。

最終変更日/変更日以降

Last-Modified は、リソースの最終変更時(shí)刻を示すサーバー側(cè)のフィールドです。例:

<code>Last-Modified: Tue, 22 Aug 2024 02:36:26 GMT</code>

これは、リソースが最後に変更されたのが 2024 年 8 月 22 日の午前 2:36:26 であることを意味します。

If-Modified-Since は、リソースが最後に取得された時(shí)間を示すクライアント側(cè)のフィールドです。例:

<code>If-Modified-Since: Tue, 22 Aug 2024 02:36:26 GMT</code>

これは、クライアントが 2024 年 8 月 22 日の午前 2 時(shí) 36 分 26 秒にリソースを取得したことを意味します。

2 つのタイムスタンプが等しい場(chǎng)合、または Last-Modified の方が早い場(chǎng)合、リソースは更新されません。 Last-Modified が後の場(chǎng)合、リソースは更新されています。

ETag/一致しない場(chǎng)合

ETag は、リソースの一意の識(shí)別子を表すサーバー側(cè)のフィールドです。例:

<code>ETag: '5d3a9f6d-1f86'</code>

これは、リソースの識(shí)別子が「5d3a9f6d-1f86」であることを意味します。

If-None-Match は、リソースの予期される識(shí)別子を示すクライアント側(cè)のフィールドです。例:

<code>If-None-Match: '5d3a9f6d-1f86'</code>

これは、クライアントが「5d3a9f6d-1f86」というリソース識(shí)別子を期待していることを意味します。

2 つの値が一致する場(chǎng)合、リソースは更新されません。それらが異なる場(chǎng)合、リソースは更新されています。

HTTP キャッシュのベスト プラクティス

ネゴシエートされたキャッシュと強(qiáng)制キャッシュを組み合わせると、ユーザーが常に最新のコンテンツを利用できるようにしながら、不要なネットワーク要求を効果的に削減できます。

一般的な方法:

強(qiáng)制キャッシュ: 靜的リソース (CSS、JS、畫像など) の場(chǎng)合、キャッシュ期間を長く設(shè)定します。これにより、ブラウザはサーバーに接続せずにローカル ストレージからリソースを直接取得できるようになります。

ネゴシエーション キャッシュ: 変更される可能性のあるリソースについては、ネゴシエーション キャッシュを使用します。ブラウザは、リソースが変更されたかどうかを確認(rèn)するリクエストを送信します。そうでない場(chǎng)合、サーバーは 304 Not Modified 応答を返し、ブラウザがローカル キャッシュを使用できるようにします。リソースが変更された場(chǎng)合、サーバーは 200 OK と更新されたリソースを返します。

実裝例:

Express.js をバックエンド フレームワークとして使用するとします。

<code>Cache-Control: max-age=3600</code>

重要な考慮事項(xiàng)

• バージョニング: 強(qiáng)制キャッシュの効果を最大限に高めるには、リソース URL にバージョン情報(bào) (/static/js/main.2024082301.js など) を含めます。リソースが更新された場(chǎng)合は、ユーザーが常に最新バージョンを取得できるようにバージョン番號(hào)を変更します。
• ネゴシエーション キャッシュのコスト: ネゴシエーション キャッシュにより不必要なデータ転送が削減されますが、それでもネットワークの往復(fù)が必要になります。めったに変更されないリソースの場(chǎng)合は、キャッシュを強(qiáng)制する方が効率的である可能性があります。

Leapcell: バックエンド プロジェクトをホストするための最良の選択

Leapcell は、Web ホスティング、非同期タスク、Redis 用の新世代サーバーレス プラットフォームです:

多言語サポート

• Node.js、Python、Go、または Rust を使用して開発します。

無制限のプロジェクトを無料でデプロイ

• 使用した分だけお支払いください - リクエストや手?jǐn)?shù)料はかかりません。

比類のない費(fèi)用対効果

• 従量課金制で、非アクティブ料金はかかりません。
• 例: 25 ドルは、平均応答時(shí)間 60 ミリ秒で 694 萬件のリクエストをサポートします。

簡素化された開発者エクスペリエンス

• 直感的な UI、セットアップが簡単。
• 完全に自動(dòng)化された CI/CD パイプラインと GitOps の統(tǒng)合。
• 実用的な洞察を得るリアルタイムのメトリクスとログ。

簡単な拡張性と高いパフォーマンス

• 自動(dòng)スケーリングにより、高い同時(shí)実行性を簡単に処理できます。
• 運(yùn)用上のオーバーヘッドがゼロ - 構(gòu)築だけに集中します。

詳しくはドキュメントをご覧ください。

X でフォローしてください: @LeapcellHQ

ブログを読む

以上がHTTP キャッシュ: 知っておくべきことすべての詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國語 Web サイトの他の関連記事を參照してください。