HTTPステータスコード「1xx」の正体：なぜ通信のプロは「100 Continue」を愛するのか
ネットワークエンジニアとして現場に立っていると、200 OKや404 Not Foundといった「結果」ばかりに目が向きがちだ。しかし、HTTPの奥深さはその「準備段階」や「交渉」のプロセスにある。
今回は、多くのエンジニアが見過ごしがちな「1xx（Informational）」ステータスコードにスポットを当てたい。RFC 7231に定義されるこの領域は、クライアントとサーバーが「本番のデータ転送を始める前に、一度握手を交わす」ための極めて重要なハンドシェイクだ。
1xxの存在意義：ただの「中間報告」ではない
1xx系のステータスコードは、サーバーがリクエストを一部受け取ったが、処理を完了するにはまだ「何らかのステップ」が必要であることを示す。
特筆すべきは、これらは最終的なレスポンスではないということだ。クライアントは1xxを受け取った後も、サーバーからの最終的な（2xxや4xxなどの）レスポンスを待ち続けなければならない。ここを理解していないと、プロトコルの挙動を誤解し、不必要なタイムアウトや再送を招くことになる。
100 Continue：巨大なペイロードを賢く扱うための切り札
API設計において、数MBから数GBに及ぶファイルをPOSTする場合を想像してほしい。認証エラーで即座に拒否されるべきリクエストに対し、巨大なボディをすべて送信し終えてから「401 Unauthorized」が返ってきたらどうだろう？帯域の無駄遣いどころの騒ぎではない。
ここで輝くのが `100 Continue` だ。
通信シーケンスのリアル
1. クライアント: ヘッダーに `Expect: 100-continue` を含めてリクエストを送信。
2. サーバー: ヘッダーを解析し、認証やバリデーションが可能なら `100 Continue` を即座に返す。
3. クライアント: 100を受け取って初めて、本体（ボディ）の送信を開始する。
もしサーバーがこのリクエストを受け入れたくない場合、ボディを受信する前に `4xx` や `5xx` を返して接続を断ち切れる。これが「ネットワーク負荷を最小化する」という設計思想の肝だ。
実践：curlで挙動を確認する
実際に `curl` を使えば、この「待機」のプロセスを可視化できる。
-v で詳細なハンドシェイクを表示
-H で Expect ヘッダーを付与
curl -v -X POST http://api.example.com/upload \
-H “Expect: 100-continue” \
-H “Content-Type: application/octet-stream” \
–data-binary @huge_file.zip
出力を見ると、ヘッダー送信後に `HTTP/1.1 100 Continue` が届き、その後にボディのアップロードが始まっているのがわかるはずだ。
101 Switching Protocols：アップグレードの先にある世界
`101 Switching Protocols` は、HTTPから別のプロトコル（主にWebSocket）へ接続を昇格させる際に使われる。
プロトコルを切り替える瞬間、TCPコネクションは維持されたまま、通信のルールだけがガラリと変わる。この「接続の抽象化」こそが、リアルタイム通信を支えるインフラの魔法だ。
Node.js (wsライブラリ) でのハンドシェイクイメージ
ブラウザが `Upgrade: websocket` を投げ、サーバーが `101` を返すことでコネクションがトンネル化される。
// サーバーサイドの概念的なハンドシェイク処理
if (request.headers[‘upgrade’] === ‘websocket’) {
// ここで101を返してプロトコルを切り替える準備をする
response.writeHead(101, {
‘Upgrade’: ‘websocket’,
‘Connection’: ‘Upgrade’
});
// この後、Socket通信へ移行する
}
現場で役立つデバッグの視点
運用中、もし「リクエストが途中で止まる」「アップロードが極端に遅い」という事象に遭遇したら、以下のポイントをチェックしてほしい。
1. プロキシの介在: 中間にあるロードバランサーやキャッシュサーバーが `100 Continue` を正しく透過（パススルー）しているか？古いプロキシだと、`100` を無視して即座にタイムアウトさせるものがある。
2. クライアントの実装: `Fetch API` などを使う場合、デフォルトでは `Expect` ヘッダーを自動付与しない環境が多い。巨大なファイルの転送を扱うなら、ライブラリが `100-continue` に対応しているか、あるいは手動で制御する必要があるかを設計段階で検証すべきだ。
3. タイムアウト設定: サーバーが `100` を返した後、クライアントがどれくらい待つのか。ネットワークが細い場合、`100` を受け取ってからボディを送り出すまでのラグを考慮したタイムアウト設計が不可欠となる。
まとめ：プロトコルの「行間」を読む
1xx系のステータスコードは、決して主役ではない。しかし、大規模なデータ転送や、WebSocketのような高度な接続を支える「縁の下の力持ち」だ。
RFCの仕様をただ暗記するのではなく、「なぜこの仕組みが必要なのか？」「ネットワークリソースをどう最適化するか？」という視点でプロトコルを眺めれば、トラブルシューティングの景色は確実に変わる。
次回のAPI開発では、ぜひヘッダーを覗いてみてほしい。パケットが「準備万端だ、送ってくれ！」と合図を送っている瞬間を捉えられれば、あなたも立派なネットワーク・スペシャリストの一歩を踏み出したと言えるだろう。
コメント