Varyヘッダーという「呪い」と「福音」：キャッシュ制御の深淵を解く
HTTP/1.1の仕様書（RFC 7231/9110）を読み解く際、多くのエンジニアが「Varyヘッダー」という小さくも強力な存在に躓く。CDNやリバースプロキシを設計する際、このヘッダーの取り扱いを誤れば、キャッシュ汚染（Cache Poisoning）という致命的な脆弱性を招くか、あるいは意図したパフォーマンスが得られないという不毛な戦いに身を投じることになる。
今日は、パケットがエッジサーバーのNICを叩くその瞬間から、バックエンドのコンテキストを決定づけるVaryヘッダーの挙動まで、インフラの深淵を覗いてみよう。
—
1. Varyヘッダーの正体：キャッシュの「多次元空間」
HTTPキャッシュの本来のキーは、シンプルに `URL` である。しかし、同じURLに対して、クライアントのデバイス種別（User-Agent）や圧縮アルゴリズム（Accept-Encoding）、あるいは言語設定（Accept-Language）によって応答を変えたいという要求は、Webの歴史と共に常に存在した。
Varyヘッダーは、「どのリクエストヘッダーをキャッシュのキー（識別子）に追加するか」をサーバーからキャッシュサーバー（CDNやブラウザキャッシュ）へ指示するものだ。
サーバーからの応答例
HTTP/1.1 200 OK
Content-Type: text/html
Vary: Accept-Encoding, User-Agent
このVaryヘッダーが存在すると、キャッシュサーバーは「このURLのコンテンツは、`Accept-Encoding`と`User-Agent`の値が一致した時に限り、キャッシュをヒットさせよ」と解釈する。
陥りやすい罠：Vary: User-Agent の悪夢
ここで一つ、ネットワークアーキテクトとして警告しておきたい。`Vary: User-Agent` は、キャッシュ効率を劇的に低下させる「禁じ手」に近い。なぜなら、User-Agent文字列は無数に存在し、ブラウザのマイナーアップデートごとにキャッシュが別物として扱われ、キャッシュヒット率が急降下するからだ。
もしデバイス出し分けが必要なら、User-Agentではなく、サーバーサイドで正規化した「デバイス種別」をCookieやカスタムヘッダーで表現し、Varyにその名前を指定するのがプロの設計である。
—
2. パケットレベルの最適化とTLSハンドシェイクの相関
Varyヘッダーが引き起こす問題は、単なるキャッシュ効率だけではない。TLSハンドシェイクとTCPバッファリングの文脈で考えてみよう。
TLS 1.3が普及した現在、RTT（Round Trip Time）削減のために `0-RTT` を活用するケースが増えている。しかし、Varyによってキャッシュが頻繁に破棄される環境では、エッジでのキャッシュミスが増え、オリジンへのバックエンド通信（RTTが長い）が発生する。
- TCPバッファチューニングの限界: キャッシュミスが頻発すると、オリジンからのTCPセッションが頻繁に貼られ、`initial_cwnd`（初期輻輳ウィンドウ）の制限により、最初のパケット群でのデータ転送量が制限される。
- TLSのオーバーヘッド: セッション再開が効かないキャッシュミス時、再度TLSハンドシェイクのオーバーヘッドが乗り、TTFB（Time To First Byte）が悪化する。
これを防ぐには、Varyのキーを極限まで絞り込むことだ。`Vary: Accept-Encoding` はほぼ必須だが、それ以外は可能な限り避ける。
—
3. 実践：キャッシュ汚染を回避するVaryの設計指針
キャッシュ汚染（Web Cache Deceptionなど）を回避し、かつ最大限のパフォーマンスを引き出すための具体的な設定指針を示す。Nginxを例に、リクエストを正規化する手法を提示する。
Nginxの設定例：Varyを適切に制御し、バックエンドへの影響を最小化する
location / {
# 1. Accept-Encodingは圧縮方式によってキャッシュを分けるために必須
# 2. 余計なUser-Agentなどは含めない（キャッシュ断片化防止）
# 3. キャッシュキーを正規化し、無用なミスを防ぐ
proxy_set_header Accept-Encoding “gzip, br”;
proxy_hide_header Vary; # 既存のVaryを一度剥がし、自前で制御する場合
add_header Vary “Accept-Encoding”;
# TCP/IPレベルのチューニング
proxy_buffering on;
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
}
インフラ構築のベストプラクティス
1. 正規化の徹底: リクエストヘッダーがキャッシュを汚染しないよう、エッジ側で必要なヘッダー以外をクレンジング（削除/正規化）せよ。
2. Varyは「最小単位」で: 複数の値をVaryに含める場合、それらが本当にキャッシュを分ける必要があるものか再考せよ。
3. CDNの機能を活用: 大手CDN（CloudflareやFastlyなど）には、`Vary`を無視しつつ、特定のリクエストヘッダーをキーにしてキャッシュを分ける「Cache Key Customization」機能がある。これを使えば、Varyヘッダーの副作用を回避できる。
—
結びに：プロトコルを愛する者へ
Varyヘッダーは、HTTP/1.1という枯れたプロトコルの中で、現代的な動的コンテンツを扱うための「つなぎ」として機能してきた。しかし、現代の高度なインフラにおいては、Varyヘッダーに依存しすぎる設計は、システムの複雑性を増大させる負債となり得る。
パケットの挙動を想像し、キャッシュサーバーのメモリ空間で何が起きているかを可視化する。その視点があれば、Varyヘッダーは単なるトラブルの種ではなく、パフォーマンスを制御するための強力なコントローラーへと変わるはずだ。
次は、HTTP/2のヘッダー圧縮（HPACK）と、このVaryがどのように干渉し合うのか……その深淵を覗いてみるのも面白いかもしれない。ネットワークは、常に問いを投げかけてくる。私たちはそれに、ベストな応答を返すだけだ。
コメント