ETagと条件付きリクエスト：304 Not Modifiedが引き起こすネットワークの静かな革命
ネットワークエンジニアとして現場に立つと、往々にして「帯域幅」という物理的な制約よりも、「ラウンドトリップ（RTT）」という論理的な壁に頭を悩ませることになる。クライアントとサーバーの間で交わされる無駄なデータ転送をいかに削ぎ落とすか。その核心にあるのが、HTTP/1.1で標準化された`ETag`と`If-None-Match`を用いたキャッシュ検証の仕組みだ。
今回は、単なるヘッダーの説明を超え、パケットレベルの挙動からLinuxカーネルのTCPスタックとの相関まで、インフラの深淵を覗いていく。
なぜLast-Modifiedでは足りないのか
HTTP/1.0時代の`Last-Modified`ヘッダーによる検証は、あくまで「時刻」ベースだ。しかし、分散システムにおいて厳密な時刻同期は悪夢そのものだ。また、1秒未満の更新や、中身は変わらないがタイムスタンプだけが更新されるようなケースでは、無駄なデータ転送（HTTP 200 OK）が発生してしまう。
そこで登場するのが`ETag`（Entity Tag）である。これはリソースに対する一意な識別子（ハッシュ値など）であり、サーバーは「このリソースの状態はこれだ」という証明書をクライアントに渡す。
パケットレベルの挙動：無駄なペイロードの削減
クライアントがキャッシュを持っている場合、次のリクエストでは`If-None-Match`ヘッダーにそのETagを含める。
クライアントからサーバーへの問い合わせ
GET /api/v1/resource HTTP/1.1
Host: api.example.com
If-None-Match: “a1b2c3d4e5f6” # キャッシュしているETagを送出
サーバー側で`If-None-Match`の値と現在のリソースのETagを比較し、一致すれば、サーバーはデータ本体を送らずに以下のレスポンスを返す。
サーバーからの回答
HTTP/1.1 304 Not Modified
Date: Wed, 25 Oct 2023 10:00:00 GMT
ETag: “a1b2c3d4e5f6”
ここでレスポンスボディは空。TCPのペイロードは極小化される。
この「304 Not Modified」は、アプリケーションレイヤーだけでなく、トランスポート層にとっても極めて重要だ。ボディが空であることは、TCPの送信バッファに詰め込むデータが減ることを意味し、結果として輻輳制御アルゴリズム（CubicやBBR）におけるスループットの枯渇を防ぐ。
パフォーマンスを極限まで引き出すためのインフラ設定
ETagを効果的に運用するためには、サーバー（Nginx等）のチューニングが不可欠だ。特に、ETag生成時の計算コストを無視してはならない。
NginxでのETag最適化設定例
Nginxの設定ファイル
http {
# ETagの計算コストを抑えるために、inodeとmtimeに基づくデフォルトETagに加え、
# 適切なCache-Controlを組み合わせる。
etag on;
# 低速なクライアントが接続を占有するのを防ぐため、keepaliveを調整
keepalive_timeout 65;
# 圧縮（Gzip）との併用：圧縮した後にETagを計算するか、
# 圧縮前のハッシュを使うかを慎重に設計する必要がある。
gzip on;
}
トランスポート層とセキュリティの深い関係
TLSハンドシェイクのオーバーヘッドを考えれば、304レスポンスの恩恵はさらに際立つ。TLS 1.3であればRTTは最小化されているが、それでもTCPの3ウェイ・ハンドシェイクとTLSのネゴシエーションにはコストがかかる。ETagによるキャッシュ検証が成功すれば、その接続（Connection）を再利用（Keep-Alive）することで、新たなハンドシェイクのコストを回避しつつ、最小限のパケットでコンテンツの鮮度を保証できる。
セキュリティの落とし穴：ETagの「強さ」と「弱さ」
ETagには「強（Strong）」と「弱（Weak）」の識別子がある。
- 強ETag (`”…”`): バイト単位で完全一致することを保証する。
- 弱ETag (`W/”…”`): コンテンツのセマンティクスが同じであることを示す。
セキュリティ専門家として忠告しておくが、ETagを誤った実装（例えば、ユーザー識別子をハッシュに含めるなど）に使うと、「ETagによる追跡（Fingerprinting）」というプライバシー侵害を招く。ETagはあくまで「リソースのバージョン」を識別するためだけに使うべきだ。
Linuxカーネルによる最適化：TCPバッファのチューニング
ETagによってパケットサイズを削減しても、サーバーのTCPスタックが適切に設定されていなければ、遅延は解消されない。特に、多くの304レスポンスを高速に返すためには、`tcp_notsent_lowat` のチューニングが効く。
送信キューに溜まる未送信データの閾値を制御し、RTTの増大を防ぐ
sysctl -w net.ipv4.tcp_notsent_lowat=16384
この設定は、TCPの送信バッファにデータが溜まりすぎないように抑制し、アプリケーションが新しいリクエストを処理する際にバッファの空きを確保しやすくするものだ。大量の条件付きリクエストを捌くAPIサーバーにおいては、このわずかなチューニングが「レスポンスのキレ」を左右する。
まとめ：ネットワークの美学
ETagと304 Not Modifiedは、HTTP/1.1という枯れた技術の中に息づく、極めて合理的な仕組みだ。現代のWebはHTTP/3やQUICが主流となりつつあるが、パケットを無駄にせず、クライアントとサーバーの間の「情報の同期」を最小限のオーバーヘッドで行うという思想は、どのプロトコルにも共通する普遍的な価値である。
インフラエンジニアとして、単に「動く」ことを目指すのではなく、パケットがネットワークを流れる瞬間の「無駄のなさ」に美しさを感じられるようになれば、あなたのシステムはより堅牢で、より速いものへと進化するはずだ。
コメント