100 Continueの流儀：肥大化するリクエストと、ネットワークの「一呼吸」を巡る最適化
ネットワークエンジニアとして現場を渡り歩いていると、「HTTP/1.1の `100 Continue` は古臭い」という声を聞くことがある。しかし、それは大きな誤解だ。現代のマイクロサービスアーキテクチャや、巨大なペイロードを伴うAPIゲートウェイの設計において、この「サーバーへの事前打診」というプロトコル設計は、単なる互換性の遺物ではなく、極限のパフォーマンスとリソース保護のための武器となる。
今日は、パケットレベルの挙動からカーネルのバッファチューニングまで、この控えめだが強力なヘッダーの真価を解剖していこう。
—
1. 100 Continueのパケットフロー：無駄なRTTをどう回避するか
クライアントが巨大なファイルをPOSTする際、サーバーが認証エラーやバリデーションエラーを返すのに、数MBのボディを受信し切るまで待つのはあまりに非効率だ。ここで `Expect: 100-continue` が登場する。
内部挙動のタイムライン
1. クライアント: `Expect: 100-continue` を含むヘッダーのみを送信。
2. 中間ノード/サーバー: リクエストの妥当性をヘッダー段階で判断。
3. サーバー: `100 Continue` レスポンスを返送（ここでTCPウィンドウは維持される）。
4. クライアント: 本体のボディ送信を開始。
もしサーバーが `4xx` や `5xx` を返せば、クライアントは残りの巨大なボディを送信することなく接続をクローズできる。これは単なる通信量の削減ではない。バックエンドのストレージI/Oやメモリバッファの枯渇を防ぐ、立派なDDoS対策の一環でもあるのだ。
—
2. TLSハンドシェイクとRTT削減の物理的限界
ここで注意すべきは、`100 Continue` が「往復」を伴うという点だ。TLSハンドシェイクが完了した直後にこのフローが走ると、ネットワークの遅延（RTT）が顕著に効いてくる。
- 最適化の視点:
- TCP Fast Open (TFO): 最初のSYNパケットにデータを載せるTFOを有効にすることで、ハンドシェイクのオーバーヘッドを劇的に下げられる。
- カーネルチューニング: `sysctl -w net.ipv4.tcp_fastopen=3` を設定し、信頼できるクライアントからの接続でハンドシェイクとリクエスト開始を同期させるのが理想だ。
—
3. 実践：Nginxにおける最適化設定
多くの現場で見落とされているのが、Nginxにおける `client_body_buffer_size` との兼ね合いだ。`100 Continue` を正しくハンドリングするには、サーバー側のバッファ戦略を明確にする必要がある。
Nginxの設定例
http {
# クライアントがボディを送る前に、ヘッダーで即座に判断する
# 期待されるサイズがバッファを超えると、サーバーは即座にレスポンスを返す
client_body_buffer_size 128k;
server {
location /upload {
# 100-continueの処理を有効化（デフォルトはon）
# これを適切に設定することで、バックエンドへの不要なストリームを遮断する
expect_100_continue on;
}
}
}
知見: `client_body_buffer_size` を絞りすぎると、`100 Continue` を待たずにサーバーがボディをディスクへ書き出そうとする。I/O負荷を避けるなら、このバッファと `100 Continue` の閾値は密接に連動させるべきだ。
—
4. セキュリティ専門家が見る「パケットの罠」
`100 Continue` は、攻撃者にとっても興味深い対象となる。「Expect Header Injection」や、サーバーを待機状態にさせる「Slowloris風の枯渇攻撃」の標的になり得るからだ。
- 脆弱性の回避策:
- タイムアウトの厳格化: `client_header_timeout` と `client_body_timeout` を極めて短く設定する。例えば `10s` 以上待つ必要はない。
- 最大ペイロードサイズの制限: `client_max_body_size` を設定し、`100 Continue` を悪用した巨大リクエストによるメモリフラグメンテーションを防ぐ。
—
5. 結論：HTTP/2, HTTP/3時代の100 Continue
「HTTP/2以降はストリーム多重化があるから不要ではないか？」という問いは、半分正解で半分間違いだ。確かにバイナリフレームによる最適化は強力だが、アプリケーション層での「事前チェック」というロジックは、プロトコルの進化とは独立したビジネスロジック上の最適化である。
ネットワークアーキテクトとして言えるのは、「低レイヤーのプロトコル最適化に甘えず、アプリケーション層のフロー制御をプロトコルレベルで設計せよ」ということだ。
`100 Continue` は、ネットワークの混雑状況やサーバーの負荷を考慮しつつ、静かに、しかし確実に通信の最適化を支えている。この小さな「一呼吸」を理解し、適切にチューニングできるエンジニアこそが、真にスケーラブルなインフラを構築できると私は信じている。
次は、TCPウィンドウサイズとHTTP/2のフロー制御ウィンドウをどう調和させるか、その深淵を覗いてみることにしよう。
コメント