HTTP/1.1の「Vary」が招くキャッシュ汚染の深淵：インフラアーキテクトが知るべき最適化の勘所
HTTP/1.1という、四半世紀以上前に策定された枯れたプロトコル。しかし、現代の複雑なフロントエンドとバックエンドの境界線において、このプロトコルが引き起こす「キャッシュ戦略のミス」は、依然としてインフラエンジニアを冷や汗まみれにさせる。
特に、`Vary`ヘッダーの不適切な取り扱いは、パフォーマンス最適化のつもりが、一瞬にしてユーザー体験を破壊し、セキュリティ上の脆弱性を生む「キャッシュ汚染」という劇薬へと化す。今日は、パケットレベルの挙動からこの深淵を覗いてみよう。
—
Varyヘッダーがキャッシュの「多次元化」を強制する仕組み
そもそも、HTTPキャッシュの基本単位は「URL（URI）」だ。しかし、現代のWebアプリケーションは同じURLであっても、リクエストヘッダー（`Accept-Encoding`, `User-Agent`, `Authorization`など）によってレスポンスを出し分ける必要がある。
ここで登場するのが `Vary` ヘッダーだ。オリジンサーバーが `Vary: Accept-Encoding` を返すとき、キャッシュサーバー（CDNやリバースプロキシ）に対してこう命じている。
> 「このリクエストのキャッシュキーは、URL単体ではなく、`Accept-Encoding` ヘッダーの内容も含めた合成値で作れ」
しかし、ここには落とし穴がある。もし `Vary: User-Agent` を設定してしまったらどうなるか？ 現代のブラウザやクローラーのUser-Agentは無数に存在する。キャッシュサーバーのストレージは、実質的に「URL × ユーザーの環境数」という巨大なマトリックスで埋め尽くされ、キャッシュヒット率は壊滅的に低下する。
—
キャッシュ汚染：意図せぬ情報漏洩とサービスダウン
キャッシュ汚染の最悪のシナリオは、本来「特定のユーザーにしか見せてはいけないコンテンツ」が、別のユーザーのブラウザにキャッシュされることだ。
脆弱性のメカニズム
例えば、認証ヘッダーを無視してキャッシュを返す設定（あるいは、`Vary: Authorization` を指定し忘れた設定）でCDNを運用しているとしよう。
1. 攻撃者: 特定のセッションIDを含むリクエストを送り、CDNにキャッシュさせる。
2. CDN: 「あ、これはURLが同じだから、次の人にもこれを返せばいいや」とキャッシュを保存。
3. 被害者: 通常のアクセスを行うが、CDNからは「攻撃者のセッション情報が含まれたレスポンス」が返却される。
これは単なるパフォーマンスの劣化ではない。認証情報の流出や、ユーザーのプライバシー侵害を招く極めてクリティカルな脆弱性だ。
—
実践的チューニング：パケットとカーネルの最適化
パフォーマンスを極限まで引き出しつつ、キャッシュ汚染を防ぐためには、以下の構成を強く推奨する。
1. Varyの値を最小化する
不要なヘッダーを `Vary` に含めてはならない。例えば、`User-Agent` でレスポンスを出し分けるのは、もはや時代遅れだ。レスポンスの出し分けは、可能な限り「Accept系」か「カスタムヘッダー」に絞るべきだ。
nginx.confでの設定例
不必要なVaryヘッダーを削除し、キャッシュの効率を最大化する
proxy_hide_header Vary;
add_header Vary “Accept-Encoding, Authorization”; # 必要なもののみに限定
2. TCPバッファとウィンドウサイズ
HTTP/1.1では、TCPのSlow Startとウィンドウサイズがパフォーマンスのボトルネックになる。OSレベルでの最適化を検討せよ。
sysctl.conf での推奨値（高トラフィック環境向け）
初期ウィンドウサイズを拡大し、最初のRTTでデータをより多く転送する
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_init_rwnd = 10
3. TLSハンドシェイクの高速化
HTTP/1.1の時代であっても、TLS 1.3の採用は必須だ。0-RTT（Zero Round Trip Time）を活用すれば、再接続時のハンドシェイクを極限まで短縮できる。ただし、0-RTTはリプレイ攻撃のリスクがあるため、冪等性（Idempotency）が保証されたGETリクエストのみに適用すること。
—
インフラエンジニアへの提言：キャッシュは「正しく」汚せ
HTTP/1.1の時代から続く「キャッシュの出し分け」という難問は、結局のところ、どのヘッダーを「正規化（Normalization）」するかという設計能力に依存する。
- 正規化の重要性: `Vary` の値が異なればキャッシュはヒットしない。CDN側で、不要なリクエストヘッダー（例：トラッキング用のクエリパラメータや、冗長なカスタムヘッダー）を削ぎ落としてからキャッシュのキーを生成する設定を入れるのが、アーキテクトとしての腕の見せ所だ。
「とりあえずCDNを噛ませてキャッシュする」という安易なアプローチは、いずれ必ず大規模な事故を招く。プロトコルの仕様を理解し、パケットがどのヘッダーを見て、どのキャッシュレイヤーに到達し、どのメモリ領域へ書き込まれるのか。その一連のフローを脳内で可視化できるエンジニアだけが、この「インターネットの交通網」を真に支配できるのである。
次回の運用では、ぜひ `Vary` ヘッダーを一度 `curl -I` で叩き出し、そのレスポンスが本当に「キャッシュ可能で安全か」を問い直してみてほしい。
コメント