用語辞典・サーバー・Web運営

Webキャッシュ

Webキャッシュとは

Webキャッシュは、一度生成・取得したWeb応答を一時保存し、同じ要求へ再利用する仕組みです。英語ではWeb cache(ウェブ・キャッシュ)と表します。

再利用できれば、転送量、オリジンサーバーの処理、待ち時間を減らせます。保存するか、どれだけ新しいと見なすか、再検証するかはHTTPの規則と設定で決まります。

キャッシュは「古いファイルが残る箱」ではありません。要求を識別し、応答の再利用条件と期限を評価するHTTPの仕組みです。

鍵で候補を探し、freshなら再利用、古いならオリジンへ再検証する保存・新鮮さ・検証・無効化を別の判断にする
ブラウザーと共有キャッシュが要求鍵、freshと古い、プライベート応答、検証器、304、更新後の無効化を判断するピクトグラム図解
図1古いは直ちに削除という意味ではありません。検証器で未変更を確認できれば、本文を再送せず再利用できます。

ブラウザーキャッシュと共有キャッシュを分ける

プライベートキャッシュは、一人の利用者を主な対象とするブラウザーキャッシュなどです。共有キャッシュは、CDNや組織内プロキシのように複数利用者の応答を扱います。

認証済みページや個人情報はプライベートでのみ扱うか、保存自体を禁止します。共有キャッシュに個人応答を保存すると、別の利用者へ返す危険があります。

キャッシュ鍵で同じ要求かを判断する

主に要求方式と対象URIを基に候補を選び、Varyで指定された要求ヘッダーも比較します。言語ごとに応答が違うなら、サーバーはVary: Accept-Languageなどで違いを伝えます。

問い合わせパラメーターの順序、追跡パラメーター、Cookieを鍵へどう扱うかは実装設定にも左右されます。無視してはいけない値を落とすと誤配信し、すべて含めると該当率が下がります。

鮮度は再利用できる時間

Cache-Control: max-age=3600は、保存後ではなく応答の生成時刻を基準に、通常3600秒の鮮度有効期間を示します。共有キャッシュ向けにはs-maxageを別指定できます。

Ageは応答が生成・検証されてからキャッシュ内で経過した概算時間を示します。Date、転送時間、上流キャッシュのAgeも考慮されるため、単純な手元タイマーとは限りません。

no-cacheとno-storeは意味が違う

  1. no-storeこの応答をキャッシュへ保存しないよう求める。機密データの残存を減らす。
  2. no-cache保存はできるが、再利用前にオリジンへ検証しなければならない。
  3. プライベート共有キャッシュへ保存させず、プライベートキャッシュでの扱いを許せる。
  4. must-revalidate古いになった後、オリジンでの検証なしに通常再利用しない。

名前の印象で設定すると逆になります。「常に最新確認したい」だけならno-cache、「保存させたくない」ならno-storeが中心です。

検証器なら本文を送り直さず確認できる

サーバーがETagを返した場合、キャッシュは次回If-None-Matchで同じタグを提示できます。変更がなければサーバーは304 Not Modifiedを返し、キャッシュ済み本文を再利用します。

Last-ModifiedIf-Modified-Sinceもありますが、時刻精度や時計条件があります。ETagの比較方式と、圧縮・言語variantごとの値を一貫させます。

古いを意図的に使う場合がある

RFC 5861のstale-while-revalidateは、一定期間は古い応答を返しながら背後で更新できます。stale-if-errorは、上流エラー時に限って古い応答を許容します。

価格、在庫、緊急情報のように古さが問題になるデータでは使える秒数を短くします。可用性と正確さの優先順位をコンテンツごとに決めます。

更新時はURL変更か無効化を行う

内容ハッシュ付き資産は、内容変更と同時にURLを変えるキャッシュbustingが確実です。同じURLを保つHTMLやAPIは、短い期限、検証器、CDN削除を組み合わせます。

一つの記事が一覧、分類、RSS、APIにも現れるなら、どのキャッシュ鍵を無効化するか依存関係を持ちます。全部削除は分かりやすい反面、オリジンへ不一致が集中します。

Cookieと認証応答を慎重に扱う

Set-CookieがあるだけでHTTP上すべてのキャッシュが自動禁止になるわけではありません。明示的なCache-ControlとCDN設定で共有可否を決めます。

URLへ利用者IDを入れず、認証ヘッダーやCookieを無視したキャッシュ鍵を作りません。ログアウト後にブラウザーの戻る操作で機密画面が見える問題には、キャッシュだけでなくページライフサイクル全体で対処します。

キャッシュpoisoningを入口で防ぐ

応答生成に影響するヘッダーやホストをキャッシュ鍵に含めないまま、攻撃者の入力を反映すると、汚染された応答を他者へ配るキャッシュpoisoningが起き得ます。受け付けるホスト、forwardedヘッダー、URLを正規化します。

キャッシュ調査では、保存場所、キャッシュ鍵、現在のAge、鮮度、検証器、応答したホップを揃えて確認します。「更新したのに古い」だけでは原因を特定できません。

HTTP cacheの確認資料:RFC 9111「HTTP Caching」RFC 5861「HTTP Cache-Control Extensions for Stale Content」

関連用語