HTTPからWebSocketへの「変身」：Upgradeヘッダーと101 Switching Protocolsの舞台裏
ネットワークエンジニアとして現場を渡り歩いていると、「なぜかWebSocketが繋がらない」「プロキシ越しで通信が断絶する」といったトラブルに遭遇することがあります。これらは大抵、HTTPのヘッダーという「地味だが強力な約束事」を正しく理解していないことに起因します。
今日は、HTTP/1.1の隠れた主役である「Upgradeヘッダー」と、プロトコル切り替えの作法について、RFCの行間を読み解きながら解説しましょう。
なぜHTTPは「変身」する必要があるのか
HTTP/1.1の設計思想は「リクエスト・レスポンス」という、いわば一問一答の形式です。しかし、現代のアプリケーション、特にリアルタイム性が求められるダッシュボードやチャット機能において、この形式はボトルネックになります。
そこで登場するのが「プロトコル切り替え」です。HTTPのコネクションをそのまま再利用し、より双方向通信に適したWebSocketなどのプロトコルへとアップグレードする。これがUpgradeヘッダーの役割です。
通信のシーケンス：101 Switching Protocolsの儀式
この切り替えは、単なるデータの送受信ではなく、厳格な「握手（ハンドシェイク）」として行われます。
1. クライアントからの「お願い」:
クライアントはリクエストヘッダーに `Upgrade: websocket` と `Connection: Upgrade` を含めて送信します。
2. サーバーによる「承認」:
サーバーがその要求を理解し、切り替えが可能であれば、HTTPステータスコード `101 Switching Protocols` を返します。
3. 通信路の変更:
以降、このTCPコネクション上ではHTTPのルールは無視され、WebSocketのフレームが直接流れるようになります。
実際のハンドシェイクの様子（curlで確認）
手元でこの挙動を確認するなら、`curl`を使ってプロトコルを覗いてみるのが一番です。
-i オプションでヘッダーを表示し、WebSocketの要求を送る
curl -i -N -H “Connection: Upgrade” \
-H “Upgrade: websocket” \
-H “Sec-WebSocket-Key: SGVsbG8sIHdvcmxkIQ==” \
-H “Sec-WebSocket-Version: 13” \
http://example.com/chat
ここで重要なのは `Sec-WebSocket-Key` です。これは「サーバー側でキャッシュされたレスポンスを誤認しないための安全装置」として機能します。
実務でハマるポイント：中間デバイスの罠
私が過去に遭遇したトラブルの8割は、クライアントとサーバーの間に配置されたロードバランサー（L7）やリバースプロキシ（Nginx, HAProxy等）によるものです。
プロキシは通常、HTTPのステートフルな処理を期待しています。突然「WebSocketのフレーム」が流れてくると、プロキシは「不正なパケットだ」と判断し、コネクションを強制終了させることがあります。
Nginxでの正しい設定例
Nginxをリバースプロキシとして使う場合、Upgradeヘッダーを明示的にバックエンドへ渡す設定が必要です。
location /ws/ {
proxy_pass http://backend_cluster;
# WebSocketのUpgradeヘッダーを透過させるための重要設定
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection “upgrade”;
# タイムアウト設定も忘れずに（デフォルトのままだと通信が切れやすい）
proxy_read_timeout 86400s;
proxy_send_timeout 86400s;
}
デバッグの極意：プロトコル切り替えの可視化
もし現場で「プロトコルが切り替わらない」という問題に直面したら、以下の手順で切り分けを行ってください。
1. Chrome DevToolsの「Network」タブ:
Statusが `101` になっているか確認します。もし `400 Bad Request` や `403 Forbidden` が出るなら、`Sec-WebSocket-Key` などのヘッダーが正しく伝わっていません。
2. Wiresharkによるパケット解析:
HTTPのレスポンスが返ってきた直後、TCPパケットのペイロードがHTTPの形式を崩しているか確認します。ここでパケットの内容が `0x81` などで始まるバイナリになっていれば、プロトコル切り替えは成功しています。
3. Connectionヘッダーの確認:
稀に `Connection: Keep-Alive` が優先されてしまい、Upgradeが無視されるケースがあります。ヘッダーの順序や重複がないか、慎重にログを追いましょう。
最後に：エンジニアとしての矜持
Upgradeヘッダーは、HTTPという汎用的なプロトコルが、いかに柔軟に新しい技術を取り込めるかを示す美しい仕組みです。しかし、その「便利さ」の裏には、中間デバイスとの相性という物理的な制約が隠れています。
「動いたからOK」ではなく、「なぜそのヘッダーが必要で、どのレイヤーで処理されているのか」を意識する。この視点を持つだけで、あなたのトラブルシューティング能力は格段に上がるはずです。
次回の運用作業では、ぜひ `curl -v` を叩いて、サーバーが返す101番のレスポンスに思いを馳せてみてください。そこには、現代のWebを支えるプロトコルたちの静かなドラマが詰まっています。
コメント