SSE、WebSockets、ポーリングの比較

WebSockets は、クライアントとサーバーの間に永続的な TCP 接続を確立します。どちらの側からでもいつでもメッセージを送信できるため、チャットアプリケーション、共同ドキュメント編集、マルチプレイヤーゲーム、ライブカーソルなど、真にインタラクティブなリアルタイム通信に適しています。接続は、どちらか一方が明示的に閉じるまで維持されます。

SSE（Server-Sent Events）は通常の HTTP 接続を使用し、サーバーが一連のイベントとしてクライアントにデータをストリーミングします。接続は一方向で、データを送信できるのはサーバーだけです。クライアントは SSE 接続を通じてメッセージを送り返せないため、その場合は別の HTTP リクエストを送信します。SSE はブラウザーの EventSource API で実装します。

ショートポーリングとは、クライアントが一定間隔（たとえば 5 秒ごと）で HTTP リクエストを送り、「更新はありますか」と確認する方式です。サーバーは現在のデータを直ちに返します。実装は最も単純ですが、何も新しい情報がない場合にもクライアントが何度もリクエストを送るため、最も非効率です。データの変化が非常に遅い場合にのみ適しています。

ロングポーリングは、ショートポーリングを改善した方式です。クライアントがリクエストを送ると、サーバーは新しいデータが利用可能になるまで接続を開いたままにします。新しいデータが到着するとサーバーがレスポンスを返し、クライアントは直ちに次のリクエストを送ります。不要なレスポンスは減らせますが、各レスポンスで新しい TCP 接続の確立が必要になるため、SSE よりもオーバーヘッドが大きくなります。

SSE には、サーバーからクライアントへのプッシュにおいて WebSockets より実用的な利点がいくつかあります。通常の HTTP で動作するため、プロトコルのアップグレードが不要で、特別な設定なしに企業プロキシやロードバランサーを通過できます。EventSource には自動再接続機能が組み込まれています。テキストベースのプロトコルなので、ブラウザーのネットワークタブで簡単にデバッグできます。

SSE には実際の制限もあります。テキスト専用であるため、バイナリデータは base64 エンコードする必要があります。また一方向なので、クライアントからサーバーへプッシュできません。さらに HTTP/1.1 では、ドメインごとの同時 EventSource 接続数が 6 に制限されます（HTTP/2 では 1 つの接続上で多重化するため、この制限はなくなります）。双方向通信には、SSE と補完的な REST 呼び出しを組み合わせる必要があります。

SSE は、リアルタイムのメトリクスを表示するライブダッシュボード、新しいアラートをプッシュする通知フィード、実行時間の長いサーバープロセスの進捗バー、ライブのソーシャルメディアフィード、株価ティッカー、サーバーからクライアントにだけメッセージが流れるチャットインターフェース（メッセージは別途 POST します）に適しています。いずれも、サーバーが更新を開始するシナリオです。

低遅延の双方向通信が必要な場合は、WebSockets が必要です。たとえば、1 つの接続上で双方にメッセージが流れるリアルタイムチャット、Google Docs のような共同編集、クライアントの操作とサーバーの更新がどちらも高速に発生するマルチプレイヤーゲーム、ライブオークション、取引プラットフォームなどです。双方向性が、その複雑さに見合う理由になります。

HTTP/2 によって、SSE は大幅に実用的になります。接続の多重化により、1 つのドメインからのすべての SSE ストリームが 1 つの TCP 接続を共有するため、ドメインごとの接続数制限がなくなります。サーバーが HTTP/2 に対応している場合、複数のデータストリームを同時に扱うダッシュボードで SSE がさらに実用的になります。

判断の目安は次のとおりです。双方向の低遅延通信が必要 → WebSockets。サーバーが更新をプッシュし、クライアントは読み取るだけ → SSE。更新頻度が低く、単純さを重視 → ポーリング。サーバー API がすでに存在し、SSE を追加できない → ポーリング。必要な遅延要件を満たす、最も単純な解決策から始めてください。

WebSocket のフレーミングでは、最初のハンドシェイク後、メッセージごとに 2～14 バイトが追加されます。SSE では、接続ごとに一度 HTTP ヘッダーを送信し、その後は改行区切りのテキストを送信します。ショートポーリングでは、ポーリングのたびに完全な HTTP リクエスト／レスポンスヘッダーが含まれます。高頻度のデータでは、オーバーヘッドの面で WebSockets が優れています。サーバーからのプッシュ頻度が低い場合は、許容できるオーバーヘッドでより単純に実装できる SSE が適しています。

SSE と WebSockets の方向性における主な違いは何ですか。

WebSockets：双方向の永続 TCP 接続（チャット、ゲーム、共同編集）。SSE：EventSource API を介した、サーバーからクライアントへの一方向 HTTP プッシュ（通知、ダッシュボード、フィード）。ショートポーリング：一定間隔のリクエスト（最も単純で、最も非効率）。ロングポーリング：データが利用可能になるまでサーバーがレスポンスを保持（リクエスト数は少ないが、遅延が大きい）。SSE の利点：プロキシを通過でき、自動再接続に対応。SSE の制限：テキスト専用、一方向、HTTP/1.1 の接続数制限。