Web開発で「リアルタイム通信」が必要になる場面は増えています。チャットや株価の更新、ゲームやIoTデバイスなどでは、HTTPだけでは対応しきれないことがあります。ここでは、WebSocketとHTTPの仕組みの違いを深掘りして解説します。
1. 接続モデルの違い
HTTP：リクエスト／レスポンス型
HTTPは「クライアントがリクエストを送る → サーバがレスポンスを返す」という1回限りの通信が基本です。
- 接続はリクエストごとに確立される
- 状態は基本的にサーバ側で保持されない（ステートレス）
- 長時間接続やリアルタイム更新には向かない
例：Webページの読み込みやAPI呼び出し。
WebSocket：常時接続型
WebSocketは、一度コネクションを確立すると、その後は「双方向で自由にメッセージを送れる状態」を維持します。
- TCPコネクションを維持
- サーバからクライアントへのプッシュが可能
- 長時間接続に向いている
例：チャットアプリ、ゲーム、株価のリアルタイム更新。
2. 通信の方向性
| 項目 | HTTP | WebSocket |
|---|---|---|
| 送信方向 | クライアント→サーバのみ | 双方向（クライアント↔サーバ） |
| プッシュ対応 | 基本不可（サーバ→クライアントはポーリングが必要） | 標準対応（サーバが自由に送信可能） |
HTTPでサーバからクライアントに情報を送る場合、以下のような手段が必要です：
- ポーリング：クライアントが定期的にサーバに問い合わせ
- 長輪講（Long Polling）：サーバがデータ更新までレスポンスを遅延させる
- サーバ送信イベント（SSE）：一方向のプッシュに限定
WebSocketはこれらの手段を使わずに、双方向通信を実現できます。
3. オーバーヘッドとパフォーマンス
HTTPのオーバーヘッド
HTTPではリクエストごとにヘッダを送る必要があり、接続も都度確立されます。
- TCP接続の確立＋TLSハンドシェイクで通信開始
- ヘッダが毎回送られる（Cookie、User-Agent、Acceptなど）
→ 頻繁に小さなメッセージをやり取りする場合、効率が悪い
WebSocketのオーバーヘッド
WebSocketは初回のハンドシェイク（HTTP Upgrade）後、TCP接続を維持。
- メッセージは軽量なフレームで送信
- ヘッダは最小限
- 低レイテンシでの大量メッセージ通信に最適
4. 接続の維持とスケーラビリティ
WebSocketは接続を維持するため、サーバ側は各クライアントごとのコネクションを保持する必要があります。
- メモリやソケットの管理コストが増える
- 大規模な同時接続には専用のインフラ（Redis Pub/Subやメッセージキュー）が必要
一方HTTPはステートレスなので、サーバ側の負荷は軽いですが、リアルタイム性は確保できません。
5. 用途の選定
| シナリオ | HTTP向き | WebSocket向き |
|---|---|---|
| ページ読み込み | ◯ | △（過剰） |
| REST API呼び出し | ◯ | ✕ |
| チャットアプリ | △（ポーリング必要） | ◯ |
| 株価や天気のリアルタイム更新 | ✕ | ◯ |
| IoTデバイスの状態監視 | ✕ | ◯ |
まとめ
リアルタイム通信や双方向通信が必要な場合はWebSocketが適しています。ただし、接続の管理やスケーラビリティには注意が必要です。