【入門編】HTTP/1.1のVaryヘッダーとキャッシュの多様性 – HTTPプロトコル・通信規格実践ガイド

こんにちは！ネットワークの世界にどっぷり浸かっているエンジニアライターです。

皆さんはWebサイトを見るとき、ブラウザが裏側でどれほど頑張って「効率よく」データを運ぼうとしているか、想像したことはありますか？一度見たページが二度目に爆速で表示されるのは、皆さんのPCや中継地点にあるサーバーが「キャッシュ（一時保管）」という名のメモ帳を持っているからです。

しかし、この「キャッシュ」、時として「間違った相手に間違った情報を渡してしまう」という大失態を犯すことがあります。そんなトラブルを防ぐための守護神、それが今回ご紹介する「Vary（ヴェアリー）ヘッダー」です。

今日は、郵便配達の仕組みに例えながら、この奥深い世界を一緒に解き明かしていきましょう。

—

想像してみてください。あなたは巨大な図書館の司書です。そこへ、お客さんから手紙（リクエスト）が届きます。

「『日本料理のレシピ』を貸して！」

あなたはすぐに本棚から本を取り出し、手渡します。これがキャッシュの基本です。しかし、もしお客さんからこんな注文が来たらどうでしょう？

「『日本料理のレシピ』を貸して！ただし、英語で書いてあるやつで！」

もしあなたが何も考えず、一番手前にある「日本語版」を渡してしまったら、お客さんは困ってしまいますよね。ここで必要なのが、「どの条件を基準に本を選ぶか」をあらかじめメモしておくことです。

HTTP通信における `Vary` ヘッダーは、まさにこのメモ書きです。サーバーはブラウザに対してこう告げます。

> 「このページをキャッシュするなら、『どの言語を希望しているか（Accept-Language）』という条件をチェックして、それごとに別々の本として保管しておいてね！」

こうすることで、キャッシュサーバーは「あ、これは英語用だな」「こっちは日本語用だな」と、リクエストの内容に応じて中身を正しく出し分けることができるようになるのです。

—

もし `Vary` ヘッダーを付け忘れるとどうなるでしょうか。

1. 最初のリクエスト（英語）がキャッシュサーバーに届く。
2. サーバーが「英語のページ」をキャッシュする。
3. 次に別の人が「日本語のページ」を要求する。
4. キャッシュサーバーは「ああ、ページならさっき持ったよ！」と、間違えて英語のページを日本語の人に渡してしまう。

これが、現場で恐れられている「キャッシュ汚染（Cache Poisoning）」の正体です。表示が崩れたり、全く違う言語が表示されたりするトラブルは、大抵このキャッシュの管理ミスが原因だったりします。

—

Webサーバー（ApacheやNginxなど）の設定は難しくありません。基本的には、HTTPレスポンスのヘッダーに「この条件で出し分けろ」と追記するだけです。

例えば、言語によってページを出し分けたい場合は、以下のように指定します。

HTTPレスポンスヘッダーの例
「言語設定（Accept-Language）を見てキャッシュを判断してね！」という指示
Vary: Accept-Language

もし、デバイス（スマホかPCか）によって出し分けるなら、こんな設定になります。

「端末の種類（User-Agent）を見てキャッシュを判断してね！」という指示
Vary: User-Agent

`Vary` ヘッダーを指定する際、あまりに細かすぎる条件（例えば、ブラウザのバージョンごとに細かく分けるなど）を指定しすぎると、キャッシュの効率が極端に落ちます。

「ほとんど同じページなのに、キャッシュが別々になってサーバーがパンクする！」という事態を避けるためにも、「本当に意味のある違いは何なのか？」を設計段階で見極めるのが、一流のネットワークエンジニアの仕事です。

—

今回のお話をまとめると、以下の3点です。

最初は難しく感じるかもしれませんが、パケットを「手紙」、サーバーを「図書館」のようにイメージすると、ネットワークの挙動がぐっと身近に感じられるはずです。

もし現場で「キャッシュが変な動きをするな？」と思ったら、まずはブラウザの開発者ツール（F12キー）を開いて、レスポンスヘッダーに `Vary` がどう設定されているか確認してみてください。きっと、トラブル解決の大きなヒントが見つかるはずですよ。

それでは、また次回の記事でお会いしましょう！ネットワークの旅を楽しんでくださいね！