キャッシュの人気のポイントは、取得した「もの」をできるだけ近い場所に保存し、次回必要なときに失われることです。スタート地点（遠い場所）まで2回走って取りに行くのではなく、近くで解けるので時間の短縮とお金の節約になります（バスに乗るとお金がかかります）。率直に言うと、Web キャッシュも同じことです。Web サイトに初めてアクセスすると、HTML ページ、画像、JavaScript ファイルなどの表現が、アクセスしたときの近くの場所に保存されます。次回必要になったときに、オリジン サーバーにアクセスして入手する必要はありません。そうすれば、Web キャッシュの利点は明らかです:
1. ネットワーク遅延を削減し、ページの応答速度を高速化し、ユーザー エクスペリエンスを向上させます。 (近くで取得するので、距離が短くなりますので、遠くのサーバーから取得するよりも当然応答速度が速くなります)
2.ネットワーク帯域幅の消費を削減します。 (近くで入手してください);
3. キャッシュにより、リクエストのためにサーバー (オリジンサーバー) に行く必要がなくなり、それに応じてサーバーへの負荷が軽減されます。
それでは、Web キャッシュはこれらのものをどこに置くのでしょうか?次に、どこにキャッシュを配置すればよいかを理解するために、どのような種類のキャッシュがあるのかを見ていきます。
--データベース キャッシュ--:
Web アプリケーションの関係が複雑でデータ テーブルが増大する場合、クエリされたデータはキャッシュに入れられる可能性があります。メモリに保存され、次回クエリを実行するときにメモリ キャッシュから直接取得されるため、応答速度が向上します。
--CDN キャッシュ--:
CDN とは、簡単に言うと、Web リクエストを送信するときに最初にそれを通過し、次にこれらの表現を取得するパスと場所を計算するのに役立ちます。パスは短くて速いです。これは Web サイト管理者によって展開されるため、ユーザーが頻繁にアクセスする表現を CDN に配置して、応答を迅速化することもできます。
--プロキシ サーバー キャッシュ--:
プロキシ サーバー キャッシュは、実際には以下で説明するブラウザ キャッシュと性質が似ていますが、違いは、プロキシ サーバー キャッシュがより幅広い人々をターゲットにしており、規模が大きいことです。 。つまり、1 人のユーザーにサービスを提供するだけでなく、通常、同じコピーが複数回再利用されるため、応答時間と帯域幅の使用量を削減するのに非常に効果的です。
-- ブラウザ キャッシュ --:
つまり、すべてのブラウザは HTTP キャッシュを実装しており、ブラウザを通じて HTTP プロトコルを使用してサーバーと通信するとき、ブラウザは合意されたルールに従ってキャッシュ作業を実行します。サーバ。これは、ブラウザの「戻る」または「進む」ボタンをクリックするときに特に便利です。
| 3. Web キャッシュ実行メカニズム |
いわゆるメカニズムとは、いつ何かを行うべきかを相手方に明確に伝える、二者間の合意です。 Web キャッシュについても同様です。いつキャッシュにアクセスして表現を取得するか、いつサーバーにアクセスして表現を取得するかを (リクエストに) 伝える必要があります。したがって、Web キャッシュ メカニズムは、http プロトコル (HTTP1.0 および HTTP1.1) と Web サイト管理者によって開発されたプロトコルの 2 つの部分に分かれています。 Web サイト内で策定されているプロトコルはさておき、http プロトコルで定義されているキャッシュ メカニズムを見てみましょう。
ところで、次のように HTML ドキュメントの 7af74544a289f1386ae1ecc80e4cef5e を介してキャッシュすることができます:
<meta http-equiv="Pragma" content="no-cache"/>
ただし、これは一部のブラウザでのみ使用でき、プロキシ サーバーは使用できません。ゆっくりしてください。 (メタは HTML 内にあるため、プロキシ サーバーはメタを読み戻すことはほとんどありません)。
--http キャッシュ メカニズム--
1. Expires
http キャッシュ メカニズムは、主に http 応答ヘッダーで設定されます。応答ヘッダーの関連フィールドは、Expires、Cache-Control、Last-です。変更済み、変更後、Etag。
HTTP 1.0 プロトコル。つまり、サーバーにアクセスしてリソース (表現) を取得することなく、合意された時間の前にキャッシュからリソース (表現) を直接取得できることをブラウザーに伝えます。
もう 1 つ: Expires は時間に設定されており、その時間は現地時間ではなくグリニッジ標準時 (GMT) であるため、時間要件は高くなります。
2. キャッシュ制御
HTTP1.1 プロトコルでは、上記の Expires を無視できます。 Cache-Control は Expires よりも具体的かつ詳細であるためです。
そして、 Cache-Control と Expires が同時に設定されている場合でも、Cache-Control の方が Expires よりも優先されます。
Cache-Control 応答ヘッダーの一般的なフィールドの具体的な意味を見てみましょう:
(1)、max-age: リソース (表現) をキャッシュできる期間を秒単位で設定するために使用されます。 2)、s-maxage: max-age と同じですが、プロキシ サーバーのキャッシュ専用です。
(3)、public: 応答を任意のキャッシュ領域にキャッシュできることを示します。 , private : 個々のユーザーのみを対象とし、プロキシ サーバーによってキャッシュすることはできません
(5)、no-cache : クライアントにリクエストを直接サーバーに送信するように強制します。つまり、各リクエストをサーバーに送信する必要があります。 。サーバーはリクエストを受信し、リソースが変更されたかどうかを判断し、変更されている場合は新しいコンテンツを返し、変更されていない場合は 304 を返します。これは誤解を招きやすく、応答がキャッシュされていないと誤解される可能性があります。実際、Cache-Control: no-cache はキャッシュされますが、応答データがクライアント (ブラウザー) に提供されるたびに、キャッシュはサーバーへのキャッシュされた応答の有効性を評価する必要があります。
(6)、no-store: すべてのキャッシュを無効にします (これは、応答がキャッシュされないことを意味します)。
3. Etag と If-None-Match
Etag は、サーバーによって生成され、初めて HTTP リクエストを開始するときにバックエンドに返されます。 Etag と同じリクエストを再度開始すると、クライアント サーバーも If-None-Match を送信し、その内容が Etag の値になります。最後に、サーバーはクライアントから送信された Etag がサーバーの Etag と同じであるかどうかを比較します。同じである場合、If-None-Match の値は false となり、ローカル キャッシュの使用を継続するために 304 が返されます。それ以外の場合は 200 が返されます。率直に言うと、Etag はサーバーによって生成される単なるタグです。また、Etag の優先度は Last-Modified よりも高くなります。
4. Last-Modified & If-Modified-since
Last-Modified は Etag に似ています。ただし、Last-Modified は、応答リソースがサーバー上で最後に変更されたことを示します。 Etag と比較すると、欠点は次のとおりです。 (1) Last-Modified アノテーションの最後の変更は、第 2 レベルまでしか正確ではありません。一部のファイルが 1 秒以内に複数回変更された場合、そのファイルに正確にラベルを付けることができません。ファイルの変更時刻;
(2) 定期的にファイルが生成される場合、内容は変更されない場合がありますが、その結果、ファイルはキャッシュを使用できなくなります。サーバーがファイル変更時刻を正確に取得できない場合や、時刻がプロキシ サーバーの時刻と一致しない場合があります。
しかし、Etagはサーバーが自動生成、あるいは開発者が生成するサーバー側の対応するリソースの一意な識別子であり、より正確にキャッシュを制御することができます。
IV. 詳細な読書
