「古い約束」と「新しいルール」の衝突：キャッシュの優先順位を整理しよう
こんにちは！ネットワークの世界へようこそ。
Webサイトを見ているとき、なぜ2回目以降のアクセスは一瞬でページが表示されるのか、不思議に思ったことはありませんか？
それは、ブラウザが「一度見たページを自分のカバン（キャッシュ）の中にしまっておく」という賢い工夫をしているからです。今日は、そのカバンの中身をいつまで信じていいのかを決める、「Expires」と「Cache-Control」という二つの看板について、お話ししていきましょう。
—
郵便配達で例える「賞味期限」の仕組み
皆さんが誰かに手紙（Webページ）を送るとき、受け取った相手がいつまでその手紙を保管していいかを決める「期限」が必要ですよね。
1. HTTP/1.0の「絶対時刻」方式（Expires）
昔ながらのやり方は、手紙に「2025年12月31日の23時59分まで有効」と、カレンダーの具体的な日付を書き込む方法です。これが`Expires`ヘッダーです。
- メリット: いつまでか一目でわかる。
- デメリット: 受け取った人の時計が狂っていたり、サーバーとブラウザでタイムゾーンがズレていたりすると、「あれ、もう期限切れかな？」と混乱が起きてしまいます。
2. HTTP/1.1の「相対時間」方式（Cache-Control）
後に登場したのが、もっと柔軟なルールです。手紙には「受け取ってから1時間だけ保管していいよ」と書くことにしました。これが`Cache-Control: max-age=3600`です。
- メリット: 今この瞬間から数えるので、時計のズレを気にしなくていい！
- 現代の主流: 圧倒的にこちらのほうが計算しやすく、事故が少ないのです。
—
二つが同時に書かれていたら、どっちを信じる？
現場でよくあるのが、「古いシステムの設定（Expires）が残ったまま、新しいルール（Cache-Control）を追加した」というケースです。
結論から言いましょう。現在のWebの世界では、「Cache-Control」が絶対的な王様です。
もし両方のヘッダーが届いた場合、ブラウザは迷わず最新のルールである`Cache-Control`を優先して計算します。なぜなら、`Expires`のような絶対時刻は、サーバーとブラウザの時計を合わせるという「極めて難しい調整」を強いるからです。現代のネットワーク設計において、時間はズレるものという前提に立つ方が、はるかに安全ですよね。
—
実践：実際にヘッダーを覗いてみよう
サーバーから送られてくるヘッダーは、ブラウザの開発者ツール（F12キー）の「ネットワーク」タブから確認できます。以下のような設定がよく見られます。
サーバーが送るヘッダーの例
HTTP/1.1 200 OK
Content-Type: text/html
古いブラウザのために一応残している日付
Expires: Wed, 31 Dec 2025 23:59:59 GMT
最新のルール！「3600秒（1時間）経ったら捨ててね」という指示
Cache-Control: max-age=3600
もし皆さんがWebサーバーの設定を行う際は、以下のように意識してみてください。
- 基本はCache-Control: `max-age`をメインに設定する。
- 保険としてExpires: 超古いブラウザに対応する必要がある場合のみ併記する。
- 注意点: 両方書くなら、どちらも同じ期間を示すように計算しておくこと（片方だけ極端に短いと、ブラウザが混乱してしまいます）。
—
最後に：一歩ずつ理解を深めていきましょう
「キャッシュの設定なんて、適当でも動くでしょ？」と思われるかもしれません。しかし、大規模なサイトになればなるほど、この小さな設定のズレが「更新したはずの画像がいつまでも変わらない！」といった深刻なトラブルに繋がります。
まずは、「Cache-Controlが今の時代の正解なんだな」と心に留めておいてください。それだけで、ネットワークトラブルを解決する際の視界がグッとクリアになりますよ。
プロトコルの歴史は、不便をどうやって解消してきたかという「工夫の歴史」です。これからも、パケットがどんな意図で旅をしているのか、一緒に紐解いていきましょうね！
コメント