HTTPキャッシュの深淵：`Expires`と`Cache-Control`が交差する境界線で起きていること
ネットワークエンジニアとして現場に立っていると、プロトコルの仕様書が「きれいごと」に過ぎない瞬間に出くわす。特に、Webキャッシュの挙動ほど、クライアントとサーバの間で解釈の揺らぎが生じやすく、かつインフラのパフォーマンスに直結する領域は他にない。
今回は、HTTP/1.0の遺産である `Expires` と、モダンなHTTP/1.1の標準である `Cache-Control` が混在する環境下で、一体何が起きているのか。その内部挙動を、パケットレベルの視点から紐解いていこう。
—
1. 優先順位という名の「仕様の隙間」
多くの技術者が誤解しているが、`Expires` は日付を指定する絶対時刻型のキャッシュ制御だ。一方、`Cache-Control: max-age` は相対時間（秒単位）でキャッシュ寿命を定義する。
RFC 7234の厳格な規定によれば、`Cache-Control` ヘッダーが存在する場合、`Expires` ヘッダーは完全に無視されることになっている。
しかし、この「無視」という挙動を過信してはいけない。レガシーなゲートウェイや、特定の古いCDNノード、あるいはプロキシサーバを通った際、パケットが書き換えられたり、実装のバグで「古いヘッダー」を優先してキャッシュ判定をしてしまうケースが稀に存在する。この挙動の差異が、デプロイ後のキャッシュパージ失敗という悪夢を招く。
なぜ両方書くのか？
歴史的経緯から言えば、HTTP/1.0準拠のキャッシュサーバに対する「念のための保険」だ。だが、現代のアーキテクチャでは、あえて `Expires` を送出しないという選択肢こそが、意図しないキャッシュ汚染を防ぐための最適解となる。
—
2. パケットレベルで見る「無駄」の正体
キャッシュヘッダーの不整合は、RTT（Round Trip Time）削減の観点からも致命的だ。
HTTP/1.1時代においても、TCPのハンドシェイクやTLS 1.3の0-RTTハンドシェイクを最適化し、TTFB（Time to First Byte）を削り取っているアーキテクトであれば、キャッシュ戦略の曖昧さがどれだけ「無駄なパケット」を生むか理解できるはずだ。
- 無効なキャッシュ判定: キャッシュが効くべきところで `If-Modified-Since` や `If-None-Match` が飛び交い、サーバ側で `304 Not Modified` を生成するコストを払う。
- TCPバッファの枯渇: 不要なリクエストが増えることで、Linuxカーネルのソケットバッファが圧迫され、同時接続数（`tcp_max_syn_backlog` 等）の限界に達する。
もし、キャッシュ戦略が曖昧でリクエストのキャッシュヒット率が下がっているなら、アプリケーションのコードをいじる前に、まずはレスポンスヘッダーの整理から始めるべきだ。
—
3. 実践：インフラ層でのキャッシュ最適化設定
Nginxを例に、キャッシュ戦略を「モダンに統一」するための設定例を示す。ここで重要なのは、古いヘッダーを「消し去る」ことだ。
キャッシュ制御をHTTP/1.1に一本化する設定
location /static/ {
# 既存のExpiresがあれば削除し、Cache-Controlを上書きする
more_clear_headers “Expires”;
# max-ageで相対時間を指定し、publicを明示してプロキシでのキャッシュを許可
add_header Cache-Control “public, max-age=31536000, immutable”;
# 厳格なセキュリティ：HTTPS通信を強制する
add_header Strict-Transport-Security “max-age=63072000; includeSubDomains; preload”;
}
なぜ `immutable` を使うのか
モダンブラウザであれば、`Cache-Control: immutable` を付与することで、ユーザーがリロードボタンを押しても再検証（Revalidation）をスキップさせることができる。これは、不要なパケットをネットワークから完全に排除する「インフラ側の最適化」だ。
—
4. トラブルシューティングの極意：TLSとヘッダー圧縮
HTTP/2以降、ヘッダーはHPACKというアルゴリズムで圧縮される。もし `Expires` と `Cache-Control` を両方大量に送り続けていれば、この圧縮効率もわずかに悪化する。
トラブルシューティング時に確認すべきは、Wiresharkのパケットキャプチャだけではない。`curl` を使って、生ヘッダーがどう流れているかを確認するのが基本中の基本だ。
ヘッダー情報を詳細に追いかけるデバッグコマンド
curl -I -H “Accept-Encoding: gzip, deflate, br” https://example.com/
ここで `Expires` が残っているなら、それは「過去の亡霊」だ。現代のインフラアーキテクチャにおいては、不要なヘッダーは帯域の無駄であり、セキュリティ上の潜在的な脆弱性（キャッシュポイズニングの要因）になり得る。
—
結びに代えて：アーキテクトとしての矜持
HTTPの歴史は「後方互換性との戦い」だ。しかし、全てのレイヤーで互換性を維持し続ける必要はない。エッジサーバやCDNのレベルで適切にヘッダーをフィルタリングし、クライアントには常にクリーンなキャッシュポリシーを届ける。
それが、現代のインフラアーキテクトが担うべき「プロトコルの最適化」だ。
パケットがネットワークを駆け巡るその瞬間、余計なヘッダーが一つ減るだけで、ユーザーの体感速度とサーバの負荷は劇的に改善する。教科書を読み解くのもいいが、ぜひ自分の手でパケットをキャプチャし、その挙動をその目で確かめてみてほしい。そこには、仕様書には書かれていない「リアルなネットワークの呼吸」があるはずだ。
コメント