WebSocket
WebSocketとは
WebSocket は、クライアントとサーバーの間に接続を張りっぱなしにして、双方向に自由にデータを送り合うためのプロトコルです。通常の [[HTTP]] が「リクエストに対してレスポンスを1回返して終わり」なのに対し、WebSocket は一度つながればサーバー側からも好きなタイミングでデータを送れます。
チャット・オンラインゲーム・株価ボード・共同編集など、「サーバーの変化を即座に画面へ反映したい」機能で使われます。
仕組み — HTTPからのアップグレード
WebSocket の接続は、最初は普通の HTTP リクエストとして始まります。
- クライアントが
Upgrade: websocketヘッダー付きの HTTP リクエストを送る - サーバーが
101 Switching Protocolsで応答する - 以降、同じ [[TCP/IP]] の接続上で WebSocket のフレームを双方向にやり取りする
この手順をハンドシェイクと呼びます。URL のスキームは ws://、TLS で暗号化する場合は wss:// を使います(実運用では wss が基本です)。
HTTPとの比較
| HTTP | WebSocket | |
|---|---|---|
| 通信の向き | クライアント発のみ | 双方向 |
| 接続 | リクエストごと(短命) | 張りっぱなし(長命) |
| サーバー発の通知 | 不可(ポーリングで代用) | 可能 |
| 向く用途 | 通常のAPI・ページ取得 | チャット・通知・ライブ更新 |
WebSocket が無い時代は、短い間隔でリクエストを繰り返すポーリングでリアルタイム風の動きを実現していました。WebSocket なら無駄な問い合わせなしに、変化があった瞬間にサーバーから届きます。
初学者向けポイント
- ブラウザでは標準の
WebSocketクラスだけで使えます
const ws = new WebSocket("wss://example.com/chat");
ws.onmessage = (event) => console.log(event.data);
ws.send("こんにちは");
- 接続は切れるものです — 再接続処理(切断検知とリトライ)を最初から設計に入れましょう
- 接続を張りっぱなしにするため、サーバーは同時接続数を意識した設計が必要です。待つだけの接続を大量に抱える形になるので、[[並行処理と非同期]] で挙げたイベントループ型のように、待ち時間をうまく回せる方式と相性がよいとされます
- 「毎秒更新が必要か?」を自問しましょう。数十秒ごとの更新で足りるなら、通常の [[REST API]] のポーリングの方がシンプルです
関連技術とのつながり
- [[HTTP]] — WebSocket は HTTP のハンドシェイクから始まりプロトコルを切り替える
- [[TCP/IP]] — 張りっぱなしの接続は TCP の上に成り立っている
- [[ソケット通信]] — WebSocket の土台にある「接続でデータを送り合う」考え方そのもの
- [[REST API]] — 単発のやり取りは REST、継続的な双方向通信は WebSocket と使い分ける
Q: WebSocketがHTTPと大きく異なる点はどれ?
- [x] 接続を維持し、サーバー側からも好きなタイミングでデータを送れる
- [ ] データを暗号化できる
- [ ] JSONを送受信できる
解説: WebSocket の本質は張りっぱなしの双方向通信です。サーバー発の送信は通常の HTTP ではできません。
Q: WebSocket接続の始まり方として正しいのはどれ?
- [ ] 専用の物理ケーブルで直接接続する
- [x] Upgradeヘッダー付きのHTTPリクエストからプロトコルを切り替える
- [ ] DNSサーバーが接続を仲介する
解説: 最初は HTTP リクエストとして始まり、101 応答を経て WebSocket にアップグレードされます。
Q: 暗号化されたWebSocket接続のURLスキームはどれ?
- [ ] https://
- [ ] ftp://
- [x] wss://
解説: WebSocket は ws://、TLS で暗号化した接続は wss:// を使います。実運用では wss が基本です。