悪魔のヘッダー「Vary」：キャッシュ汚染を防ぎ、エッジコンピューティングを最適化する深淵なる作法
ネットワークの最前線で戦う諸君なら、一度は「なぜか古いキャッシュが配信される」「ユーザーエージェントによって表示が崩れる」といった怪奇現象に遭遇したことがあるはずだ。その犯人の多くが、HTTP/1.1から本格的に導入された `Vary` ヘッダーの不適切な扱いに起因している。
今回は、単なるRFCの解説ではなく、パケットがCDNのエッジキャッシュを通過する際の「判断ロジック」と、それがパフォーマンスおよびセキュリティにどう直結するのかを、インフラアーキテクトの視点から紐解いていく。
—
1. Varyヘッダーが引き起こす「キャッシュ汚染」の正体
CDNやリバースプロキシ（Nginx, Varnish等）において、キャッシュサーバーはキー（通常はURL）に基づいてレスポンスを決定する。しかし、現代のWebアプリケーションは同じURLであっても、リクエストヘッダーに応じて異なるコンテンツ（PC用、スマホ用、圧縮の有無など）を返す必要がある。
ここで `Vary` ヘッダーが登場する。「このレスポンスは、指定されたリクエストヘッダーの値に基づいて出し分けるべきだ」とサーバーがキャッシュサーバーに宣言するわけだ。
致命的な設定ミス：高すぎる多様性
もし `Vary: User-Agent` を安易に設定してしまうとどうなるか。世の中には数千種類ものUser-Agentが存在する。これらをすべてキャッシュのキーにしてしまうと、キャッシュヒット率は壊滅的に低下し、オリジンサーバーへリクエストが殺到する「キャッシュスタンピード」を引き起こす。
さらに、攻撃者がランダムなUser-Agentを捏造して大量にリクエストを送れば、CDNのキャッシュ領域をゴミデータで埋め尽くす「キャッシュ汚染（Cache Poisoning）」が可能になる。これは単なるパフォーマンス低下ではなく、セキュリティ上の深刻な脆弱性だ。
—
2. パケットレベルで考える：Varyとヘッダー圧縮の最適化
インフラアーキテクトとしては、この `Vary` をどう制御し、レイテンシを極限まで削るかを考えねばならない。
HTTP/2以降のヘッダー圧縮（HPACK）との関係
HTTP/1.1の `Vary` はテキストベースだが、HTTP/2/3ではHPACK/QPACKによりヘッダーは圧縮される。しかし、`Vary` の値が長大で頻繁に変化すると、動的テーブルが頻繁に更新され、圧縮効率が低下する。
対策：
`Vary` には最小限のキーのみを指定せよ。`User-Agent` ではなく、必要な機能フラグを持つ特定のヘッダー（例：`X-Device-Type`）へ抽象化するのが定石だ。
—
3. 実践：Nginxによる効率的なVary制御
実務でキャッシュ効率を最大化しつつ、セキュリティを担保するためのNginx設定例を紹介する。
キャッシュの正規化とVaryの最適化
location / {
# ユーザーエージェント全体ではなく、特定の識別子に絞る
# これによりキャッシュキーの爆発を防ぐ
proxy_set_header X-Device-Type $device_type;
# オリジンからのレスポンスに対してVaryを整理
# 不要なVaryヘッダーを削除し、必要なものだけを許可する
proxy_hide_header Vary;
add_header Vary “Accept-Encoding, X-Device-Type”;
# TCPバッファチューニングとの併用
# バックエンドへのスループットを最大化する設定
proxy_buffering on;
proxy_buffer_size 128k;
proxy_buffers 4 256k;
}
—
4. トランスポート層の最適化とTLSハンドシェイク
`Vary` を活用したコンテンツ出し分けを行う際、忘れがちなのが「TCPの初期輻輳ウィンドウ（initcwnd）」とTLSハンドシェイクのオーバーヘッドだ。
- TCP Fast Open (TFO) の活用: リクエストと同時にデータパケットを送り出すことで、RTTを削減する。
- TLS 1.3 0-RTT: キャッシュサーバーとの通信において、セッション再開時のハンドシェイクをゼロRTTにすることで、`Vary` による出し分けのオーバーヘッドをネットワークレイヤーで相殺する。
もし君たちがハイエンドな配信基盤を設計しているなら、キャッシュサーバーの「判定ロジック（Vary）」と「物理的な通信性能（TCP/TLS）」を切り離して考えるのではなく、「キャッシュのヒット率を上げ、オリジンまでのRTTを最小化する」という一つの最適化問題として統合して考えるべきだ。
—
結びに：アーキテクトとしての矜持
`Vary` ヘッダーは、Webの多様性を支えるための強力なツールだが、それは諸刃の剣でもある。
1. キャッシュキーの多様性を制限せよ: `User-Agent` のような高次元な値をそのままキーにしてはならない。
2. Varyの正規化: CDN側で `Vary` ヘッダーを適切に正規化し、無駄なキャッシュ生成を抑制せよ。
3. 監視を怠るな: キャッシュヒット率（Cache Hit Ratio）だけでなく、`Vary` に起因するキャッシュの断片化（Fragmented Cache）をメトリクスとして可視化すること。
ネットワークは正直だ。設計の甘さは、必ずパケットの遅延やインフラコストという形で跳ね返ってくる。諸君のインフラが、より堅牢で、より速いレスポンスをユーザーに届けられることを期待している。
コメント