HTTP/1.xの「影の主役」：1xx系ステータスコードが制御するプロトコルの境界線
ネットワークエンジニアとして、多くの開発者がHTTPのステータスコードを「200 OK」か「404 Not Found」の二元論で語る姿を耳にする。しかし、OSI参照モデルの深層でパケットが交錯する現場において、真に洗練されたシステムを設計する者は、1xx系の「情報レスポンス（Informational Responses）」を巧みに操る。
これは単なるヘッダーのやり取りではない。TCPの輻輳制御（Congestion Control）やTLSハンドシェイクのオーバーヘッドを極限まで削ぎ落とすための、非常に高度なハンドシェイクの儀式なのだ。
—
1. 100 Continue：巨大なペイロードを「投げる前」の保険
もしあなたが数メガバイトのファイルをPOSTしようとしているとき、サーバー側が認証エラーやバリデーション失敗で接続を即座に切断したらどうなるか？ クライアントは貴重な帯域とTCPバッファを消費し、無駄なパケットをネットワークに送り出したことになる。
`100 Continue` は、クライアントがリクエストボディを送信する前に「このリクエストを処理する準備はあるか？」とサーバーに問いかけるための、いわば「先行確認の握手」だ。
パケットレベルの挙動と最適化
この挙動を有効にするには、クライアントは `Expect: 100-continue` ヘッダーを付与する。
1. Client -> Server: ヘッダーのみのHTTPリクエスト（TCP送信）。
2. Server -> Client: `100 Continue` のレスポンス。
3. Client -> Server: 本体のペイロード送信。
ここで重要なのは、RTT（Round Trip Time）の削減だ。低遅延が求められる環境では、サーバーがこのレスポンスを返すまでの時間を計測し、タイムアウト値を微調整する必要がある。もし `tcp_init_cwnd` （初期輻輳ウィンドウ）が適切に設定されていないと、このハンドシェイク自体がボトルネックになりかねない。
カーネルパラメーターの最適化（参考値）
TCPウィンドウのスケーリングを有効化（大容量転送の前提）
sysctl -w net.ipv4.tcp_window_scaling=1
バッファサイズの自動調整（高スループット環境）
sysctl -w net.ipv4.tcp_rmem=”4096 87380 16777216″
sysctl -w net.ipv4.tcp_wmem=”4096 65536 16777216″
—
2. 101 Switching Protocols：静寂の切り替え
`101 Switching Protocols` は、HTTPの制約から脱却し、WebSocketのような双方向通信へシームレスに移行するためのゲートウェイだ。このステータスコードが返された瞬間、HTTPのセマンティクスは終了し、トランスポート層の上で別のプロトコルが支配権を握る。
セキュリティの観点から最も警戒すべきは、このスイッチング時の プロトコル・ダウングレード攻撃 だ。
- TLSの再利用: TLS 1.3のハンドシェイクが完了している状態であれば、そのトンネルをそのまま流用する。もしここで不十分な暗号スイート（古いTLSバージョン）が許容されていると、中間者攻撃の餌食となる。
- アップグレード・ヘッダーの検証: `Upgrade: websocket` を投げた際、サーバー側は必ず `Connection: Upgrade` を含めて応答しなければならない。これを厳密にバリデーションしないプロキシは、HTTPスマグリングの脆弱性を生む温床となる。
—
3. 実務的な実装の勘所：クライアント側の挙動
多くの中級エンジニアは、1xx系のレスポンスを「無視」するライブラリを使いがちだ。しかし、高負荷なインフラを支えるなら、ライブラリの挙動をオーバーライドしてでも、このシグナルを拾うべきだ。
Goによる100 Continueハンドリングの例
req, _ := http.NewRequest(“POST”, “https://api.example.com/upload”, body)
req.Header.Set(“Expect”, “100-continue”)
// クライアント側で100 Continueを受け取った際のロジックを制御
client := &http.Client{
Transport: &http.Transport{
ExpectContinueTimeout: 1 time.Second, // サーバーからの反応待ち時間を厳密に設定
},
}
// ここでレスポンスを待機し、タイムアウトすれば即座に接続をクローズしてリトライへ
—
4. アーキテクトへの警鐘：なぜ今、1xx系なのか
現代のウェブアーキテクチャでは、HTTP/2やHTTP/3（QUIC）が主流だ。しかし、ストリーム多重化が行われるHTTP/2以降でも、1xx系は依然として重要だ。なぜなら、「制御プレーン」と「データプレーン」を論理的に分離できるからだ。
リソースを消費する前に接続の正当性を確認し、プロトコルを動的に最適化する。これは単なる仕様書上のルールではなく、パケットが物理的な距離を移動する際の「コスト」を最小化するためのエンジニアリングそのものだ。
もしあなたが現在、APIのレイテンシーに悩んでいるなら、プロファイルデータからアプリケーションロジックを覗く前に、まずパケットキャプチャを開いてほしい。TCPのフラグの中に、あなたのシステムを高速化する「100 Continue」のヒントが隠されているはずだ。
ネットワークは嘘をつかない。プロトコルを深く理解する者だけが、その沈黙の背後にある最適化の余地を読み解くことができるのである。
コメント