⭐️CDN（e.g. Akamai）のキャッシュ検証時の注意点

例えば、example.comのキャッシュ設定を変えたので動作テストをしたい場合。

前提: キャッシュはマシン（エッジサーバー）ごとに持っている。 別のマシンに当たると、さっきキャッシュさせたはずのものがMISSになる。

Akamai’s cache is not monolithic — each individual edge server has its own cache. — https://techdocs.akamai.com/property-mgr/docs/know-caching

以下のように別々のリクエストを投げた場合、それぞれのcurlで新しいTCPコネクション（3-way handshake + TLSハンドシェイク）を張り直す。

Akamaiクラスタ内のどのマシンに割り振られるかが接続の度に変わりうる。

=> 一連の流れでテストしたい場合に動作が安定しない可能性

curl url1
curl url2
curl url3

そこで、以下のようにリクエストをまとめる。

curl url1 url2 url3

同じTCPコネクションを使い回すため、必ず同じマシンにルーティングされる（ただし途中で接続が切られ、張り直すと別マシンになりうる）。

=> 動作テストの結果が安定する。

補足: HTTP/1.1 と HTTP/2

HTTP/1.1: 1本の接続で一度に1リクエスト。応答を待ってから次を送る（keep-alive で接続は使い回す）
HTTP/2: 1本の接続に、番号ラベル（ストリームID）付きの小包（フレーム）を混ぜて流せる。受け取り側は番号で仕分ける（多重化 / multiplexing）
- → 返事を待たずに次を送れるので、重いレスポンスに後ろが待たされない
ただし curl は -Z（--parallel）を付けないと、HTTP/2でも1つずつ送る

curl    url1 url2 url3:  送1 → 返1 → 送2 → 返2 → 送3 → 返3
curl -Z url1 url2 url3:  送1 送2 送3 → 返1〜3 が混ざって届く
                         └ 別々のリクエストを、返事を待たずに続けて送る

使い回されるのは同じホストへの接続だけ

確認:

curl -sv -o /dev/null -o /dev/null https://example.com/ https://example.com/ 2>&1 | grep -iE "connected to|re-using"

2本目で Re-using existing connection with host example.com と出れば、同じ接続を使い回している。

部分	意味
`-s`	進捗バーを消す
`-v`	接続・TLS・HTTPのやり取りを表示（標準エラーに出る）
`-o /dev/null`	本文を捨てる。URLごとに1つ要るので2個
`2>&1`	標準エラーを標準出力に合流させ、`grep` に渡す
`grep -iE "..."`	指定した文字を含む行だけ表示（`-i`: 大文字小文字を無視、`-E`: `"..."` の中の縦棒を「または」として扱う）

使い回さない場合（curlを分けて実行）:

curl -sv -o /dev/null https://example.com/ 2>&1 | grep -iE "connected to|re-using"
curl -sv -o /dev/null https://example.com/ 2>&1 | grep -iE "connected to|re-using"

→ 両方で Connected to が出る（毎回張り直し）。接続先IPも変わった（※example.com はCloudflareなので、Akamaiの挙動ではなく「張り直している」ことの証拠）。

教訓: CDNのキャッシュ挙動を検証するときは、同一接続内で連続アクセスする方法でないと、単発リクエストの結果だけでは誤った結論を出しかねない。