賢者のための通信術：`Expect: 100-continue` が切り拓く、肥大化するリクエストの最適化戦略
現代のマイクロサービスアーキテクチャにおいて、我々は常に「帯域」と「レイテンシ」という二つの悪魔と対峙している。特に数MBから数GBに及ぶファイルアップロードを扱う際、何も考えずにリクエストを放り投げるのは、無策な砲撃に等しい。
「とりあえず送ってみる」というアプローチが、認証エラーやバリデーション失敗で徒労に終わったとき、その無駄なパケットが消費したRTT（往復時間）と帯域は、二度と戻ってこない。ここで登場するのが、HTTPの隠れた知恵袋、`Expect: 100-continue` だ。
1. `Expect: 100-continue` の本質：信頼と検証のハンドシェイク
このヘッダーの意図は極めて明快だ。クライアントは「これから大きなデータを送るが、受け入れる準備はできているか？」とサーバーに問いかけ、サーバーが「良し、送れ（100 Continue）」と応答して初めて、ボディの送信を開始する。
パケットレベルでの挙動
このハンドシェイクは、TCPの輻輳制御アルゴリズム（特にスロースタートフェーズ）と深く関わっている。
1. Client -> Server: `POST /upload` リクエストを送信（ヘッダーのみ）。`Expect: 100-continue` を付与。
2. Server -> Client: 認証やゲートウェイのバリデーションを確認し、`100 Continue` を返送。
3. Client -> Server: 本体のペイロード（ボディ）を送信。
もしサーバーが拒否すべきリクエストであれば、クライアントが数MBのデータを回線に乗せる前に `4xx` や `401 Unauthorized` を返すことができる。これは無線環境や高レイテンシ環境において、致命的な「帯域の浪費」を防ぐ強力な武器となる。
2. インフラアーキテクトが直面する「罠」とチューニング
しかし、この仕組みを安易に導入してはいけない。特にTLSハンドシェイクやTCPバッファが絡む領域では、慎重な調整が必要だ。
RTTのジレンマ
`Expect: 100-continue` は、理論上「余分な1往復（RTT）」を消費する。もしサーバーのレスポンスが極めて速い環境（同一DC内など）であれば、この1往復がボトルネックになる場合がある。
これを解決するためのアーキテクチャ上の工夫として、多くのクライアントライブラリは「タイマー」を実装している。
Pythonのrequestsライブラリにおけるタイムアウト戦略の例
import requests
100-continueの応答を待つ際の最大待機時間を設定する
これにより、サーバーが即座に反応しない場合でも、
一定時間後に強制的にボディ送信を開始し、デッドロックを防ぐ
response = requests.post(
url=”https://api.example.com/upload”,
data=large_file_generator,
headers={“Expect”: “100-continue”},
timeout=(3.05, 10) # connect timeout, read timeout
)
TCPバッファとウィンドウサイズ
`Expect` を使用する場合、カーネルの `tcp_wmem` （送信バッファ）の設定が重要になる。サーバーが `100 Continue` を返すまでの間、クライアント側のアプリケーション層はデータ送信を控えるが、TCPスタックレベルでのフロー制御が適切でないと、バッファが溢れる可能性がある。
大規模なアップロードを想定するなら、Linuxカーネルパラメーターでバッファを拡張しておくべきだ。
sysctlでのバッファ拡張例
高帯域・高レイテンシ環境でスループットを最大化する
net.ipv4.tcp_wmem = 4096 65536 16777216 # 最小・デフォルト・最大値を設定
net.core.wmem_max = 16777216
3. セキュリティ：未知の脆弱性への対策
`Expect: 100-continue` は、セキュリティの観点では「先行検証」の役割を果たす。しかし、攻撃者はこれを利用して、DoS攻撃を仕掛けることも可能だ。
- リソース枯渇攻撃: 攻撃者が大量の「Expect」リクエストを送り続け、サーバーのリソース（メモリや接続スロット）を専有させる。
- 対策: `LimitRequestFieldSize` や `LimitRequestBody` といったサーバー側の制限を厳格に適用すること。また、リバースプロキシ（Nginxなど）側で `proxy_expect_100_continue` を適切に制御し、バックエンドに負荷を逃がさない設計が求められる。
Nginxでの制御例
バックエンドへの期待ヘッダーの伝播を制御する
location /upload {
proxy_set_header Expect $http_expect;
proxy_http_version 1.1; # HTTP/1.1の維持が必須
# 必要に応じて、ここでバッファリング設定を調整する
proxy_request_buffering on;
}
結論：ネットワークの「呼吸」を制御せよ
`Expect: 100-continue` は、ネットワークの呼吸を整えるための高度な調律だ。何も考えずに全てのデータを流し込むのは「叫び声」を上げているのと同じだが、適切なハンドシェイクは「対話」を生む。
- 小規模なリクエスト: 不要なRTTを増やすだけなので、利用を避ける。
- 巨大なバイナリデータ: 認証・認可の失敗リスクが高いため、必須で実装する。
プロトコルの仕様を理解し、自身のインフラのRTTとスループットの特性を把握すること。それが、世界最高峰のインフラアーキテクトに求められる「パケットへの敬意」である。
次回のチューニングでは、ぜひパケットキャプチャを開き、`100 Continue` が正しく発行され、TCPのウィンドウサイズが健全に推移しているかを自分の目で確認してほしい。そこには、数字だけでは見えない、ネットワークの美しい挙動が刻まれているはずだ。
コメント