🎹 🆘 👓 nginxでキャッシュを使用する場合の落とし穴 👨🏽‍🔬 🌻 🕕

Webサーバーとリバースプロキシnginxには、HTTP応答をキャッシュするための非常に強力な機能があります。ただし、場合によっては、ドキュメントと例では不十分であり、その結果、すべてが私たちが望むほど簡単で単純ではないことがあります。たとえば、nginxの設定は、血のある場所に書き込まれます。この記事では、状況を少し改善しようとします。

この記事の内容：a）全ページキャッシュの落とし穴。 b）ローテーションを伴うキャッシュ。 c）キャッシュされたページに動的な「ウィンドウ」を作成します。

nginx + fastcgi_phpバンドルを使用していると仮定します。 nginx + apache + mod_phpを使用している場合、ディレクティブ名をfastcgi_cache *とproxy_cache *に置き換えるだけです

ページをPHP側でキャッシュするかnginx側でキャッシュするかを選択する場合、nginxを選択します。まず、難なく、「高負荷」についてスマートに話すことなく、1秒あたり5〜1万件のリクエストを送信できます。第二に、nginxはキャッシュのサイズを個別に監視し、陳腐化した場合と、使用頻度の低いデータを混雑させた場合の両方でキャッシュを消去します。

ページ全体のキャッシュ

サイトのメインページが動的に生成されてもめったに変更されない場合、nginxにキャッシュすることでサーバーの負荷を大幅に減らすことができます。トラフィックが多い場合、キャッシュが非常に高速に動作するため、短期的なキャッシング（5分以下）でもパフォーマンスが大幅に向上します。ページを30秒だけキャッシュした後でも、データを更新するダイナミズムを維持しながら、サーバーの大幅なオフロードを実現できます（多くの場合、30秒に1回更新するだけで十分です）。

たとえば、次のようにメインページをキャッシュできます。

 fastcgi_cache_path / var / cache / nginx levels = keys_zone = wholepage：50m;
 ...
サーバー{
   ...
  場所/ {
     ...
     fastcgi_pass 127.0.0.1:9000;
     ...
     ＃キャッシュをオンにして、キャッシュキーを慎重に選択します。
     fastcgi_cache wholepage;
     fastcgi_cache_valid 200 301 302 304 5m;
     fastcgi_cache_key "$ request_method | $ http_if_modified_since | $ http_if_none_match | $ host | $ request_uri";
     ＃異なるユーザーが同じセッションCookieを受け取らないことを保証します。
     fastcgi_hide_header "Set-Cookie";
     ＃とにかく、nginxにページをキャッシュさせる
     ＃PHPで公開されるヘッダーをキャッシュします。
     fastcgi_ignore_headers "Cache-Control" "Expires";
   }
 }

この設定のすべての行が血で書かれていると言っても、私は大げさには誇張しません。ここには多くの落とし穴があります。それらすべてを見てみましょう。

fastcgi_cache_path：デバッグの容易さも重要です

fastcgi_cache_path / var / cache / nginx levels = keys_zone = wholepage：50m;

fastcgi_cache_pathディレクティブで、レベルの「空の」値を設定します。これによりパフォーマンスがわずかに低下しますが（ファイルはディレクトリに分割せずに/ var / cache / nginxに直接作成されます）、キャッシュの問題をデバッグおよび診断するのがはるかに簡単です。私を信じて、あなたは/ var / cache / nginxに登り、そこに何回保存されているかを見なければならないでしょう。

fastcgi_cache_valid：応答コード304もキャッシュする

fastcgi_cache_valid 200 301 302 304 5m;

fastcgi_cache_validディレクティブでは、標準コード200 OK、301 Moved Permanently、302 Foundだけでなく、304 Not Modifiedも強制的にキャッシュします。なんで？ 304の意味を思い出しましょう。これは、2つの場合に空の応答本文で発行されます。

ブラウザが「If-Modified-Since：date」ヘッダーを送信した場合、日付は「Last-Modified：date」応答ヘッダーの値以上です。つまりクライアントは次のように尋ねます。「これから新しいバージョンはありますか？そうでない場合は、304を返してトラフィックを節約します。あれば、ページの本文を教えてください。
ブラウザが「If-None-Match：hash」ヘッダーを送信した場合、ハッシュは応答ヘッダー値「ETag：hash」と一致します。つまりクライアントは次のように尋ねます。「ページの現在のバージョンは、前回リクエストしたものと異なりますか？そうでない場合は、304を返してトラフィックを節約します。もしそうなら、ページの本文を教えてください。

どちらの場合も、Last-ModifiedまたはETagはnginxキャッシュから取得される可能性が高く、検証は非常に高速です。特に200の応答を受け取るクライアントにキャッシュから返されるという事実に照らして、スクリプトにこれらのヘッダーを表示させるためだけにPHPを「プル」する必要はありません。

fastcgi_cache_key：依存関係を慎重に扱う

fastcgi_cache_key "$ request_method | $ http_if_modified_since | $ http_if_none_match | $ host | $ request_uri";

特に注目すべきは、fastcgi_cache_keyディレクティブの値です。このディレクティブの最小作業値を指定しました。右側のステップ、左側のステップ。場合によっては、キャッシュから「誤った」データを受信し始めます。だから：

必要な$ request_methodへの依存インターネットでのHEADリクエストは非常に一般的です。 HEADリクエストへの応答にボディが含まれることはありません。 $ request_methodの依存関係を削除すると、HEADメソッドを使用してメインページを要求する前に誰かがGETで空のコンテンツを取得する可能性があります。
$ http_if_modified_sinceへの依存性は、304 Not Modifiedレスポンスを持つキャッシュが、通常のGETリクエストを行うクライアントに誤って与えられないようにするために必要です。そうしないと、クライアントはキャッシュから空の応答を受け取る場合があります。
$ http_if_none_matchでも同じです。空白のページを顧客に提供しないように保証する必要があります！
最後に、$ hostおよび$ request_uriへの依存関係にはコメントは不要です。

fastcgi_hide_header：セキュリティ問題の解決

fastcgi_hide_header "Set-Cookie";

fastcgi_hide_headerディレクティブは非常に重要です。これがないと、セキュリティ上の重大なリスクが発生します。ユーザーはキャッシュ内のセッションCookieを通じて他のユーザーのセッションを取得できます。（確かに、nginxの最新バージョンでは、この要因を自動的に考慮するために何かが行われました。）これがどのように起こるか理解していますか？ Vasya Pupkinはサイトにアクセスし、セッションとセッションCookieを受け取りました。その時点でキャッシュを空にすると、Vasina Cookieがキャッシュに書き込まれます。その後、別のユーザーが来て、キャッシュから応答を受け取り、その中にVasyaのCookieが入りました。それは彼のセッションも意味します。

もちろん、次のように言うことができます。メインページでsession_start（）を呼び出さないようにすれば、Cookieに問題はありません。 理論的にはこれは真実ですが、実際にはこの方法は非常に不安定です。 多くの場合、セッションは「延期」されて開始され、セキュリティホールが発生するため、コードのどの部分でもセッションへのアクセスを必要とする関数を「誤って」呼び出すだけで十分です。 また、セキュリティは、特定の手法の過失が原因でホールが発生する可能性がある場合、その手法は定義上「漏れやすい」と見なされます。 さらに、セッションCookieを除く他のCookieがあります。 また、キャッシュに書き込む必要もありません。

fastcgi_ignore_headers：タイプミス中にサイトを負荷から「横に」させない

fastcgi_ignore_headers "Cache-Control" "Expires";

nginxサーバーは、PHPが生成するCache-Control、Expires、およびPragmaヘッダーに注意を払います。ページをキャッシュする必要がない（または既に古くなっている）と言われた場合、nginxはキャッシュファイルに書き込みません。この動作は、論理的に思えますが、実際には多くの困難を引き起こします。したがって、ブロックします。fastcgi_ignore_headersのおかげで、見出しに関係なく、ページのコンテンツはキャッシュファイルに保存されます。

これらの困難は何ですか？これらは再びセッションとsession_start（）関数に関連付けられます。これは、PHPでデフォルトでヘッダー「Cache-Control：no-cache」と「Pragma：no-cache」を設定します。この問題には3つの解決策があります。

キャッシングが想定されているページでsession_start（）を使用しないでください。既に上で検討したこの方法の欠点の1つは、不注意な動きが1回あれば十分であり、キャッシュされたメインページへの1秒あたり数千のリクエストを受け取るサイトが、キャッシュがオフになると即座に「横たわる」ことです。 2番目のマイナス-2つの場所でキャッシュロジックを管理する必要があります：nginx構成とPHPコード。つまりこのロジックは、システムのまったく異なる部分に「広がり」ます。
ini_set（ 'session.cache_limiter'、 ''）を設定します。これにより、セッションでの作業時にキャッシュを制限するヘッダーの出力をPHPで強制的に防止できます。ここでの問題は同じです。「ぼやけた」キャッシングロジック。理想的には、すべてのキャッシングを1か所から管理したいからです。
fastcgi_ignore_headersを使用してキャッシュファイルに書き込む場合、キャッシュ禁止ヘッダーを無視します。これは、Win-Winのソリューションであると思われるため、これをお勧めします。

ロータリーキャッシング

静的なホームページはそれほど興味深いものではありません。サイトに多くの資料があり、メインがそれらの一種の「ショーケース」として機能する場合はどうすればよいですか？このような「ウィンドウ」では、「ランダムな」素材を表示して、さまざまなユーザーがさまざまなものを見られるようにすると便利です（1人のユーザーでも、ブラウザーでページをリロードすることで新しいコンテンツを受け取ります）。

ソリューションは、ローテーションを使用したキャッシュです。

スクリプトを強制的にランダムにメインページに要素を返し、データベースに必要なクエリを（ゆっくりではありますが）実行します。
次に、1つではなく、たとえば10ページのバリエーションをキャッシュに保存します。
ユーザーがサイトにアクセスすると、これらのオプションの1つが表示されます。この場合、キャッシュが空の場合はスクリプトが起動され、空でない場合はキャッシュから結果が返されます。
別のユーザーが1日でサイトのすべての資料を「見る」ことができるように、キャッシュエージングタイムを小さく設定します（たとえば、1分）。

その結果、スクリプトジェネレーターへの最初の10個のリクエストが「正直に」実行され、サーバーが「ロード」されます。しかし、それらはキャッシュに「落ち着き」、1分以内にすでにすぐに発行されます。生産性の向上は、サイトへの訪問者が多いほど大きくなります。

回転キャッシュを実装するnginxの構成要素は次のとおりです。

 fastcgi_cache_path / var / cache / nginx levels = keys_zone = wholepage：50m;
 perl_set $ rand 'sub {return int rand 10}';
 ...
サーバー{
   ...
  場所/ {
     ...
     fastcgi_pass 127.0.0.1:9000;
     ...
     ＃キャッシュをオンにして、キャッシュキーを慎重に選択します。
     fastcgi_cache wholepage;
     fastcgi_cache_valid 200 301 302 304 1m;
     fastcgi_cache_key "$ rand | $ request_method | $ http_if_modified_since | $ http_if_none_match | $ host | $ request_uri";
     ＃異なるユーザーが同じセッションCookieを受け取らないことを保証します。
     fastcgi_hide_header "Set-Cookie";
     ＃とにかく、nginxにページをキャッシュさせる
     ＃PHPで公開されるヘッダーをキャッシュします。
     fastcgi_ignore_headers "Cache-Control" "Expires";

     ＃ブラウザに毎回ページをリロードさせます（ローテーションのため）。
     fastcgi_hide_header "Cache-Control";
     add_header Cache-Control "no-store、no-cache、must-revalidate、post-check = 0、pre-check = 0";
     fastcgi_hide_header "プラグマ";
     add_headerプラグマ「キャッシュなし」;

     ＃常に最新のLast-Modifiedを発行します。
    期限切れ-1;  ＃注意!!! この期限切れの行が必要です！
     add_header Last-Modified $ sent_http_Expires;
   }
 }

前の例と比較して、場所にさらに6つのディレクティブを追加する必要がありました。それらはすべて非常に重要です！しかし、自分より先に進まないで、すべてを順番に検討します。

perl_set：ランダマイザーの依存関係

perl_set $ rand 'sub {return int rand 10}';

perl_setディレクティブは単純です。変数を作成します。これを使用して、nginxはそれに組み込まれたPerlインタープリターの関数を呼び出します。nginxの作成者によると、これは非常に迅速な操作であるため、「一致を保存」しません。変数は、各HTTP要求で0から9までのランダムな値を取ります。

fastcgi_cache_key：ランダマイザーの依存関係

fastcgi_cache_key "$ rand | $ request_method | ...";

ここで、ランダマイザー変数をキャッシュキーに混合しています。その結果、同じURLに対して10個の異なるキャッシュが必要になりました。キャッシュミス中に呼び出されるスクリプトはメインページの要素をランダムな順序で提供するため、メインページは10種類あり、それぞれが1分間「存続」します（fastcgi_cache_validを参照）。

add_header：ブラウザのキャッシュを強制的にオフにします

fastcgi_hide_header "Cache-Control";
add_header Cache-Control "no-store、no-cache、must-revalidate、post-check = 0、pre-check = 0";
fastcgi_hide_header "プラグマ";
add_headerプラグマ「キャッシュなし」;

上記では、nginxはPHPスクリプトによって出力されるキャッシュヘッダーの影響を受けやすいと述べました。 PHPスクリプトがヘッダー「Pragma：no-cache」または「Cache-Control：no-store」を返した場合（さらに、たとえば「Cache-Control：no-save、no-issue、me-here-not-私はこれを言わなかった、これはこの帽子です））、nginxは結果をキャッシュファイルに保存しません。特にこの動作を抑制するために、fastcgi_ignore_headersを使用します（上記を参照）。

Pragma：no-cacheとCache-Control：no-cacheの違いは何ですか？プラグマがHTTP / 1.0のレガシーであり、古いブラウザーとの互換性のために現在サポートされているからです。 HTTP / 1.1はCache-Controlを使用します。

ただし、ブラウザにはまだキャッシュがあります。また、場合によっては、ブラウザがページを表示するためにサーバーにリクエストを行おうとしないこともあります。代わりに、彼は自分のキャッシュからそれを取得します。なぜならローテーションがあるため、この動作は不便です。ユーザーがページにアクセスするたびに、新しいデータを表示する必要があるためです。（実際、まだ1つのオプションをキャッシュしたい場合は、Cache-Controlヘッダーを試すことができます。）

add_headerディレクティブは、キャッシュ禁止ヘッダーをブラウザーに渡すだけです。さて、このヘッダーが誤って増加するのを防ぐために、最初にHTTPレスポンスからPHPスクリプトが書き込んだもの（およびnginxキャッシュに書き込まれたもの）を削除します：fastcgi_hide_headerディレクティブ。結局、nginx configを作成するとき、PHPがそこに出力することを決定するかどうかはわかりません（そして、session_start（）が使用される場合、それは間違いなく決定します）。突然、彼は独自のCache-Controlヘッダーを設定しますか？次に、そのうちの2つがあります。PHP-shnyと、add_headerによって追加されます。

期限切れおよび最終変更：保証ページの再読み込み

期限切れ-1; ＃注意!!! この期限切れの行が必要です！
add_header最終変更$ sent_http_Expires;

別のトリック：Last-Modifiedを現在の時刻に設定する必要があります。残念ながら、nginxには現在の時刻を格納する変数はありませんが、expires -1ディレクティブを指定すると魔法のように表示されます。

これは現在文書化されていませんが（2009年10月）、nginxは、クライアントに送信されるXXX応答ヘッダーごとに$ sent_http_XXXの形式の変数を作成します。そのうちの1つを使用します。

現在の時間にこの見出しを設定することがなぜそれほど重要なのですか？すべてが非常に簡単です。

PHPがヘッダー「Last-Modified：some_date」を発行したとしましょう。
このヘッダーはnginxキャッシュファイルに書き込まれ（確認できます：この例では、ファイルは/ var / cache / nginxに格納されます）、クライアントにブラウザーに送信されます。
ブラウザはページとその変更日を記憶します...
… HTTP- - «If-Modified-Since: _».
nginx? , Last-Modified If-Modified-Since. ( ), nginx «304 Not Modified» . : , .

実際、大きな問題は、Last-ModifiedとCache-Control no-cacheの両方が存在する場合、ブラウザーがどのように動作するかです。彼はIf-Modified-Sinceリクエストを行いますか？ここでは、ブラウザが異なると動作が異なるようです。実験。

Last-Modifiedを手動で設定する理由がもう1つあります。実際、session_start（）PHP関数はLast-Modifiedヘッダーを強制的に発行しますが、その中に最初に制御を受け取ったPHPファイルへの変更の時刻を示します。したがって、サイト上のすべてのリクエストが同じスクリプト（フロントコントローラー）に送信される場合、Last-Modifiedはこのスクリプトの変更にかかった時間とほぼ常に等しくなりますが、これは完全に間違っています。

キャッシュページの動的な「ウィンドウ」

そして最後に、キャッシュの観点から有用なテクニックの1つを紹介します。サイトのメイン（または他の）ページをキャッシュしたいが、動的でなければならない1つの小さなブロックが干渉する場合は、SSIを操作するためにモジュールを使用します。

ページの動的な部分に、次のHTMLコメントを挿入します。

<！-＃include virtual = "/ get_user_info /"->

nginxキャッシュに関しては、このコメントはプレーンテキストです。コメントとしてキャッシュファイルに保存されます。ただし、後でキャッシュを読み取るときに、SSI nginxモジュールが機能し、動的URLを参照します。もちろん、アドレス/ get_user_info /には、このブロックの内容を返すPHPハンドラーが必要です。この方法については、Habrのこの記事で詳しく説明しています。

もちろん、このページまたはサーバー全体でSSIを有効にすることを忘れないでください。

ssi on;

SSI includeディレクティブには、非常に重要な別のプロパティがあります。そのようなディレクティブがページ上で見つかると、それらのすべてが並行モードで同時に処理され始めます。したがって、ページに4つのブロックがあり、それぞれが200ミリ秒をロードする場合、合計ページは800ではなく200ミリ秒でユーザーに受信されます。

この記事のソースコードはここで読むことができます：http : //dklab.ru/chicken/nablas /56.html

nginxでキャッシュを使用する場合の落とし穴