序文：

ウェブ上の一部のシナリオでは、多くのコンテンツを変更する必要はありません。すべてのリクエストが一定期間変更されないコンテンツデータをリクエストすると、帯域幅が無駄に消費されます。

ネットワークが貧弱な場合、コンテンツを要求してページを開くのに時間がかかることがあります。

したがって、協調サーバーは、ブラウザのキャッシュメカニズムを通じて、頻繁に変更する必要のないリソースをブラウザでキャッシュして、トラフィックの消費と応答時間を効果的に削減できます。

1. httpキャッシュとは

HTTPキャッシュとは：クライアントがサーバーにリソースをリクエストすると、最初にブラウザーキャッシュをチェックします。ブラウザーに「リクエストリソース」のコピーがある場合、サーバーからの必要なしにブラウザーキャッシュから直接抽出できます。このリソースをリクエストします。

共通のHTTPキャッシュはGET要求リソースのみをキャッシュできるため、次の要求キャッシュはGET要求を指すことに注意してください。

HTTPキャッシュの分類：リクエストがサーバーに対して行われたかどうかに基づいて、HTTPキャッシュを2つのカテゴリ、強力なキャッシュとネゴシエートされたキャッシュに分類します。

httpキャッシュは2番目のリクエストから開始されます。

初めてリソースを要求するとき、クライアントはサーバーにリソースを要求し、サーバーは応答リソースを返し、リソースのキャッシュパラメーターを応答ヘッダーに返します。

2回目にリソースをリクエストすると、ブラウザはこれらのリクエストパラメータを判断して強力なキャッシュにヒットし、200を返します。ディスクキャッシュ内のリソースを使用し、サーバーにはリクエストしません。それ以外の場合、リクエストパラメータはリクエストヘッダーに追加され、サーバーに渡されて、ネゴシエーションにヒットしたかどうかを確認します。キャッシュ、リターン304をヒット、キャッシュリソースを使用、ヒットがない場合、サーバーは新しいリソースを返します。

2、強力なキャッシュ

強力なキャッシュとは、キャッシュの有効期限 expires または有効時間 max-age を設定することです。有効時間内では、キャッシュは無効にならず、ブラウザはブラウザキャッシュから直接リソースを読み取ります。要求されたリソースがキャッシュデータベースにない場合、または要求されたリソースが無効な場合、リソースはサーバーからのみ要求されます。

必須キャッシングに関連するリクエストレスポンスヘッダー：

期限切れ

応答ヘッダーは、リソースの有効期限を表します。ただし、サーバー時間とクライアント時間の間に差異がある可能性があるため、キャッシュヒットでエラーが発生する可能性もあります。一方、ExpiresはHTTP1.0の製品であるため、ほとんどの場合、代わりにCache-Controlを使用します。

キャッシュ制御（期限よりも優先度が高い）

要求/応答ヘッダー、キャッシュ制御フィールド、キャッシュ戦略の正確な制御。Cache-Controlには多くの属性があり、異なる属性には異なる意味があります。

プライベート：クライアントはキャッシュできます

public：クライアントとプロキシサーバーの両方がキャッシュできます

max-age = x：キャッシュコンテンツはx秒後に期限切れになります

no-cache：キャッシュされたデータを検証するには、ネゴシエートされたキャッシュが必要です

no-store：すべてのコンテンツはキャッシュされません

プラグマ

その値はno-cacheおよびno-storeです。つまり、cacha-controlと同じであり、cache-controlよりも優先度が高く、期限が切れます。つまり、3つが同時に表示される場合は、最初にpragma-> cache-control->が期限切れになります。

3.交渉キャッシュ

キャッシュのネゴシエーションでは、サーバー側でリソースが変更されているかどうかを比較して、キャッシュを使用できるかどうかを判断する必要があります。変更がない場合は、304ステータスコードが返され、ブラウザはステータスコードを取得して、キャッシュされたデータを直接使用できます。それ以外の場合、サーバーは新しいリソースを返します。

ネゴシエーションキャッシュでは、リソースが変更されたかどうかを判断する方法が特に重要であることがわかります。現在、Last-Modified と Etagの 2つの主な戦略があります。

最終更新日

サーバーが要求に応答すると、リソースの最終変更時刻がGMT形式でブラウザーに通知されます。

ブラウザが初めてサーバーを要求しない場合、要求ヘッダーにはif-Modified-Sinceフィールドが含まれ、その後にキャッシュで取得された最終変更時間が続きます。サーバーがこのリクエストを受信すると、既存のif-Modified-Sinceがリクエストされたリソースの最終変更時刻と比較され、一致する場合は304と応答パケットヘッダーが返されます。ええ

それが実際に変更された場合：送信応答が全体として開始すると、サーバーは200 OKを返します。

変更されていない場合：応答ヘッダーのみを送信する必要があり、サーバーは次を返します：304 Not Modified

Last-Modifiedは、実際には必ずしも完全に正確であるとは限りません。

Last-Modifiedの最終変更は、2番目のレベルまでしか正確ではありません。ファイルが1秒以内に複数回変更された場合、ファイルの変更時刻を正確にマークすることはできません

一部のファイルは変更されているが、内容は変更されていないが、Last-Modifiedが変更されているため、ファイルはキャッシュを使用できない

サーバーがファイルの変更時刻を正確に取得していない、またはプロキシサーバーの時刻と一致していない場合があります。

したがって、HTTP 1.1はこれらの問題を改善するためにEtagを導入しました。

Etag（Last-Modifiedよりも優先度が高い）

サーバーがリクエストに応答すると、このフィールドを介してサーバーによって生成された現在のリソースの一意の識別子をブラウザーに通知します（生成ルールはサーバーによって決定されます）。

サーバーが初めて要求されない場合、ブラウザーの要求ヘッダーにはIf-None-Match フィールドが含まれ、次の値はキャッシュで取得された識別子です。このメッセージを受信した後、サーバーはIf-None-Matchの 値を要求されたリソースの一意の識別子と比較します。

異なる場合は、リソースが変更され、ステータスコード200が返され、サーバーは新しいリソースを返します。

同じで、リソースが変更されていないことを示し、ステータスコード304が返され、ブラウザはデータリソースをキャッシュから直接取得します。

ただし、etagには欠点もあります。つまり、式文字列が生成されるたびに、サーバーのオーバーヘッドが増加します。したがって、最終変更とetagの使用方法も、特定のニーズに応じて検討する必要があります。

第四に、実践

さて、理論の部分は終了しました。実際に試してみましょう

nodejsを使用してサーバーを開き、getリクエストの応答を取得し、httpキャッシュの関連属性を設定しました。Webページの部分は、単純な読み込みイメージです。初心者のnodejs書き込みインターフェイスは、キャッシュする方法を理解するためだけに、完全ではありません参照用にのみ使用してください。

強力なキャッシュ：

nodejsのgetリクエスト部分のコード：

app.get("/api/getPic", (req, res) => {
  res.setHeader("Cache-Control", "public,max-age=120");  //max-age设置的2分钟
  let date = new Date(Date.now() + 5000).toUTCString(); //Expires过期时间设置了5分钟后
  res.setHeader("Expires", date);
  let data = JSON.stringify({
    msg: "请求成功",
    result: [
      {
        url:
          "https://ss3.bdstatic.com/70cFv8Sh_Q1YnxGkpoWK1HF6hhy/it/u=350525183,1430160676&fm=11&gp=0.jpg"
      }
    ]
  });
  res.send(data);
});

リクエストを送信すると、強力なキャッシュの設定がセットアップされていることがわかります（デフォルトは、ネゴシエーションキャッシュのetagですが、理由はわかりません...）：

ページを更新した直後は、この時点で紫色のソースになり、ステータスコードは200で、ディスクキャッシュからは背面に表示され、このときの画像リソースはサーバーに要求せずにディスクキャッシュから取得されます。

2分後、ページは再び更新されます。この時点で、ステータスコードは304、つまり要求されたサーバー、要求されたリソースは変更されておらず、ネゴシエートされたキャッシュヒットを示しています。

Etagネゴシエーションキャッシュはデフォルトで提供されるため、ネゴシエーションキャッシュに手書きはありません。関係するパートナーは、Last-ModifiedおよびEtag属性値を設定するための独自の設定を書き込むことができます。

補足：

ネットワーク要求のサイズには3つの状況があります

メモリキャッシュから

ディスクキャッシュから

リソースのサイズ

値を示すステータスコードは200で、サーバーから最新のリソースを直接ダウンロードします

メモリキャッシュからはネットワークリソースを要求せず、リソースはメモリ内にあり、一般的なjsスクリプト、フォント、画像はメモリに保存されます

ディスクキャッシュからはネットワークリソースを要求しません。ディスクでは、通常、非スクリプトがcssなどのメモリに格納されます。