HTTPの「橋渡し」を理解する：Upgradeヘッダーとプロトコル切り替えの深層
ネットワークエンジニアとして現場を歩いていると、「なぜHTTPはこんなにも柔軟なのか？」と感心させられる瞬間が多々あります。Webという巨大なインフラは、本来ステートレスで短命なHTTPというプロトコルを基盤にしながら、WebSocketのようなリアルタイム通信までやってのける。この魔術を支えているのが、今回解説するUpgradeヘッダーを用いたプロトコル切り替え（Protocol Switching）の仕組みです。
RFC 7230（HTTP/1.1のメッセージ構文とルーティング）で定義されているこのメカニズムは、まさに「HTTPで握手をして、合意したら別の土俵へ飛び移る」という鮮やかな手口です。
—
1. Upgradeハンドシェイクの「作法」
プロトコル切り替えのシーケンスは、非常にシンプルかつ論理的です。クライアントが「HTTPから別のプロトコルへ変えませんか？」と提案し、サーバーが「承知した、切り替えよう」と応じる。この二段階のダンスを紐解いていきましょう。
基本的な通信フロー
1. クライアント: `Upgrade`ヘッダーと`Connection: upgrade`ヘッダーを含むリクエストを送信。
2. サーバー: 切り替えが可能であれば、HTTP 101 (Switching Protocols) ステータスコードと、同意したプロトコルを明記した`Upgrade`ヘッダーを返す。
3. 転換: サーバーが101レスポンスを送信した直後から、通信路のプロトコルが切り替わる。
ここで重要なのは、`Connection: upgrade`というヘッダーが必須であるという点です。HTTP/1.1では、特定のホップ間でのみ有効なヘッダーを制御するためにこの指定が不可欠です。これを忘れると、プロキシサーバーが正しくパケットを中継してくれず、ハンドシェイクが途中で沈黙することになります。
—
2. 実践：curlで覗く「交渉の裏側」
論より証拠。まずは手元の端末から、WebSocketへの切り替えをシミュレートしてみましょう。
-i はレスポンスヘッダーを表示するため
-H で必要なヘッダーを付与（WebSocketのハンドシェイクに必須のパラメータ）
curl -i -N -H “Connection: Upgrade” \
-H “Upgrade: websocket” \
-H “Sec-WebSocket-Key: SGVsbG8sIFdvcmxkIQ==” \
-H “Sec-WebSocket-Version: 13” \
http://echo.websocket.org/
このコマンドを打つと、サーバーからのレスポンスに注目してください。
- HTTP/1.1 101 Switching Protocols
- Upgrade: websocket
- Connection: Upgrade
この「101」が返ってきた瞬間、そこから先はHTTPのパケット構造を捨て、WebSocketのバイナリフレームが飛び交うトンネルへと変わります。もしサーバーが対応していなければ、通常通り`200 OK`や`404 Not Found`が返ってくるだけ。この「ネゴシエーションの失敗」が、インフラ運用におけるトラブルシューティングの第一歩となります。
—
3. Web API開発での注意点：プロキシとファイアウォールの罠
実務において最もハマりやすいのが、中継機器による「Upgradeヘッダーの剥離」です。
多くのロードバランサーやリバースプロキシ（NginxやHAProxyなど）は、設定を正しく行わないと、この`Upgrade`ヘッダーを単なる不要なヘッダーと見なし、バックエンドへ転送する際に削除してしまいます。
Nginxでの設定例
Nginxをフロントに置く場合、プロトコル切り替えを明示的に許可する必要があります。
location /ws/ {
proxy_pass http://backend_cluster;
# 必須：クライアントからのUpgrade要求をバックエンドへ継承する
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;
}
この設定がないと、クライアントは「切り替えたい」と言っているのに、バックエンドは「ただのHTTPリクエスト」として受け取ってしまい、結果として`400 Bad Request`やタイムアウトが発生します。
—
4. なぜHTTP/1.1の「Upgrade」が必要なのか
最近ではHTTP/2やHTTP/3（QUIC）が普及し、これらは最初からマルチプレキシングやストリーム制御を備えています。しかし、HTTP/1.1のUpgradeヘッダーは、「既存のHTTP/1.1インフラという土壌を活かしつつ、全く異なる通信方式に拡張できる」という、極めて現実的な進化の道筋を示しました。
エンジニアとして覚えておいてほしいのは、「プロトコルは決して一つではない」という事実です。HTTPという共通言語で最初の握手を行い、用途に応じて最も効率的なプロトコル（WebSocketやHTTP/2へのアップグレードなど）へ切り替える。この「適材適所のプロトコル選択」こそが、高パフォーマンスなWebシステムを設計する際の真髄です。
最後に：トラブルシュートの指針
もし通信がうまくいかない場合は、以下の順序で確認してください。
1. ブラウザ/クライアントのDevTools: `101 Switching Protocols`が返っているか？
2. Request Header: `Connection: Upgrade` と `Upgrade: [プロトコル名]` は揃っているか？
3. Proxyのログ: プロキシの手前までヘッダーが届いているか？（tcpdumpでパケットをキャプチャするのが一番確実です）
教科書的な知識だけでは、現場の複雑なネットワーク環境は超えられません。プロトコルの裏側で何が起きているのか、パケットの先にある「合意」を想像してみてください。そうすれば、どんな複雑なインフラ障害も、必ず解決の糸口が見えてくるはずです。
コメント