HTTPからWebSocketへ：Upgradeヘッダーが引き起こす「プロトコルの魔法」
ネットワークエンジニアとして現場に立っていると、「HTTPは単なるドキュメント転送の手段」という認識がいかに危ういかを思い知らされる瞬間がある。Web APIの設計やインフラ運用において、HTTPは今や、より高度で双方向な通信を切り拓くための「玄関口」としての役割が主となっているからだ。
今回は、HTTP/1.1において最もエレガントかつ、トラブルシューティングの現場でエンジニアの腕が試される機能の一つ、「Upgradeヘッダー」によるプロトコル切り替えについて深掘りしていく。
—
1. なぜ「Upgrade」が必要なのか？
HTTP/1.1は基本的に「リクエストを出してレスポンスを受け取る」という、短期的な関係性の上に成り立っている。しかし、リアルタイムなチャットや株価配信、あるいはゲームの通信といったユースケースでは、この一往復のコストが致命的なオーバーヘッドになる。
そこで登場するのが「プロトコル・アップグレード」だ。これは、「HTTPという共通言語で握手（ハンドシェイク）をしてから、全く別の言語（WebSocketなど）に乗り換えて、同じTCPコネクションを使い回す」という、極めて合理的な仕組みである。
2. 101 Switching Protocolsの役割
プロトコルの切り替えは、以下のようなシーケンスで進行する。
1. Client: 「このコネクションをWebSocketで使いたいんだけど、いいかな？」とリクエストを送る。
2. Server: 「わかった。じゃあ、今のHTTP通信はここまで。ここから先はWebSocketのルールで話そう」と返答する。
この時、サーバーが返すステータスコードが `101 Switching Protocols` だ。このコードが返された瞬間、TCPコネクション上のバイナリ・ストリームの解釈方法が、HTTPからWebSocketへと切り替わる。これは単なる情報の伝達ではなく、コネクションの「性格」を変える儀式のようなものだ。
3. 実践：Upgradeのハンドシェイクを解剖する
実際にどのようなヘッダーがやり取りされているのか、`curl`を使って覗いてみよう。WebSocketのエンドポイントに対してリクエストを送る際の典型的な構成だ。
WebSocketへのアップグレードリクエストを模したcurlコマンド
curl -i -N -H “Connection: Upgrade” \
-H “Upgrade: websocket” \
-H “Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==” \
-H “Sec-WebSocket-Version: 13” \
http://example.com/chat
- Connection: Upgrade: 「このコネクションの挙動を変えたい」という意思表示。
- Upgrade: websocket: 具体的にどのプロトコルに乗り換えたいかを指定。
- Sec-WebSocket-Key: サーバー側で正当性を検証するためのランダム値。
- Sec-WebSocket-Version: 使用するプロトコルのバージョン。
このリクエストに対し、サーバーは以下のようなレスポンスを返す。
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
この`Sec-WebSocket-Accept`は、クライアントが送ったKeyを元に計算されたハッシュ値だ。これが一致すれば、晴れて双方向通信の開始となる。
4. 現場でハマる「インフラの罠」
この仕組みを理解せずにロードバランサーやプロキシを設定すると、必ず痛い目を見る。特に多いのが、「中間ノードによるUpgradeヘッダーの削除」だ。
NginxやHAProxyなどのリバースプロキシを前段に置く場合、プロキシ自体がUpgradeヘッダーを正しく解釈し、バックエンドへ転送する設定になっていないと、クライアントは永遠に101を待つことになる。
Nginxでの設定例
location /chat/ {
proxy_pass http://backend_cluster;
# プロキシがHTTP/1.1のアップグレードを透過させるための肝
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection “upgrade”;
# WebSocketのタイムアウト設定を適切に管理する
proxy_read_timeout 86400s;
proxy_send_timeout 86400s;
}
この設定がないと、Nginxは「ただのHTTPリクエスト」として処理しようとし、クライアントは接続失敗に終わる。現場で「WebSocketが繋がらない！」と泣きつかれたら、まずこのプロキシ設定の有無を確認するのが鉄則だ。
5. デバッグの心得
実務において「プロトコルが切り替わらない」という問題に直面した時は、以下の手順を推奨する。
1. ブラウザのデベロッパーツール（Networkタブ）: `101 Switching Protocols`が返っているか、あるいは`400 Bad Request`や`403 Forbidden`で弾かれていないかを確認する。
2. tcpdump / Wireshark: そもそもUpgradeヘッダーがバックエンドに到達しているか、生のパケットで確認する。レイヤー7の設定ミスは、レイヤー4のパケットを見れば即座に判明する。
3. セキュリティヘッダーの確認: 最近のWeb APIでは、WebSocket接続時にOriginヘッダーのチェックが厳格だ。CORS設定でWebSocketのエンドポイントが弾かれていないか、サーバー側のログを注視してほしい。
最後に：ネットワークを「プログラム」する
HTTP/1.1のUpgradeという仕組みは、ネットワークを固定されたパイプラインではなく、目的に応じて動的に最適化できる「プログラム可能な器」へと変える第一歩だ。
技術は教科書の通りに動くこともあるが、現実のネットワークはノイズと制約で満ちている。だからこそ、こうした通信の裏側にある「握手のルール」を深く理解しておくことが、困難なトラブルからシステムを救う唯一の武器になるのだ。
さあ、次はあなたの担当しているシステムのログを眺めてみてほしい。そこには、今日もひたむきに「プロトコルの交渉」を続けるパケットたちが息づいているはずだ。
コメント