Pleskウェブサーバ

HTTP条件付きリクエストとキャッシュ検証を理解する

HTTP条件付き リクエストは、最後のリクエスト以降にリソースが実際に変更された場合にのみ、クライアントがリソースを完全にロードするようにすることで、伝送コストを削減する。どのように キャッシュの検証 ETag、Last-Modified、If-None-Match、If-Modified-Since、304 Not Modifiedが確実に機能し、ロード時間が著しく短縮されます。.

中心点

バリデーション フルダウンロードの代わりに304は帯域幅と時間を節約します。.
イータグ とLast-Modifiedは、クリーンな制御のために一緒に働く。.
キャッシュ・コントロール は鮮度を定義し、期限はサプリメントのみ。.
前提条件 If-Matchのような安全な書き込み処理。.
セキュリティ 機密性の高いコンテンツには、プライベート/非保存が必要です。.

条件付きリクエストは日常生活で何をするか

をセットした。 条件付き サーバに明確な質問を投げかける必要がある：本当に新しいデータを転送する必要があるのか、それともキャッシュで十分なのか？ブラウザまたはプロキシは条件を送信し、サーバーはファイルが変更されたかどうかをチェックし、ボディなしで304 Not Modifiedで応答する。このパターンによって、HTML、CSS、JavaScript、画像、APIレスポンスが最新の状態に保たれ、インフラへの負荷が大幅に軽減される。より長い有効なアセットについては、私は長いmax-age値を使用し、バリデーションによってそれらが最新であることを保証する。もし適切なキャッシュ制御戦略古くなったコンテンツを危険にさらすことなく、キャッシュを最大限に活用する。.

キャッシュ検証を可能にするヘッダー

信頼性の高い キャッシュ-クライアントは決断を下すために、レスポンスからの明確なシグナルを必要としている。私はCache-Controlを鮮度とルールのために使い、Expiresを時々補足として使い、Last-ModifiedとETagを実際の検証のために使う。Last-Modifiedは素早くチェックできる更新時間を提供し、ETagは動的コンテンツにも使われるバージョン識別子を提供します。重要なのは、no-cacheは削除するのではなく、使用前に検証するということです。これらのセマンティクスを正しく適用すれば、コンテンツを最新の状態に保ちながら、データ・トラフィックを顕著に減らすことができる。内容.

迂回路のない条件付きリクエストのシーケンス

最初の呼び出しで、クライアントはファイルと以下のような検証値を保存する。 イータグ またはLast-Modifiedをキャッシュに送る。その後、リソースの有効期限が切れたり、使用前に新たなチェックが必要になったりして、クライアントはIf-None-MatchまたはIf-Modified-Sinceを送信する。サーバーはその情報を現在のステータスと比較し、新しいボディを持つ200 OKまたはペイロードなしの304 Not Modifiedを返す。その後、クライアントは既存のコピーを使い続け、送信、TLS作業負荷、時間を節約する。このピンポンは目立たないように見えるが効果ロードフィーリングとサーバーの負荷については明らかだ。.

ETagとLast-Modifiedの直接比較

私はこうしている。 最終更新日 私はタイムスタンプを素早くシンプルな参照として使いたいが、細かい制御にはETagsを使う。タイムスタンプは、非常に短い変更間隔で限界に達したり、動的な出力を改ざんすることがあります。私はファイルのハッシュ、データベースのバージョン、レンダリングのバリエーションからETagsを作成し、コンテンツの変更ごとに新しい識別子を生成しています。両方のメカニズムを組み合わせることができます：クライアントはIf-None-MatchとIf-Modified-Sinceを並行して送信することができ、サーバーは適切なチェックを選択します。このようにして、信頼できる バリデーション, これは静的リソースにも動的リソースにも等しく適用される。.

基準	最終更新日	イータグ
精度	ファイルに適した2番目の解像度	各コンテンツ変更のバージョン識別子
ダイナミクス	ファイルベースでない頻繁な変更に弱い	APIとレンダリングコンテンツに強い
支出	低い、ファイルシステムから利用可能	低～中程度、アプリ/プロキシで生成
コンフリクト	時計が狂う可能性がある	weak/strongタグが正しく設定されていない可能性

ブラウザのキャッシュとAPIの正しい設定

静的アセットには、長い 最高年齢 そして、更新がすぐに認識されるように、ETagまたはファイル名ハッシュで保存する。私はよくHTMLやAPIのレスポンスにno-cacheのマークをつけ、毎回すべてを再読み込みしなくてもクライアントが使用前に検証できるようにしている。共有キャッシュが他者に保持されたものを出力しないように、個人用ページにはprivateを付けている。エラーはしばしば矛盾したディレクティブやバリデーションヘッダの欠落によって引き起こされますが、私は明確なルールでそれを回避しています。典型的なつまずきのブロックを知っていれば、簡単に避けることができます。キャッシングにおけるヘッダートラップ, これは、私が自分自身を方向付けるのに好きなものだ。.

ステータスコードと条件を効果的に使用する

私は組織する ステータスコード 明らかに：200 OKはコンテンツを配信し、304 Not Modifiedはキャッシュの使用を確認し、412 Precondition Failedは条件が満たされない場合にキャンセルする。安全な書き込み操作のために、私はIf-Matchを使い、ETagが期待されるバージョンと一致する場合にのみ更新が有効になるようにしている。If-None-MatchまたはIf-Modified-Sinceを使った読み込みは、余計なペイロードを防ぎ、クライアントの同期を保つ。一貫した動作は重要である：同じエンドポイントは、同じ前提条件に対して同じように応答すべきである。SEOとボットのために、私はキャッシュとクローラーがステータスメッセージをどのように解釈するかに注意を払う。 HTTPステータスコードとクローリングクリーンな判断に役立つ。.

キャッシングのセキュリティとデータ保護

デリケートなコンテンツには ノーストア そのため、ブラウザやプロキシのキャッシュに残る可能性はありません。パーソナライズされたページはCache-Control: privateでマークし、長期的にキャッシュされたURLに個人データが表示されないことを確認しています。ユーザーアカウントや内部IDについて結論が導き出されることを許さず、ETagsを中立的にデザインしています。ログインビューやバンキングフローでは、一貫してすべてのキャッシュを無効にしています。データの最小化、適切なディレクティブ、クリーンなヘッダーを組み合わせれば、リスクを減らし、データを保護することができます。 守秘義務.

実装：サーバーとアプリケーションのステップ

はじめに静的動的なリソースの、長いデッドラインが意味を持つ場所と、検証が優先される場所を決める。Nginx、Apache、またはアプリサーバーでは、キャッシュコントロールを設定し、last-modifiedとETagsを有効にする。受信リクエストを処理する際、If-None-MatchとIf-Modified-Sinceを評価し、条件が一致すれば304で応答する。書き込み処理では、If-Matchを使用し、上書きを防ぐために逸脱した場合は412を返す。これにより、キャッシュを効率的に使用し、同時に 正しさ を保証する。.

メトリクス、テスト、モニタリングの賢明な利用

をチェックする。 ネットワーク-タブで、リソースがキャッシュから来ているか、検証中か、新しくロードされたかをチェックする。ステータス、エイジ値、ETags、転送されたレスポンスのサイズを監視しています。負荷がかかった状態で、待ち時間、転送量、サーバーのCPUを測定し、304レスポンスの実際の効果を確認します。リバースプロキシからのログは、共有キャッシュがその役割を果たしているかどうか、どれだけの検証が成功したかを示している。このデータを使って、最大年齢、キャッシュ制御ディレクティブ、ETagストラテジーを調整し、レスポンスタイムや ヒット率 に投票した。.

ホスティングのパフォーマンス：なぜ条件付きリクエストはコスト削減につながるのか

何れかの 304-共有キャッシュのレスポンスは帯域幅を節約し、TLSのオーバーヘッドを減らし、レスポンスタイムを短縮します。リバースプロキシ、ロードバランサー、CDNを使ったホスティングのセットアップでは、共有キャッシュを明確に許可するか、特に除外することで最大の効果が得られます。転送量が少ないということは、ユーロのトラフィックコストが低いということでもあり、実際の負荷ピークに対してより多くのリザーブがあるということでもある。繰り返されるページビューやAPIポールがより迅速に反応するため、ユーザーエクスペリエンスも向上する。このようにして、純粋なハードウェアのアップグレードだけでは実現できないパフォーマンスの可能性を実現し、既存の インフラストラクチャー より良い。

よくある間違いと現実的な解決策

矛盾 ヘッダー no-cacheのような、はるか未来の有効期限との組み合わせはキャッシュを混乱させる。ダイナミックエンドポイントのETagsが欠落していると、不必要なフルダウンロードにつながります。私は信頼できる識別子を追加し、if-none-matchを評価します。最大年齢が短すぎると、めったに変更されないファイルの可能性を無駄にしてしまう。HTMLの積極的なキャッシュは、目に見える変更を遅らせる。私はno-cacheとETagを組み合わせ、コンテンツを最新の状態に保つ。鮮度、検証、妥当性に関する明確な決定によって、私はこれらのつまずきのブロックを解決し、コンテンツを強化する。 計画性.

Varyをきれいに使い、表現をコントロールする

条件付きリクエストが共有キャッシュで安全に動作するように、私は正しい可変. .ヘッダーは、どのリクエストヘッダーが表現に影響を与えるかを定義する。典型的な例は Accept-Encoding (gzip、br）、, Accept-Language そして 受け入れる. .言語ごとにコンテンツを配信する場合は、Vary: Accept-Languageを設定して、フランス語のリクエストに対してプロキシがドイツ語版を共有しないようにしています。パーソナライズされたコンテンツの場合、私はあえてVary: Cookieを使わず、代わりに キャッシュ制御：プライベート, を使うことで、キャッシュキーの制御不能な爆発を避けることができる。有効な認証でのみ配信されるリソースについては、privateを使用するか、関連するヘッダでVary: AuthorisationまたはVaryを使用して明確に分離します。一貫性は重要です。Varyディメンションの選択されたセットは安定したままでなければなりません。そうでなければ、新しいバリアントが常に作成されるため、キャッシュのヒット率と検証の利点が崩れてしまいます。.

強いETagsと弱いETags、圧縮とバイトの等価性

強力なETags バイト単位の同一表現を特徴付け、範囲要求と組み合わせて正確な検証を可能にする。. 弱いETags (W/...)はコンテンツが同じであることを示すだけで、必ずしも同じバイトである必要はありません。実際には、それぞれの表現（圧縮を含む）に対して一意な識別子を生成できるのであれば、強いETagを使います。リバースプロキシがgzipやbrotliをオンザフライで使用するようになると、サーバとクライアントが異なるバイトを誤って同一と認識しないように、ETagの生成を適応させるか、弱いETagに切り替えます。強固な方法は、配信されたレスポンスの最終バイトからETagを生成し、同時に Vary: Accept-Encoding を設定する。これは、„gzip “と „br “がそれぞれ有効なETagsを受け取ることを保証します。バイトの等価性を保証できない場合（例えば、HTMLのタイムスタンプが異なる場合）、ページの意味が変更されていない限り、信頼できる304応答を可能にする弱いETagsを選択します。.

微調整におけるキャッシュ制御：s-maxage、must-revalidate、stale-while-revalidate

そのほか 最高年齢 私は特に細かいディレクティブを使っている。. Sマクサージュ 専用アドレス 共有キャッシュ (CDNやプロキシ）を使って、ブラウザよりも積極的にキャッシュすることができる。. 再検証が必要 クライアントは、期限切れのコンテンツを発見的に使用するのではなく、常に検証することを余儀なくされる。. プロキシ再検証 は、共有キャッシュに特化したこの義務に対処している。とは 有効期限切れ 私は、バックグラウンドで検証を実行している間、少し古いコピーを一時的に配信することを許可している。ユーザーはすぐに何かを見ることができ、次のリクエストは新鮮なメタデータの恩恵を受けることができる。. もしエラーなら をセーフティネットとして使用します：Originが失敗したりエラーを返した場合、キャッシュは定義された時間の間、最後の既知のコピーを配信することができます。ビルドハッシュされたアセットに対しては、長い最大年齢と不変, ファイル名がコンテンツとともに変更されるため、中間的な検証は不要だからだ。HTMLとAPIについては、no-cache＋バリデータが、最新性を確保しつつ帯域幅を節約するためのゴールドスタンダードであることに変わりはない。.

さらなる条件と方法：HEAD、レンジ、ライティングコンフリクト

条件付きリクエストはGETに限らない。A HEAD-requestはヘッダーのみを提供し、ボディなしで素早くバリデーションを行うのに理想的です。大きなファイルには レンジ-リクエスト イフ・レンジ 部分的な領域は、リソースがまだ期待されるバージョンと一致する場合にのみ送信されるようにする。書き込み操作については イフ・マッチ ab: PUT、PATCH、DELETEは、クライアントのETagが現在のバージョンと一致する場合にのみ動作します。そうでない場合は、412 Precondition Failedで応答します。前提条件を強制したい場合、たとえば衝突しやすいリソースでは、428 Precondition Requiredを使って、クライアントにIf-Matchを使ってもらうようにしている。412は前提条件の違反を示し、409は内容の競合（ビジネスロジックのルールなど）を強調する。このように明確にすることで、クライアントの実装を容易にし、盲目的なオーバーライドを避けることができる。.

パーソナライゼーション、クッキー、データ保護の実際

パーソナライズされたページでは、私は答えに印をつける。 プライベート 或いは ノーストア. .なぜなら、そのような「ユーザーごと」のEタグは、無意識のうちにトラッキング・マーカーになりうるからである。その代わりに、私はパブリックな表現とプライベートな表現を厳密に区別しています。キャッシュキー（Vary: Cookie）にクッキーを設定するのは、絶対に必要な場合だけです。認可されたAPIレスポンスに対しては、私は キャッシュ制御：プライベート そして必要であれば、Authorisationヘッダー形式をVaryにする。このようにして、共有キャッシュが不注意に機密のレスポンスを共有しないようにしている。コンテンツが混在するアプリケーション（パブリックな基本フレームワーク、パーソナライズされたサブエリア）では、断片化されたキャッシュやエッジESI/SSIに頼る一方、重要な部分はプライベートのままにしている。その結果、パフォーマンスを低下させることなくデータを保護することができる。.

運用：CDN、サロゲート、無効化

CDNのセットアップでは Sマクサージュ を明確なバリデーターで使用し、利用可能であればサロゲート固有のディレクティブを使用して、ブラウザとは別にエッジキャッシュを制御します。再バリデーションはOriginの負荷を減らしますが、時にはハードなバリデーションが必要になることもあります（セキュリティ修正など）。そこで私は2つの方法を考えています： キャッシュ・バスト 静的アセットのファイル名ハッシュと パージ/HTMLとAPIの無効化。これにより、„パージ・ストーム “を防ぎ、なおかつ更新までの時間を短く保つことができる。CDNで一貫したキャッシュ・キー（ホスト、パス、クエリ・パラメータ、関連するVaryヘッダを含む）を持つことも重要だ。クエリパラメータについては、セマンティックなもの（例えば?lang=）と純粋にトラッキングに関連したパラメータを意識的に区別している。後者は断片化を避けるためにキャッシュキーでは無視している。これにより、ブラウザのキャッシュ、中間プロキシ、CDNの連鎖を透明で予測可能なものに保っている。.

304の詳細ヘッダーとメタデータを正しく更新する

また 304-レスポンスには重要なメタデータが含まれています。クライアントがキャッシュエントリを更新できるように、Date、Cache-Control、ETag/Last-Modified、そして関連する場合はExpiresとVaryを再度送ります。Content-TypeとContent-Encodingは必ずしも繰り返される必要はないが、わかりやすさに貢献する。304がボディペイロードを含まないことと、一貫性のあるバリデータを送信することが重要である：表現を変えずに304のETagを変更することは混乱を招く。ガイドラインが調整される場合（例えば、より長いmax-age）、クライアントはボディをリロードすることなくメタデータを採用することができます。.

クリーンな検証のためのテストとデバッグ戦略

私は特にDevToolsで以下の点をチェックしている： ディスクキャッシュから 対 メモリキャッシュから 対 再検証済み; Status 200/304; 共有キャッシュからのレスポンスにおけるAgeヘッダー; ETag/Last-Modifiedの一貫性とVaryの効果。再現性のあるテストのために、ブラウザのキャッシュを一時的に無効にするか、プライベートモードを使用する。サーバー側では、200/304の比率、平均レスポンスサイズ、CPU使用率に関するログを評価する。警告シグナルは、例えば、短い変更間隔を持つリソースへの多くの200レスポンス（バリデータの欠落）、再バリデーションのループ（逸脱時間/クロックドリフト）、URLごとに異常に多くのバリアント（過剰なVary）です。私は負荷テストを使って、s-maxage、stale-while-revalidate、if-none-matchがプレッシャー下でどのように振る舞うかをチェックし、スループットとレイテンシが一致するまでディレクティブを調整します。.

エッジケースとロバスト・デフォルト

すべてのリソースに明確な変更ルールがあるわけではない。私は、生成されたサイトマップ、フィード、ダッシュボードのデフォルトを慎重に設定する： キャッシュなし にETag/Last-Modifiedを加えたものである。アップストリームシステム間のクロックが不安定な場合、私は厳密な秒単位の比較を避け、タイムスタンプに依存しないETagを使用します。圧縮が可変の場合（異なるgzipレベル）、圧縮の結果をETag生成に含めるか、弱いETagに切り替えます。また、クライアントがバリデータなしでリクエストしてきた場合は、明確なシグナルを送ります：鮮度を明確にする（max-age/immutable）か、検証を明確にする（no-cache + ETag）。これらは 堅牢なデフォルト 不完全なクライアントや欠陥のあるクライアントであっても、不要な負荷ピークが発生しないようにする。.

簡単な要約

条件付きリクエストの接続 スピード そして、コンテンツが変更された場合にのみ、クライアントが完全なリソースを取得するようにすることで、適時性を確保します。新鮮さを保つためにキャッシュ制御を使用し、信頼性の高いチェックのためにlast-modifiedとETagを組み合わせ、条件が満たされた場合は一貫して304で応答します。共有キャッシュにデータが残らないように、個人的なコンテンツや機密性の高いコンテンツはprivateまたはno-storeで隔離しています。DevTools、ログ、メトリクスで測定することで、期限を伸ばしたり、検証ロジックを強化したりできる場所がわかります。これらの構成要素を一緒に考えれば、ページの高速化、サーバー負荷の軽減、そして ラウンダー データを無駄にしないユーザー体験。.