100 Continueの深淵：プロトコルの「作法」が極限のレイテンシを制する
HTTPステータスコードの「1xx（Informational）」を、単なる「中間応答」として片付けていないだろうか。特に `100 Continue` は、現代のマイクロサービスアーキテクチャや大規模なデータ転送において、TCPのスロースタートやRTT（Round Trip Time）のオーバーヘッドを最適化するための極めて洗練された「握手」である。
今回は、この1xx系ステータスコードがパケットレベルでどのような挙動を示し、インフラエンジニアがいかにしてこれを制御すべきか、その深層を紐解く。
—
1. 100 Continue：無駄なペイロードを送信しないための「意思確認」
巨大なファイルアップロードや、認証情報の検証が必要なPOSTリクエストを想像してほしい。クライアントが数メガバイトのデータをいきなりTCPストリームに流し込み、サーバー側で「認証エラー」や「リクエストエンティティ過大」と判定されて切断されたらどうなるか。その数メガバイトの通信と、それに費やしたサーバーのバッファメモリは完全に無駄になる。
`100 Continue` は、クライアントがヘッダーのみを送信し、サーバーが `Expect: 100-continue` を解釈して「準備完了」の応答を返してから初めてボディを送信させるための、いわば「お見合い」のプロトコルだ。
パケットレベルの挙動
1. クライアント: `Expect: 100-continue` を含んだHTTPヘッダーを送信。
2. サーバー: リクエストヘッダーを解析。受け入れ可能であれば `100 Continue` を送信。
3. クライアント: サーバーからの応答を確認後、初めてペイロード（ボディ）を送信。
これにより、帯域幅の無駄遣いを防ぎ、特に高レイテンシな環境下でのパケットロスを最小化できる。しかし、クライアント側がサーバーの応答を待たずに送信を開始してしまう「デフォルトの挙動」が、実はパフォーマンスのボトルネックになるケースも多い。
—
2. 101 Switching ProtocolsとTLSハンドシェイクの最適化
`101 Switching Protocols` は、HTTP/1.1の接続をWebSocketやHTTP/2にアップグレードするためのトリガーだ。ここで注意すべきは、トランスポート層における「TLSハンドシェイクのオーバーヘッド」である。
プロトコルを切り替える際、既存のTCPコネクションを維持したままレイヤーを上げるため、新たなTCPの3ウェイ・ハンドシェイクは不要だが、TLSのセッション再開（Session Resumption）が効いていないと、暗号化のネゴシエーションでRTTが余計に消費される。
NginxでWebSocketへのアップグレードを最適化する設定
map $http_upgrade $connection_upgrade {
default upgrade;
” close;
}
server {
location /ws/ {
proxy_pass http://backend;
# プロトコル切り替え時のヘッダー制御
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
# タイムアウトを短くし、枯渇したコネクションを早期解放する
proxy_read_timeout 60s;
proxy_send_timeout 60s;
}
}
—
3. インフラエンジニアが知るべき「1xx」の罠と回避策
TCPバッファチューニングとRTTの削減
`100 Continue` を待機する際、クライアント側のTCPバッファが小さいと、サーバーの応答待ちの間にウィンドウサイズが埋まり、後続のパケットがドロップする。特に、高スループットを求める場合は、OS側のTCPスタックを調整する必要がある。
Linuxカーネルパラメータの最適化（sysctl.conf）
広帯域・高レイテンシ通信（BDP: Bandwidth Delay Product）を見越したバッファ拡大
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
TCP Fast Openを有効化し、3ウェイ・ハンドシェイクの遅延を削減
net.ipv4.tcp_fastopen = 3
セキュリティリスク：HTTP Request Smuggling
`100 Continue` を悪用した脆弱性に注意が必要だ。フロントエンドのプロキシとバックエンドのサーバーで `Expect` ヘッダーの処理が一致していない場合、リクエストの境界が曖昧になり、悪意のあるペイロードが後続のリクエストに混入する可能性がある。
- 対策: フロントエンドのロードバランサーで `Expect: 100-continue` を適切にフィルタリングし、バックエンドへ安易にパススルーしない設定が必須である。
—
4. 結び：プロトコルの「静かなる対話」を設計する
HTTPステータスコードの1xxは、単なる「進捗通知」ではない。それは、通信の両端が互いの状態を同期させ、リソースを効率的に活用するための「静かなる対話」である。
現代のインフラ構築において、アプリケーションコードのチューニング以上に、こうした「プロトコルの作法」を理解し、ネットワークの特性に合わせてチューニングを施すことこそが、真のパフォーマンス向上への近道だ。
次に `100 Continue` を見かけたときは、それが単なる中間応答ではなく、あなたのネットワークを最適化するために用意された、プロトコルの知恵の結晶であることを思い出してほしい。その時、あなたのシステムは、より堅牢で、より速い、真のプロフェッショナル仕様へと進化を遂げるはずだ。
コメント