ETagとIf-None-Match：ネットワークの帯域を無駄にしない「賢い」キャッシュ検証術
こんにちは。ネットワークの現場で「なぜかキャッシュが効かない」「更新が反映されない」といった怪奇現象と戦い続けてきたエンジニアの皆さん、今日はお疲れ様です。
Web APIの設計やインフラ運用において、クライアントとサーバー間の無駄な通信を減らすことは、レスポンス速度の向上とサーバー負荷軽減という、いわば「Webの基本にして究極の最適化」です。その主役となるのが HTTP/1.1で標準化された `ETag` ヘッダーによるキャッシュ検証 です。
今回は、RFC 7232で定義されたこの仕組みを、現場で「動く」レベルの解像度で紐解いていきましょう。
—
1. なぜ「最終更新日時（Last-Modified）」だけでは不十分なのか？
多くの初心者が最初にぶつかる壁が「なぜ `Last-Modified`（時刻ベース）があるのに、わざわざ `ETag`（ハッシュベース）を使うのか？」という疑問です。
時刻ベースの検証には、2つの致命的な弱点があります。
- 解像度の限界: ファイルシステムやOSによっては、更新日時が秒単位までしか持てず、1秒間に複数回更新されるリソースを判別できない。
- 論理的な更新: 内容が変わっていないのに、何らかの処理でタイムスタンプだけが更新された場合、無駄な再ダウンロードが発生する。
これに対し、`ETag`（Entity Tag）は、リソースの内容そのものを指し示す「指紋」のようなものです。内容が変わらなければ、ETagも変わりません。これこそが、ネットワークエンジニアが信頼する「確実な識別子」なのです。
—
2. 304 Not Modifiedが生まれる「条件付きリクエスト」のフロー
ETagを使ったキャッシュ検証は、以下のシーケンスで進みます。
1. 初回リクエスト: サーバーが `ETag: “v123″` を返送。クライアントはこれをローカルに保存。
2. 再リクエスト: クライアントは `If-None-Match: “v123″` をヘッダーに付与して送信。
3. サーバー検証: サーバーは現在のリソースのETagと、クライアントの `If-None-Match` を比較。
4. 判定:
- 一致した場合: サーバーは `304 Not Modified` を返し、ボディ（実データ）は送信しない。
- 不一致の場合: サーバーは `200 OK` とともに新しいデータと新しいETagを送信。
この「ボディを返さない」という一点こそが、モバイル端末や低速回線において、体感速度を劇的に向上させる魔法なのです。
—
3. 実践：curlで挙動を追いかける
理論だけでなく、実際に手を動かしてパケットを覗いてみましょう。エンジニアの必携ツール `curl` を使えば一目瞭然です。
1回目：ETagを取得する
curl -v https://api.example.com/data
2回目：取得したETagを If-None-Match にセットして投げる
curl -v -H ‘If-None-Match: “ここに初回取得したETagの値を入れる”‘ https://api.example.com/data
この際、2回目のレスポンスヘッダーに `HTTP/1.1 304 Not Modified` が返ってきていることを確認してください。もし `200 OK` が返ってくるなら、サーバー側のキャッシュロジックが壊れているか、ETagの生成ロジックがリクエストごとに変わってしまっている可能性があります。
—
4. サーバー側での実装Tipsと注意点
Web APIを設計する際、ETagの生成には以下の点に注意してください。
- Strong ETag vs Weak ETag: `W/` で始まるETagは弱参照（意味的に等しければOK）です。厳密な一致が必要な場合はStrong ETagを使いますが、多くのAPIではハッシュ値（MD5やSHA-1の先頭数文字など）をそのままETagとして使うのが一般的です。
- Nginxでの設定例: 静的ファイルを配信する場合、Nginxは自動でETagを生成しますが、設定で強制的に無効にしていると効果がありません。
nginx.conf
location /static/ {
etag on; # ETagの生成を有効化（デフォルトはonですが明示も可）
expires 1h; # ブラウザキャッシュの有効期限も併せて設定
}
—
5. Fetch APIでフロントエンドから制御する
ブラウザのFetch APIでは、デフォルトでキャッシュ検証が行われることが多いですが、意図的に挙動を制御したい場合は以下のようにヘッダーを操作します。
// フロントエンドでの条件付きリクエスト例
const etag = localStorage.getItem(‘my-resource-etag’);
fetch(‘https://api.example.com/data’, {
headers: {
// サーバーが保持しているETagを伝えて「変わっていなければ返さないで」と指示
‘If-None-Match’: etag
}
}).then(response => {
if (response.status === 304) {
console.log(‘キャッシュが有効です。ローカルのデータを利用します。’);
} else {
// 200 OKの場合はETagを更新して保存
const newEtag = response.headers.get(‘ETag’);
localStorage.setItem(‘my-resource-etag’, newEtag);
return response.json();
}
});
—
最後に：エンジニアとしての矜持
ETagは非常にシンプルですが、だからこそ「適切に実装されているか」でシステムの質が露呈します。
もしあなたがAPIを設計する立場なら、必ずリソースごとに一意なETagを返す設計にしてください。もし運用する立場なら、まずは `curl -v` を叩いて、304が正しく返ってきているかを確かめることから始めましょう。
ネットワーク上の無駄な往復を一つ減らす。その積み重ねが、数百万ユーザーが使うシステムの「軽快さ」というユーザー体験を作り上げます。ぜひ、今日からあなたのAPIにもこの「賢い検証」を組み込んでみてください。
それでは、また現場でお会いしましょう。
コメント