1xx ステータスコードという「静寂の中の対話」：プロトコル設計の深淵
ネットワークアーキテクチャの世界では、往々にして「データが流れている状態」こそが正常と見なされる。しかし、我々が対峙すべきは、パケットが届くまでの「沈黙」や、複雑なハンドシェイクの合間に生じる「微細な待機時間」の制御だ。
特にHTTP/1.1において、ステータスコード `1xx (Informational)` は地味な存在に見えるかもしれない。だが、この「暫定応答」こそが、高トラフィック環境におけるシステム効率の生命線である。今回は、`100 Continue` と `101 Switching Protocols` を軸に、その裏側にあるプロトコル挙動を解剖していく。
—
100 Continue：最適化された「先制攻撃」とTCPバッファの罠
`100 Continue` は、クライアントが大きなリクエストボディを送信する前に、サーバー側が「リクエストヘッダーを受け付けた。残りのボディを送っても良いか？」を判断するためのプロトコル上の握手だ。
パケットレベルの挙動とRTTのトレードオフ
クライアントが `Expect: 100-continue` をヘッダーに含めると、TCP層では以下の挙動が発生する。
1. ヘッダーのみの送信: クライアントはボディを含まずにHTTPヘッダーだけを送り出す。
2. 待機: サーバーからの `100 Continue` を待つ。
3. ボディ送信: 応答を受信してから、残りのペイロードを流し込む。
ここで重要なのは、RTT（Round Trip Time）が1回増えるという事実だ。レイテンシに厳しいアプリケーションでこれを不用意に使うのは愚策である。しかし、認証エラーやリソース制限で4xxを返すことが確定しているリクエストに対し、数メガバイトのペイロードを無駄に転送するコストを考えれば、`100 Continue` は「帯域の節約」という極めて現実的な防衛策となる。
カーネルレベルでのチューニング
もし貴方がLinuxカーネルで高負荷なサーバーを運用しているなら、`tcp_rmem` や `tcp_wmem` といったバッファ設定以上に、以下の観点を意識すべきだ。
- Expectヘッダーの無視: 多くのWebサーバー（Nginx等）はデフォルトで `100 Continue` を自動応答するが、アプリケーション層で検証が必要ない場合は、無駄なハンドシェイクを避けるため設定で抑制する判断も必要だ。
- タイムアウトの制御: クライアント側で `Expect` を投げた後の待機時間は、デフォルトで1〜2秒程度に設定されていることが多い。これを `curl` 等で計測する場合、以下のパラメーターで「サーバーがどれだけ早く応答できるか」をシミュレーションすることをお勧めする。
100 Continueの応答時間を計測し、サーバーの処理能力を可視化する
–expect100-timeout で待機時間を制御し、タイムアウト挙動を確認する
curl -v -H “Expect: 100-continue” \
–expect100-timeout 0.5 \
http://your-api-endpoint/upload
—
101 Switching Protocols：プロトコル移行の境界線
`101 Switching Protocols` は、HTTPの枠組みから別のプロトコル（主にWebSocket）へ切り替える際の「越境許可証」だ。
TLSハンドシェイクとの共生
WebSocketへのアップグレード（HTTP Upgrade）は、TLS（HTTPS）の上で行われる場合、より複雑な依存関係を持つ。
- HTTP/1.1: `Connection: Upgrade` ヘッダーと `Upgrade: websocket` を送信。
- サーバー: `101 Switching Protocols` で応答し、コネクションを維持したまま、以降の通信をWebSocketフレームに切り替える。
ここで注意すべきは、TLSセッションが継続されるという点だ。HTTP層で発生したTLSのオーバーヘッドは、WebSocket移行後も維持されるため、最初のハンドシェイクでいかに効率的な暗号スイート（TLS 1.3の推奨）を選択するかが、後の通信品質を決定づける。
—
セキュリティの観点：1xx応答が招く脆弱性
1xx応答を安易に実装すると、HTTP Request Smuggling や、中間者攻撃のリスクが浮上する。特に「リクエストの断片化」を許容する設計は、プロキシサーバーとバックエンドサーバー間での解釈の不一致を生む。
対策の要諦
1. プロキシの厳格化: 100 Continueを受け取った際、プロキシがバックエンドに即座に転送するのか、それともクライアントからのボディを待ってから統合するのか。この挙動の不一致が脆弱性の温床となる。
2. ヘッダー圧縮の悪用防止: HTTP/1.1ではヘッダー圧縮は存在しないが、HTTP/2へのアップグレードを101で行う場合、HPACKの動的テーブルのサイズ制限を適切に設定し、DoS攻撃を回避する必要がある。
—
まとめ：アーキテクトが目指すべき地平
ステータスコード `1xx` を使いこなすということは、プロトコルが「流れる川」であることを理解し、その流れを制御する「堰（せき）」を設計する行為に他ならない。
- 低レイテンシ環境: `100 Continue` は控え、クライアントサイドでのバリデーションを徹底する。
- 高帯域・大容量アップロード: `100 Continue` を積極的に活用し、不要なパケット流出を食い止める。
- リアルタイム通信: `101 Switching Protocols` を用いて、HTTPのオーバーヘッドを最短で脱却する。
教科書的な仕様をなぞるだけでは、インフラのパフォーマンスは1ミリも向上しない。パケットがTCPウィンドウの中でどう震え、TLSの暗号化によってどのように遅延が生じるか。その「物理的な感覚」をコードに落とし込めた時、貴方のネットワークは真に堅牢なものとなる。
さあ、次は貴方の環境のパケットキャプチャを開き、`100 Continue` がどれだけの時間を消費しているか、その目で確認してみてほしい。データは嘘をつかない。
コメント