『リアルタイム通信』の3つの主要技術
リアルタイム通信は WebSocket・SSE・Long Polling の3技術を用途で使い分けます。本記事では編集部の視点で、比較を公開情報をもとに整理します。WebSocket 本番運用 もご参考に。
3技術の基本
(1) WebSocket：双方向・常時接続。(2) SSE：サーバー→クライアント単方向。(3) Long Polling：HTTP 反復取得。(4) Server Push (HTTP/2)：採用低調(公開情報をもとに)。(5) WebRTC：P2P 通信。WebRTC 実践 もご参考に。
用途別の推奨
(1) チャット・ゲーム：WebSocket。(2) LLM ストリーミング：SSE。(3) 通知配信 (簡易)：SSE / Long Polling。(4) 共同編集：WebSocket + CRDT。(5) 株価/IoT：WebSocket。
パフォーマンス比較
(1) WebSocket：レイテンシ最小・帯域効率良。(2) SSE：HTTP/1.1 で接続数制限あり。(3) Long Polling：オーバーヘッド大。(4) サーバー負荷：WebSocket 接続維持コスト。(5) 同時接続数：WebSocket 1サーバー10万級可能(公開情報をもとに)。
実装の難易度
(1) SSE：HTTP の延長・実装最易。(2) Long Polling：シンプル。(3) WebSocket：プロトコル特殊・libs 必要。(4) スケール：WebSocket 最複雑。(5) 監視：WebSocket が一番難。
ブラウザサポート
(1) WebSocket：全モダンブラウザ。(2) SSE：IE 除く全ブラウザ。(3) Long Polling：全ブラウザ。(4) セキュリティ：いずれも HTTPS 推奨。(5) 認証：SSE は Cookie ベース簡単。SSE 実装 もご参考に。
マネージドサービス
(1) Pusher：WebSocket。(2) Ably：複数プロトコル対応。(3) AWS API Gateway WS：WebSocket。(4) Cloudflare Workers：WebSocket/SSE。(5) Supabase Realtime：DB変更通知。Supabase 実践 もご参考に。
選択フロー
(1) 双方向必要? → Yes: WebSocket。(2) サーバー→ クライアントのみ? → SSE。(3) シンプル実装重視? → SSE。(4) 大規模スケール? → WebSocket。(5) 互換性最重要? → Long Polling。
失敗しがちなパターン
(1) SSE で双方向通信：別チャネル必要。(2) WebSocket 接続多すぎ：サーバ枯渇。(3) 切断検知遅い：ゾンビ接続。(4) 認証なし：誰でも接続。(5) 監視不足。対策は、(1)用途別選定、(2)Pub/Sub 連携、(3)heartbeat、(4)JWT 検証、(5)接続数アラート、です。