帯域を無駄にするな：ETagと条件付きGETが守る「真のネットワーク効率」
ネットワークアーキテクチャの観点から見て、HTTP/1.1の最大の功績は「いかにして通信を発生させないか」という最適化の思想にある。特に`ETag`を用いた条件付きGETは、現代のCDNやWeb加速技術の根幹をなす、極めてエレガントな仕組みだ。
教科書的な説明は省こう。現場で向き合うべきは、クライアントが手元に持つキャッシュの「鮮度」を、サーバーと最小のパケット交換で同期させるための、冷徹なまでの最適化ロジックである。
—
If-None-Matchが引き起こす「304」の沈黙
クライアントが一度リソースを取得すると、ブラウザはそれをローカルにキャッシュする。しかし、そのリソースが更新されたかどうかを知るためには、本来であれば再度サーバーへリクエストを投げ、巨大なペイロード（200 OK）を受け取る必要がある。これでは帯域の浪費だ。
ここで登場するのが `ETag`（Entity Tag）である。サーバーが生成したリソースのハッシュ値（またはバージョン識別子）を `If-None-Match` ヘッダーに込めて送信することで、サーバー側は以下の挙動をとる。
1. 受信: `If-None-Match` に含まれるハッシュ値と、サーバー上の最新リソースのハッシュを比較。
2. 判定: 一致すれば、ボディを一切送信せず `304 Not Modified` を返す。
3. 効果: TCPの「Slow Start」によるウィンドウサイズの制限や、TLSの暗号化計算リソースを最小限に留める。
この「ボディなしの304」こそが、トラフィックを劇的に削減するインフラの生命線だ。
—
パケットレベルでの最適化：RTTとTCPウィンドウ
条件付きGETを語る上で避けて通れないのが、RTT（Round Trip Time）の削減である。304レスポンスはヘッダーのみで構成されるため、パケットのサイズは極めて小さい。これは、TCPの初期輻輳ウィンドウ（initcwnd）の制限下でも、単一のセグメントで通信が完結することを意味する。
もしここで200 OKを返せば、データ転送のためにTCPウィンドウの拡大を待つ必要が生じ、レイテンシが跳ね上がる。304は、TLSハンドシェイクという重いコストを支払った後の通信において、サーバー・クライアント間の「同期」という最小限の仕事だけを完遂する、最もコスト効率の高いパケットなのだ。
サーバーサイド実装の勘所（Nginx設定例）
Nginx等のリバースプロキシでETagを適切に扱うには、単にデフォルト任せにするのではなく、ファイルのinodeや更新日時からハッシュを生成させる設定を吟味する必要がある。
NginxでETagを有効化し、ファイル変更時の再検証を最適化する設定
etag on;
複数のサーバーノード間でETagの整合性を保つため、
ファイル更新日時ではなく内容ベースのハッシュ化を検討すべき
※ただしCPU負荷とのトレードオフになる点に注意
gzip_vary on; # Varyヘッダーを付与し、キャッシュの誤認を防ぐ
—
セキュリティの深淵：ETagによる追跡リスク
ETagは強力だが、一方で「究極の追跡手段」にもなり得る。Cookieを無効化していても、サーバーがリクエストごとにユニークなETagを振れば、クライアントを特定する「ETag追跡」が可能だ。
セキュリティ専門家としての警告だが、プライバシー保護の観点から、動的に生成されるページに強力なETagを付与することは避けるべきである。また、クロスサイトリクエストフォージェリ（CSRF）やキャッシュ汚染（Cache Poisoning）の標的にならないよう、`Vary: Accept-Encoding` や `Vary: Authorization` を適切に設定し、キャッシュの区分け（Keyの分離）を厳密に行う必要がある。
—
実務におけるチューニング：TCPバッファとコネクションの再利用
HTTP/1.1の弱点は、TCPコネクションのヘッド・オブ・ライン・ブロッキング（HOLB）にある。しかし、`Keep-Alive`と条件付きGETを組み合わせることで、この弊害をある程度緩和できる。
- TCPバッファチューニング:
サーバーサイドでは `net.ipv4.tcp_slow_start_after_idle = 0` を設定し、アイドル状態からの復帰時にウィンドウサイズを縮小させないことで、条件付きGETの応答速度を最大化する。
- TLSハンドシェイクの軽減:
可能であればTLS 1.3への移行を強く推奨する。0-RTTハンドシェイクと組み合わせることで、条件付きGETのレイテンシは実質的にゼロに近づく。
結論：プロトコルを愛するということ
HTTP/1.1のETagは、一見すると枯れた技術だ。しかし、この「たった数バイトの比較」のために、我々はTCP/IPの挙動からカーネルのバッファ、暗号化のオーバーヘッドまでを考慮し、設計を突き詰めることができる。
単に動くコードを書くのではない。「なぜそのパケットがそのサイズなのか」「なぜそのヘッダーが必要なのか」。その問いに答えられる人間だけが、真にスケーラブルなネットワークアーキテクチャを構築できるのだ。
明日のインフラ改善には、ぜひ `curl -Iv` でレスポンスヘッダーを覗き、`304` が返ってくるまでのタイムラインを、ナノ秒単位で想像してみてほしい。そこには、エンジニアが設計した美しい論理構造が息づいているはずだ。
コメント