WebSocket対Server-Sent Events対ロングポーリング対WebRTC対WebTransportの比較
- 現代のリアルタイムWebアプリケーションでは、サーバーからクライアントへイベントを送信する機能が不可欠である。
- このニーズにより複数の手法が開発され、それぞれに長所と短所がある。
- 初期にはロングポーリングだけが利用可能な選択肢だったが、その後、双方向通信のためのより堅牢なソリューションであるWebSocketが登場した。
- WebSocketの後には、サーバーからクライアントへの単方向通信のためのよりシンプルな方法としてServer-Sent Events（SSE）が提供された。
- WebTransportプロトコルは、より効率的で柔軟かつスケーラブルなアプローチを提供し、この分野をさらに革新すると見られている。
- 特定のユースケースでは、サーバー-クライアントイベントのためにWebRTCも検討できる。
ロングポーリングとは？
- ロングポーリングは、HTTPを通じてブラウザで利用できるサーバー-クライアントメッセージングを可能にした最初の「ハック」技術である。
- クライアントが定期的にサーバーへデータを要求する従来のポーリングとは異なり、ロングポーリングでは新しいデータが利用可能になるまで開いたままのサーバー接続を確立する。
- サーバーに新しい情報があると、クライアントへ応答を返して接続を閉じる。
- クライアントはサーバーからの応答を受け取った直後に新しいリクエストを開始し、この過程が繰り返される。
- この方法により、より即時性の高いデータ更新が可能になり、不要なネットワークトラフィックとサーバー負荷を減らせる。
- しかし、それでも通信遅延を引き起こす可能性があり、WebSocketのような他のリアルタイム技術より効率が低い。
WebSocketとは？
- WebSocketは、クライアントとサーバー間の単一の持続的接続を通じて、全二重通信チャネルを提供する。
- この技術は、HTTPのリクエスト-レスポンスサイクルのオーバーヘッドなしにブラウザとサーバー間のデータ交換を可能にし、リアルタイムデータ転送に適している。
- WebSocketは従来のHTTPに比べて大きな進歩を示しており、接続が確立されると双方が独立してデータを送信できるため、低遅延かつ高頻度の更新が必要なシナリオに理想的である。
Server-Sent Eventsとは？
- Server-Sent Events（SSE）は、HTTPを通じてサーバーの更新をクライアントへプッシュする標準的な方法を提供する。
- WebSocketとは異なり、SSEはサーバーからクライアントへの単方向通信専用に設計されているため、クライアントがサーバーへデータを送る必要なくリアルタイムで更新を受け取りたい状況に適している。
WebTransport APIとは？
- WebTransportは、Webクライアントとサーバー間の効率的で低遅延な通信のために設計された最新のAPIである。
- HTTP/3 QUICプロトコルを活用し、多様なデータ転送機能を実現する。
- WebTransportは、リアルタイムゲーム、ライブストリーミング、コラボレーションプラットフォームのように高性能なネットワーキングを必要とするアプリケーションにとって強力なツールである。
- WebTransportは現在ワーキングドラフト段階にあり、まだ広く採用されていない。
WebRTCとは？
- WebRTC（Web Real-Time Communication）は、Webブラウザやモバイルアプリケーション内で、複雑なサーバーインフラや追加プラグインのインストールなしにリアルタイム通信（RTC）機能を実現するオープンソースプロジェクトおよびAPI標準である。
- WebRTCは、ブラウザ間で音声、映像、データを交換するためのピアツーピア接続をサポートする。
- WebRTCは、NATやファイアウォールを越えて動作するよう設計されており、ICE、STUN、TURNなどのプロトコルを使ってピア間接続を確立する。
技術の限界
- 双方向にデータを送れるのはWebSocketとWebTransportだけである。
- ドメインあたり6リクエストという制限により、すべての持続的なサーバー-クライアントメッセージング手法の使い勝手が制限される。
- モバイルアプリでは、一定時間アクティビティがないとOSがアプリを自動的にバックグラウンドへ移し、開いている接続を閉じる。
- 企業環境では、多くのプロキシやファイアウォールがHTTP以外の接続を遮断するため、WebSocketサーバーをインフラに統合しにくい。
パフォーマンス比較
- WebSocket、SSE、ロングポーリング、WebTransportの性能を直接比較するには、遅延、スループット、サーバー負荷、さまざまな条件下でのスケーラビリティといった主要な側面を評価する必要がある。
遅延
- WebSocket: 単一の持続的接続による全二重通信により、最も低い遅延を提供する。
- Server-Sent Events: サーバーからクライアントへの通信では低遅延を提供するが、追加のHTTPリクエストなしにサーバーへメッセージを送ることはできない。
- ロングポーリング: 各データ転送ごとに新しいHTTP接続の確立に依存するため、より高い遅延をもたらす。
- WebTransport: WebSocketと同様の低遅延を提供すると期待されており、HTTP/3プロトコルを活用することで、より効率的な多重化と輻輳制御の利点を持つ。
スループット
- WebSocket: 持続的接続により高いスループットを達成できるが、クライアントがサーバーの送信速度に追いついてデータを処理できない場合はスループットが低下することがある。
- Server-Sent Events: WebSocketより少ないオーバーヘッドで多くのクライアントにメッセージをブロードキャストできるため、単方向のサーバー-クライアント通信ではより高いスループットを達成できる。
- ロングポーリング: 頻繁に接続を開閉するオーバーヘッドのため、一般的にスループットは低い。
- WebTransport: 単一接続内で双方向ストリームと単方向ストリームの両方について高いスループットをサポートすると期待されており、複数ストリームが必要なシナリオではWebSocketを上回る可能性がある。
スケーラビリティとサーバー負荷
- WebSocket: 大量のWebSocket接続を維持するとサーバー負荷が大きく増加し、多数のユーザーを抱えるアプリケーションのスケーラビリティに影響を与える可能性がある。
- Server-Sent Events: WebSocketより接続オーバーヘッドが少ないため、主にサーバーからクライアントへの更新が必要なシナリオではよりスケーラブルである。
- ロングポーリング: 頻繁な接続確立による高いサーバー負荷のため、スケーラビリティは最も低い。
- WebTransport: HTTP/3の接続およびストリーム処理の効率を活用するよう設計されているため、WebSocketやSSEに比べてサーバー負荷を抑えながら高いスケーラビリティを持つ。
推奨事項とユースケース適合性
- サーバー-クライアント通信技術の中で、それぞれが固有の利点と適したユースケースを持つ。
- Server-Sent Events（SSE）は実装が最も簡単で、企業ファイアウォールの制限を回避して技術的な問題を避けられる。
- WebSocketは、持続的な双方向通信が求められるシナリオで優れている。
- WebTransportは採用のハードルがあり、Node.jsを含むサーバーフレームワークで広くサポートされておらず、Safariとも互換性がない。
- ロングポーリングは非効率で、新しいHTTP接続を繰り返し確立する高いオーバーヘッドのため、ほとんどのユースケースで推奨されない。
既知の問題点
- すべてのリアルタイムストリーミング技術には既知の問題点がある。
- クライアントが接続中、再接続中、またはオフラインのとき、サーバー側で発生したイベントを取り逃す可能性がある。
- 企業ファイアウォールはストリーミング技術の利用に問題を引き起こすことがある。
GN⁺の見解
- この記事は、リアルタイムWebアプリケーションを構築する際に開発者が利用できるさまざまな通信技術を比較しており、技術選定に役立つ有用な情報を提供している。
- WebSocketとSSEはすでに広く使われており、特にWebSocketはリアルタイムチャットやゲームのような双方向通信が必要なアプリケーションで非常に人気が高い。
- WebTransportはまだドラフト段階で広くサポートされていないため、実プロジェクトへの適用には無理があるかもしれない。しかし、将来的なHTTP/3ベース技術として大きな可能性を持っており注目に値する。
- ロングポーリングは古い技術だが、特定の状況では依然として有用であり、とりわけレガシーシステムとの互換性が重要な場合に利用できる。
- リアルタイム通信技術を選ぶ際には、アプリケーションの要件、サポートされるブラウザとサーバーインフラ、そして技術の成熟度を考慮する必要がある.
1件のコメント
Hacker Newsの意見
Server Sent Events(SSE) への愛着を示しつつ、WebSockets にはフロー制御（バックプレッシャー）とマルチプレクシングが欠けていること、SSE ではバイナリデータを送れないこと、WebTransport には導入上の潜在的な問題があることに言及している。
企業環境でリアルタイム機能を実装する難しさと、官僚主義によって問題解決に限界があることを指摘し、簡単な解決策として更新ボタンを追加することを提案している。
HTTP/2 以上を前提とするなら、EventSource と fetch() の組み合わせは単一の TCP 接続を使う他のプロトコルと同じくらい良さそうだという意見と、HTTP/3 が UDP を使うことへの言及がある。
WebSockets と SSE が初回リクエストでヘッダー送信をサポートしていない理由が分からないとし、リアルタイムサービスの認証実装が実装者任せになっている状況を指摘している。
WebSockets と SSE の大規模運用上の問題、バックエンドで特別な観測が必要なこと、モバイルデバイスでのデバッグの難しさ、ネットワーク接続コストの問題、状態維持の難しさなどに言及している。
90年代に設計されたオンラインオークションシステムで、リアルタイム更新をサーバープッシュ / HTTP ストリーミングで処理していた経験を共有している。
Long polling のシンプルさが懐かしいという話とあわせて、WebRTC への前向きな評価にも触れている。
Stream で働く人として、ほとんどの場合は 30 秒ごとに keep-alive ping を送る websockets の使用を勧めつつ、WebTransport の低遅延とリアルタイムゲームや音声データ転送への適用可能性にも言及している。
記事が WebRTC の UDP ベース通信の利点に触れていない点について、批判的な意見を示している。