境界線上の駆け引き：Varyヘッダーが制御する「キャッシュの神髄」
HTTP/1.1の仕様書、RFC 7231の深淵を覗いたことがあるだろうか。そこに記された `Vary` ヘッダーは、単なるメタデータではない。CDNやブラウザキャッシュ、そしてオリジンサーバーが繰り広げる「リソース提供の最適化」という名のチェス盤における、最も重要な駒の一つだ。
多くのエンジニアが「キャッシュの出し分け」という認識で止まっているが、インフラアーキテクトの視点から見れば、これはTCPコネクションの効率、TLSハンドシェイクのオーバーヘッド、そしてキャッシュ汚染（Cache Poisoning）によるセキュリティリスクを天秤にかける、極めて高度なパケット制御の領域である。
—
1. パケットの視点から見る「Vary」の存在理由
クライアントから送出されたパケットがエッジサーバー（CDN）に到達した瞬間、キャッシュエンジンはリクエストヘッダーを走査する。もし `Vary: Accept-Encoding` が設定されていれば、エッジは `Gzip` 圧縮されたコンテンツと、そうでないコンテンツを「別物」として認識しなければならない。
ここで重要なのは、Varyを多用することが、キャッシュのヒット率を劇的に下げる要因になるという冷徹な事実だ。
例えば、`Vary: User-Agent` を設定したとしよう。モバイル、タブレット、デスクトップ、さらに無数のブラウザバージョンに応じたUA文字列をキーにしてキャッシュを生成すれば、CDNのバックエンドには「事実上、キャッシュが効かない」のと同じ状態のフラグメンテーションが発生する。これはエッジからオリジンへの不要な再送（リクエストの透過）を招き、結果としてTTFB（Time to First Byte）を悪化させ、バックエンドの負荷を増大させる。
—
2. 賢いVaryの運用とキャッシュキーの正規化
アーキテクトが目指すべきは、Varyに依存しすぎないインフラ設計だ。可能な限り「キーを正規化」し、エッジ側でヘッダーを変換することで、キャッシュの断片化を最小限に抑える必要がある。
推奨されるVary設定の勘所
- Accept-Encodingは必須: `Vary: Accept-Encoding` は、トランスポート層の効率化（コンテンツ圧縮）に不可欠だ。ただし、これ以外のヘッダー（User-Agent等）をVaryに含めるのは避けるべきだ。
- ヘッダーの正規化: CDN側（FastlyやCloudflare等）の設定で、`User-Agent` を特定のデバイスカテゴリ（`mobile`, `tablet`, `desktop`）に書き換えてからキャッシュキーを生成するように制御する。
NginxでVaryヘッダーを制御する際のヒント
すべてのリクエストでVaryを送るのではなく、必要な場合のみ動的に制御する
map $http_accept_encoding $vary_header {
default “Accept-Encoding”;
“” “”; # 圧縮が不要な場合はVaryも出さない
}
レスポンスヘッダーに適用
add_header Vary $vary_header always;
—
3. セキュリティの死角：キャッシュ汚染とVaryの悪用
Varyは時に攻撃のベクターとなる。もし攻撃者が、サーバーが意図しない多様なリクエストヘッダーを送りつけることで、CDNに「有害なバリエーション」をキャッシュさせることができれば、それは立派なキャッシュ汚染だ。
特に、`Vary: X-Forwarded-For` のようなヘッダーを安易に許可すると、攻撃者は偽造されたIPアドレスに基づいて、特定のユーザーセッションを汚染したり、プライベートなコンテンツを別のユーザーに配信させる隙を生む。
インフラ防衛のための鉄則:
- Vary対象のホワイトリスト化: 信頼できるヘッダーのみをキャッシュキーに含める。
- キャッシュキーの分離: 必要であれば、Varyに頼らず `Cache-Key` を個別に生成・管理できるCDNの高度な設定機能を利用する。
—
4. パフォーマンスの極致：TLSとRTTの最適化
Varyを適切に制御し、キャッシュヒット率を最大化することは、単にサーバー負荷を減らすだけではない。それはTCPのSlow Startからの脱却を意味する。
キャッシュがヒットすれば、オリジンへの往復（RTT）はゼロになり、クライアントは確立されたTLSコネクション上で即座にデータを取得できる。逆にVaryの設定ミスでキャッシュがミスすれば、RTTの増大に加え、再度TLSハンドシェイクが必要になるケースすらある。
ネットワークチューニングのチェックリスト
1. TCP Fast Open (TFO) の有効化: 再接続時のRTTを削減する。
2. TLS 1.3の強制: 0-RTTハンドシェイクによるオーバーヘッドの最小化。
3. BBR輻輳制御アルゴリズムの適用: Linuxカーネルレベルで `net.core.default_qdisc = fq` と `net.ipv4.tcp_congestion_control = bbr` を設定し、パケット損失環境下でもスループットを維持する。
カーネルパラメータでのTCP最適化（BBRの有効化）
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr
注意: これらの設定は本番環境でのパフォーマンステストを経て適用すること
—
結論：プロトコルを支配する者が、UXを制す
Varyヘッダーは、HTTP/1.1から続く古典的な仕様だが、現代のCDNアーキテクチャにおいてもその重要性は揺るがない。キャッシュの断片化を恐れ、適切なキー正規化を行い、セキュリティを担保した上でキャッシュヒット率を極限まで引き上げる。
技術とは、公式ドキュメントをなぞることではない。プロトコルが裏側でどう動き、カーネルがパケットをどう処理しているのかを想像し、その挙動を意図通りに制御することだ。Varyを制する者は、ネットワークのレスポンスを制する。ぜひ、あなたのインフラでも今一度、Varyの挙動をパケットキャプチャで確認してみてほしい。そこには、まだ最適化の余地が眠っているはずだ。
コメント