nginxのリソースキャッシュ設定の詳細な説明

私はずっとキャッシュについて学びたいと思っていました。結局のところ、キャッシュはフロントエンドのパフォーマンス最適化に大きな役割を果たします。キャッシュには、必須キャッシュとネゴシエートされたキャッシュの 2 種類があります。それらの違いについての記事をたくさん読んだことがありますが、実際に使ったことはありません。意味は知っているものの、設定方法がわかりません。実践経験が不足しているため、記憶も曖昧になっています。練習は最高の教師です！ nginx サーバーを使用してキャッシュを学習するプロセスを記録します。

予備調査

まず、 nginxのルートディレクトリに新しいindex.htmlファイルとindex.jsファイルを作成しました。この時点で、 nginx構成ファイルは次のようになります。

サーバー{
 8080を聴く;
 server_name ローカルホスト;
 位置 / {
  ルート /Volumes/myFile/nginx_root; 
  インデックス index.html index.htm;
 }
}

次にブラウザを開いて localhost:8080 にアクセスします。コンソールを開いて、次の 2 つのリクエストを見つけます。

最初のアクセスでは、両方のリクエストのステータスコードが 200 であることがわかります。リクエストの 1 つをクリックして、応答ヘッダー情報を確認してみましょう。

ご覧のとおり、応答ヘッダーにはEtagとLast-Modified情報が含まれています。これはネゴシエーションキャッシュによって使用されるフィールドです。 nginx はデフォルトでキャッシュを使用しているようです。次に、HTML ファイルと JS ファイルを変更せずにページを再度更新して検証します。ネゴシエーションキャッシュにヒットした場合、ステータスコードとして304 Not Modified返されます。 http リクエストのステータスコードを観察するために、数回更新しました。 HTML ファイルは毎回 304 を返します。しかし、js ファイルは最初は 304 でしたが、後で200 OK (from memory cache)になりました。つまり、HTML ファイルがネゴシエーションキャッシュにヒットするたびに、JS ファイルは強力なキャッシュにヒットします (強力なキャッシュの優先度はネゴシエーションキャッシュよりも高くなります)。なぜこのようなことが起こるのでしょうか? Baidu で検索しました:

一部のキャッシュでは 200 OK (キャッシュから) と表示され、他のキャッシュでは 304 Not Modified と表示されるのはなぜですか?とても簡単です。エンティティタグが削除されているかどうかを確認するだけです。削除された場合、常に 200 OK (キャッシュから) になります。削除しないと、2 つが交互に表示されます。

では、2 つのトリガーのタイミングの違いは何でしょうか? 200 OK (キャッシュから) は、リンクを直接クリックするか、URL を入力して Enter キーを押すことによってトリガーされます。304 Not Modified は、ページが更新されたとき、または強力なキャッシュが設定されているがエンティティタグが削除されていない場合にトリガーされます。

私の例とは対照的に、私は次のように理解していますindex.htmlファイルはページを更新し、ネゴシエーションキャッシュにヒットして 304 を返しますが、js ファイルは index.html ファイル内でリンクされているため、強力なキャッシュ 200 OK (キャッシュから) にヒットします。私の考えを検証するために、アドレスバーを使用してindex.jsファイルに直接アクセスしました。アドレスバーに「localhost:8080/index.js」と入力します。304 が返されます。この時点でのリクエストヘッダーを見てみましょう。

この時点でCache-Control max-age=0 を指定し、ネゴシエートされたキャッシュの関連パラメータも伝送していることがわかります。ブラウザを更新するときに、強力なキャッシュにヒットしないようにCache-Control:max-age=0実行するようです。

nginx 強力なキャッシュを無効にする

nginxで強力なキャッシュを無効にした後に何が起こるか見てみましょう。 nginx設定ファイルを変更します。

サーバー{
 8080を聴く;
 server_name ローカルホスト;
 位置 / {
  ルート /Volumes/myFile/nginx_root; 
  インデックス index.html index.htm;
  add_header Cache-Control no-cache;
  # public は任意のオブジェクトによってキャッシュできますが、private は個々のユーザーによってのみキャッシュでき、プロキシ サーバーによってキャッシュすることはできません。add_header Cache-Control private;
 }
}

nginx設定ファイルを変更した後、 nginxサーバーを再起動します。この時点で、localhost:8080にアクセスしてください。

ご覧のとおり、この時点では HTML ファイルと JS ファイルの両方が 304 であり、両方ともネゴシエーションキャッシュにヒットしています。

キャッシュ制御:保存なし

すべてのキャッシュを無効にします (つまり、応答はキャッシュされません)。キャッシュは通常、非キャッシュプロキシサーバーのように動作し、クライアントに no-store 応答を転送してからオブジェクトを削除します。

キャッシュ制御: キャッシュなし

クライアントがサーバーに直接リクエストを送信するように強制します。つまり、各リクエストはサーバーに送信されなければなりません。サーバーはリクエストを受信し、リソースが変更されたかどうかを判断します。変更された場合は、新しいコンテンツを返します。変更されていない場合は、リソースが変更されていないことを示す 304 を返します。これは簡単に誤解を招き、応答がキャッシュされていないと人々に信じ込ませる可能性があります。実際、Cache-Control: no-cache はキャッシュされますが、応答データがクライアント (ブラウザ) に提供されるたびに、キャッシュはサーバーからのキャッシュされた応答の有効性を評価する必要があります。

実際、 Cache-Controlをno-storeに設定すると、キャッシュされないという本当の意味になります。次に、 nginxファイルを変更し、 Cache-Controlをno-storeに設定して、何が起こるかを確認します。この時点でブラウザを再度更新してください。

nginx構成ファイルを変更した後、最初の 304 を除いて (今回はブラウザが no-store 情報を受信しただけで、リクエストヘッダーにはキャッシュ関連の情報がまだ含まれていた)、残りの数回のページ更新ではすべて 200 が返されたことがわかります。強力なキャッシュもネゴシエーションキャッシュもヒットしません。 index.jsファイルの http ヘッダー情報を見てみましょう。

ここでは全体像を捉えていません。実際、レスポンスヘッダーにはCache-Control: no-storeも含まれています。 Cache-Control: no-storeのサポートにより、サービスがレスポンスヘッダーでネゴシエーションキャッシュパラメータを返しても、ブラウザはリソースを要求するときにキャッシュ関連のパラメータを持ち込まないことがわかります。したがって、現在はキャッシュが存在せず、強力なキャッシュもネゴシエーションキャッシュもヒットしません。各 http リクエストのリソースはサーバーから返されます。

結論

この探索はこれで終わりです。実はこれは私の学習の記録にすぎません。一度練習すると、キャッシュに対する理解と認識がより明確になります。練習すれば完璧になるというのは本当です。後日、React.js や Vue.js などのフレームワークを使用してフロントエンドをパッケージ化した後、 nginxを使用してフロントエンドリソースをデプロイし、関連するキャッシュを構成する方法について記事を書く予定です。そのときに記録しておく意味があるかどうかを確認します。

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。

以下もご興味があるかもしれません: