「とりあえずキャッシュ」からの脱却。ETagとIf-None-Matchで実現する、削ぎ落とされた通信最適化
ネットワークの現場に長くいると、「通信量を減らせ」という指示を耳にタコができるほど聞かされる。CDNを入れる、圧縮をかける――それらはもちろん重要だ。だが、エンジニアとしてもう一段階深淵に触れるなら、「そもそも送る必要のないパケットを送らない」という思想を設計に組み込むべきだ。
HTTP/1.1で導入された`ETag`と`If-None-Match`は、まさにその思想の体現である。今回は、泥臭いトラブルシューティングにも耐えうる、この「条件付きリクエスト」の真髄を紐解いていこう。
—
ETagとは何か？：一意な「指紋」による識別
`ETag`（Entity Tag）は、サーバー上の特定リソースに対する「指紋」だ。最終更新時刻（`Last-Modified`）で管理する古い手法もあるが、あれは1秒未満の更新を捉えられなかったり、ファイルの中身が変わっていないのにタイムスタンプだけが変わるようなケースでキャッシュが台無しになる。
その点、ETagはリソースの内容をハッシュ化した文字列などを用いる。つまり、「中身が同じなら、たとえ生成時刻が違っても同一リソース」とみなせるのだ。
通信シーケンス：304 Not Modifiedという「沈黙の合意」
クライアントが一度リソースを取得すると、ブラウザはそのETagを記憶する。次に同じリソースを要求する際、クライアントはこう叫ぶ。
> 「俺はこいつのETag（`”12345″`）を持ってるんだ。もし中身が変わってないなら、わざわざデータを送り直さなくていいぜ？」
これが `If-None-Match` ヘッダーの役割だ。サーバー側は、現在のリソースのETagと照らし合わせ、変化がなければ 304 Not Modified を返す。この時、ボディ（中身のデータ）は空だ。この「送信データゼロ」という恩恵が、高トラフィックなAPIやWebサイトにおいてどれほどの帯域を救うか、想像してみてほしい。
—
実践：ETagを活用したWeb APIの設計
では、実際にどのようなやり取りが発生しているのか。curlを使ってその挙動を剥き出しにしてみよう。
1. 初回リクエスト（ステータス 200 OK）
-i オプションでレスポンスヘッダーを表示する
curl -i https://api.example.com/data/config
レスポンスが返ってくると、ヘッダーに以下のような記述があるはずだ。
`ETag: “v1-abcdefg”`
2. 二回目以降の確認（ステータス 304 Not Modified）
キャッシュが有効な場合、クライアントはヘッダーを付与して再送する。
If-None-Matchに前回のETagを指定する
curl -i -H ‘If-None-Match: “v1-abcdefg”‘ https://api.example.com/data/config
サーバーのログやパケットキャプチャを確認してほしい。レスポンスは `HTTP/1.1 304 Not Modified` となり、`Content-Length` は0か、あるいは最小限のヘッダーのみになっているはずだ。
—
現場のTips：実装と運用の落とし穴
1. ETag生成のコストを軽視するな
ETagを生成するために、毎回巨大なデータベースをスキャンしたり、複雑な計算をしていては本末転倒だ。推奨されるのは、ファイルのMD5ハッシュを保持するか、DBのレコード更新フラグをETagとして利用すること。計算コストと通信削減のトレードオフを常に見極めるのがアーキテクトの腕の見せ所だ。
2. 強弱（Strong/Weak）の罠
ETagには「強（Strong）」と「弱（Weak）」がある。
- Strong ETag (`”…”`): 内容がビット単位で完全に一致することを保証する。デフォルトはこれだ。
- Weak ETag (`W/”…”`): 内容が「意味的に」等価であることを示す。Webサーバーが圧縮をかけた際などに自動生成されることが多い。
デバッグ中に `W/` というプレフィックスを見つけても「バグかな？」と焦らないこと。それは「バイト単位では違うかもしれないが、意味は同じだからキャッシュを使っていいぞ」というサーバーの優しさだ。
—
さあ、コードで確認しよう（Python/Flaskの例）
小規模なAPIを構築する際、Flaskであれば以下のようにETagを考慮したキャッシュ制御を実装できる。
from flask import Flask, make_response, request
app = Flask(__name__)
@app.route(‘/resource’)
def get_resource():
# 実際はここでDBのハッシュやバージョンを取得
current_etag = ‘”v1-abcdefg”‘
# クライアントからのIf-None-Matchを確認
if request.headers.get(‘If-None-Match’) == current_etag:
# 一致すれば中身を送らず304を返す
return ”, 304
response = make_response(“ここにリソースの本体データが入る”)
response.set_etag(current_etag) # ETagをヘッダーにセット
return response
—
最後に：ネットワークアーキテクトからの助言
ETagの設計は、単なるプロトコルの仕様確認ではない。「クライアントとの信頼関係の構築」だ。
サーバーが賢く振る舞い、クライアントが無駄な通信を控える。この洗練されたやり取りが積み重なって、インターネットは今日も安定して動いている。もし君が現在、APIのレスポンスが遅い、あるいは転送量が増大して困っているなら、まずはこの「条件付きリクエスト」が適切に行われているか、ブラウザのデベロッパーツールを開いて確認することから始めてほしい。
無駄な通信を削ぎ落とす美学。それこそが、シニアエンジニアへの第一歩だ。
コメント