操作して学ぶ
WebSocketハンドシェイク可視化
WebSocket はふつうの HTTP リクエストで始まり、101 Switching Protocols を境に全二重通信へ「昇格」します。 その確立からフレームのやり取り、そして Close までを1ステップずつ追えます。 メッセージの色はフェーズ（HTTPハンドシェイク／データフレーム／制御フレーム）を表します。
HTTP ハンドシェイクデータフレーム制御フレーム
1 / 8
HTTP ハンドシェイククライアント → サーバー
1. Upgrade リクエスト（HTTP GET）
GET /chat HTTP/1.1Upgrade: websocketConnection: UpgradeSec-WebSocket-Key: (ランダム base64)Sec-WebSocket-Version: 13WebSocket は普通の HTTP GET で始まる。だから 80/443 の同じポートを使え、既存のプロキシやファイアウォールを通り抜けられる。
要点Sec-WebSocket-Key はランダムな値で、認証ではない。「この応答が本当にこの握手への返事か」を確かめるための合図。
押さえどころ
- なぜ HTTP で始めるのか。既存の 80/443 ポート・プロキシ・認証の仕組みをそのまま再利用できるから。専用ポートを開けずに、ファイアウォールを通り抜けられる。
- 101 で「昇格」する。同じ TCP 接続が WebSocket に切り替わり、以降は HTTP のリクエスト／レスポンスではなくフレーム単位の通信になる。
- 全二重が主眼。HTTP は「リクエスト → レスポンス」の交互だが、WebSocket は両者がいつでも送れる。サーバーからのリアルタイムなプッシュが可能になる。
- マスクはセキュリティではない。クライアント → サーバーのフレームは必ずマスク（XOR）される。これは経路上のプロキシがフレームを HTTP と誤解してキャッシュを汚す攻撃を防ぐための仕組み。
- Ping/Pong と Close。制御フレームで死活監視をし、終了はいきなり切らず Close フレームを交換してからクリーンに閉じる。
双方向のやり取りが要るならWebSocket。サーバー → クライアントの一方向で十分なら、HTTP のまま使える Server-Sent Events（SSE）のほうが軽く済みます。用途で選び分けます。