「Expect: 100-continue」の深淵 —— 巨大なリクエストを捌くための礼儀と、レイテンシという名の代償
HTTP/1.1において、サーバーへ巨大なリクエストボディを投げつける際、私たちはしばしば「Expect: 100-continue」というヘッダーに遭遇する。これはネットワークエンジニアの視点で見れば、単なるヘッダー以上の意味を持つ。クライアントが「これから重い荷物を運ぶが、受け取る準備はあるか？」と問いかけ、サーバーが「許可する、送れ」と返す。この一連のハンドシェイクは、一見丁寧だが、裏を返せばRTT（Round Trip Time）を確実に一つ余分に消費する「諸刃の剣」だ。
今日は、この挙動をパケットレベルで解剖し、現代のインフラ環境でどのように最適化すべきか、その深淵を覗いてみよう。
1. 100-continueのパケット挙動：待機時間の正体
「Expect: 100-continue」が付与されたリクエストは、以下のプロセスで進行する。
1. Client -> Server: `Expect: 100-continue` を含んだヘッダーのみを送信。
2. Server -> Client: 受信したヘッダーを検証し、許可なら `HTTP/1.1 100 Continue` を返送。
3. Client -> Server: 待機していたリクエストボディの送信を開始。
このフローにおいて最も恐ろしいのは、サーバーからのレスポンスを待つ間のクライアント側の静寂だ。もしサーバー側の検証ロジックが重ければ、クライアントは無駄な待機時間を強いられる。最悪の場合、TCPのSlow Startと相まって、パケットの送信開始が遅れ、全体のスループットが劇的に低下する。
2. ネットワーク層・TLS層における最適化戦略
もしあなたがパフォーマンスを極限まで引き出したいのなら、以下の観点を意識して設計してほしい。
TCPバッファと初期ウィンドウ（IW）のチューニング
100-continueの待機時間中、TCP接続はアイドルのまま放置される。その後、実際にボディを送信する際にカーネルの`TCP_INIT_CWND`が10（またはそれ以上）に設定されているかを確認せよ。これにより、最初のラウンドで送信できるデータ量を最大化し、RTTのロスをカバーできる。
LinuxカーネルパラメータでのTCP最適化例
初期ウィンドウを大きくし、初回バーストのパケット数を増やす
ip route change default via 192.168.1.1 dev eth0 initcwnd 10
TLSハンドシェイクとの共存
TLS 1.3を使用している場合、0-RTTの恩恵を期待したくなるかもしれないが、100-continueとの組み合わせには注意が必要だ。リクエストボディがTLSのEarly Dataに含まれる場合、サーバー側の再送攻撃対策（Replay Protection）が100-continueのハンドシェイクと競合し、意図せぬ接続断を招く可能性がある。
3. なぜ「Expect: 100-continue」を無視する選択肢があるのか
多くのモダンなマイクロサービス環境では、クライアント側でこのヘッダーを明示的に「送らない」設定にすることが多い。
- 理由1: サーバーが4xxエラーを返す確率が極めて低い場合、100-continueの往復は単なるオーバーヘッドである。
- 理由2: 認証トークンの検証がAPIゲートウェイで行われる場合、ゲートウェイが即座に100-continueを返せるかどうかが重要。返せないなら、クライアントは無駄に待たされるだけだ。
もしあなたがGo言語でクライアントを実装しているなら、デフォルトの挙動を以下のように制御できる。
// Go言語におけるHTTPクライアントの挙動制御
transport := &http.Transport{
// 100-continueを待たずに即座にボディを送信する設定
// これによりRTTのロスを回避するが、サーバーがボディを受け入れられない場合はTCP RSTが飛ぶ
ExpectContinueTimeout: -1,
}
client := &http.Client{Transport: transport}
4. セキュリティ専門家への警告：DoSの温床
セキュリティの観点から無視できないのが、「100-continueを悪用したリソース枯渇攻撃」だ。
悪意あるクライアントが、大量の接続で `Expect: 100-continue` を送り続け、サーバー側で検証待ちのステートを保持させれば、サーバーのメモリやスレッドを容易に枯渇させることができる。
- 対策: `ExpectContinueTimeout` を適切に短く設定すること（通常1秒以下）。
- 対策: サーバー側でのヘッダーパース処理に厳格なタイムアウトを設け、不正な期待値を送るクライアントを即座に切断する。
総括：最適化の哲学
100-continueは、クライアントとサーバー間の「契約」だ。しかし、この契約が結ばれるまでの時間は、現代の超高速ネットワークにおいては贅沢なコストになり得る。
君のアプリケーションが「巨大なファイルを送る前に、認証やバリデーションで弾かれる可能性が高い」のであれば、100-continueは強力な武器になる。しかし、そうでないなら、このヘッダーを捨てて、TCPのパイプラインを最初から全開にする勇気も必要だ。
パケットは嘘をつかない。君の設計するネットワークの挙動を、`tcpdump`や`Wireshark`で覗き、レイテンシの波形と向き合ってみてほしい。その先には、教科書には載っていない「本物のチューニング」の世界が待っている。
コメント