タイムスタンプが狂うとき、システムは死ぬ——HTTP `Date`ヘッダーと時刻同期の深淵
ネットワークエンジニアとして現場に長くいると、「なぜかキャッシュが効かない」「APIの署名検証が通らない」という相談を死ぬほど受ける。その原因の8割は、複雑なロジックではなく、極めてプリミティブな「時刻」の不一致だ。
今回は、HTTP/1.1の礎であり、キャッシュ制御の要である `Date` ヘッダーについて、仕様の深淵と現場での実務的な教訓を共有したい。
—
1. RFC 7231が定める「厳格」な時刻フォーマット
HTTPの `Date` ヘッダーは、メッセージが生成された時刻を示す。RFC 7231で定義されているこの形式は、古くからの名残で極めて厳格だ。
Date: Wed, 21 Oct 2023 07:28:00 GMT
重要なのは、「必ずGMT（グリニッジ標準時）であること」そして「HTTP-date形式（IMF-fixdate）であること」だ。
- 曜日: 3文字の英字（Mon, Tue…）
- 日付: 2桁
- 月: 3文字の英字（Jan, Feb…）
- 年: 4桁
- 時刻: HH:MM:SS
もしあなたがAPIサーバーを自作する際、適当な文字列フォーマット（ISO 8601など）で出力してしまえば、キャッシュプロキシ（NginxやCDN）は日付を正しくパースできず、最悪の場合、キャッシュのTTL（有効期間）計算がバグり、古いコンテンツが永久に配信され続けるという事故につながる。
—
2. なぜ `Date` ヘッダーがキャッシュの「命綱」なのか
キャッシュの有効期限判定には `Expires` や `Cache-Control: max-age` が使われるが、これらは「サーバーがいつ生成したか（`Date`）」という基準点がないと機能しない。
もしサーバーの時計が30秒遅れていたらどうなるか。CDNは「まだ期限内だ」と判断し、クライアントには鮮度の落ちたデータが届く。逆に進んでいれば、キャッシュは即座に無効化され、オリジンサーバーにリクエストが集中する。いわゆる「キャッシュ・スタンピード」現象の引き金だ。
実務Tips:
大規模分散システムでは、全ノードで `NTP` や `Chrony` を使い、ミリ秒単位で時刻を同期させるのは「インフラエンジニアの嗜み」だ。もしクラウド環境（AWS/GCP等）を使っているなら、ホスト側の時刻同期サービスを疑う前に、自サーバーのシステムクロックがドリフトしていないか、まずは `chronyc tracking` コマンドで確認する癖をつけてほしい。
—
3. 実践：デバッグと確認の作法
コードを書く際、あるいはトラブルシューティングの際、生のHTTPヘッダーを確認するのは基本中の基本だ。
curl でヘッダーを確認する
まず、対象のサーバーがどのような `Date` を返しているかを確認する。
-I オプションでHEADリクエストを送り、Dateヘッダーを抽出
curl -I https://api.example.com | grep Date
出力例: Date: Wed, 21 Oct 2023 07:28:00 GMT
Python (Requests) でパースする
PythonでAPIを叩く際、時刻のズレを検知するコードを仕込んでおくと、運用が格段に楽になる。
import requests
from datetime import datetime, timezone
response = requests.get(“https://api.example.com”)
server_date_str = response.headers.get(“Date”)
RFC 7231形式をPythonのdatetimeに変換
server_date = datetime.strptime(server_date_str, “%a, %d %b %Y %H:%M:%S GMT”).replace(tzinfo=timezone.utc)
local_now = datetime.now(timezone.utc)
サーバーとローカルの時刻差を計算（極端な乖離があればアラートを出す）
delta = abs((local_now – server_date).total_seconds())
if delta > 5:
print(f”警告: サーバーとの時刻乖離が {delta} 秒発生しています！”)
—
4. 現場からの警鐘：HTTP/1.1以後の落とし穴
HTTP/2やHTTP/3へとプロトコルは進化したが、`Date` ヘッダーの重要性は変わっていない。特に現代のマイクロサービスアーキテクチャでは、複数のAPIを跨いでリクエストが飛び交う。
あるAPIサーバーが `Date` を正しく付与しなかったり、あるいはロードバランサーがヘッダーを書き換えて時刻をズラしたりすると、後続のシステムで「署名検証エラー」が多発する。Amazon S3の署名付きURLなどが代表例だが、これらは `Date` ヘッダーをリクエストの正当性確認に使用するため、数分ズレただけで「403 Forbidden」を叩き出す。
シニアエンジニアからのアドバイス:
「動いているから大丈夫」ではなく、「時刻がズレたとき、このシステムはどこで最初に悲鳴を上げるか」を常に想像すること。
1. NTP同期は全ノードで必須。
2. ログには常にJSTではなくUTCを記録する。
3. API設計では、Dateヘッダーだけに頼らず、リクエストボディにタイムスタンプを含めることも検討する。
HTTPはシンプルだが、そのシンプルさゆえに、基礎をおろそかにした者が最も痛い目を見るプロトコルだ。今日から、`Date` ヘッダーを見る目が少し変わることを期待している。
コメント