1047

WebSocketとServer-Sent Eventsはどちらも、データをブラウザーにプッシュできます。私には、それらは競合するテクノロジーのように見えます。それらの違いは何ですか？どちらか一方を選択するのはいつですか。

4

6 に答える 6

1232

WebsocketとSSE（Server Sent Events）はどちらもデータをブラウザーにプッシュできますが、競合するテクノロジーではありません。

Websocket接続は、ブラウザーにデータを送信することも、ブラウザーからデータを受信することもできます。WebSocketを使用できるアプリケーションの良い例は、チャットアプリケーションです。

SSE接続は、データをブラウザーにプッシュすることしかできません。オンラインの株価情報、またはタイムラインやフィードを更新するTwitterは、SSEの恩恵を受ける可能性のあるアプリケーションの良い例です。

実際には、SSEで実行できることはすべてWebsocketでも実行できるため、Websocketはより多くの注目と愛を集めており、SSEよりも多くのブラウザーがWebsocketをサポートしています。

ただし、一部のタイプのアプリケーションではやり過ぎになる可能性があり、バックエンドはSSEなどのプロトコルを使用して実装する方が簡単な場合があります。

さらに、SSEは、JavaScriptのみを使用してネイティブにサポートされていない古いブラウザーにポリフィルすることができます。SSEポリフィルのいくつかの実装は、Modernizrgithubページにあります。

落とし穴：

  • SSEには、開いている接続の最大数に制限があります。これは、ブラウザごとの制限であり、非常に少ない数に設定されているため、さまざまなタブを開くときに特に苦痛になる可能性があります（6）。この問題は、 ChromeとFirefoxで「修正されません」とマークされています。www.example1.comこの制限はブラウザ+ドメインごとであるため、すべてのタブで6つのSSE接続を開き、別の6つのSSE接続を開くことができますwww.example2.com（Phateに感謝）。
  • WSのみがバイナリデータとUTF-8の両方を送信できます。SSEはUTF-8に制限されています。（Chado Nihiに感謝します）。
  • パケットインスペクションを備えた一部のエンタープライズファイアウォールでは、WebSocket（Sophos XG Firewall、WatchGuard、McAfee Web Gateway）の処理に問題があります。

HTML5Rocksには、SSEに関するいくつかの優れた情報があります。そのページから：

サーバー送信イベントとWebSocket

WebSocketではなくサーバー送信イベントを選択するのはなぜですか？良い質問。

SSEが影に隠れている理由の1つは、WebSocketなどの後のAPIが、双方向の全二重通信を実行するためのより豊富なプロトコルを提供するためです。双方向チャネルを持つことは、ゲーム、メッセージングアプリなど、および双方向でほぼリアルタイムの更新が必要な場合に、より魅力的です。ただし、一部のシナリオでは、データをクライアントから送信する必要はありません。サーバーアクションからの更新が必要なだけです。いくつかの例としては、友人のステータスの更新、ストックティッカー、ニュースフィード、またはその他の自動データプッシュメカニズム（クライアント側のWeb SQLデータベースまたはIndexedDBオブジェクトストアの更新など）があります。サーバーにデータを送信する必要がある場合、XMLHttpRequestは常に友だちです。

SSEは従来のHTTPを介して送信されます。つまり、動作させるために特別なプロトコルやサーバーの実装は必要ありません。一方、WebSocketは、プロトコルを処理するために全二重接続と新しいWebSocketサーバーを必要とします。さらに、サーバー送信イベントには、自動再接続、イベントID、任意のイベントを送信する機能など、WebSocketには設計上欠けているさまざまな機能があります。

TLDRの概要：

Websocketに対するSSEの利点：

  • カスタムプロトコルではなく、単純なHTTPを介して転送
  • JavaScriptをポリフィルして、SSEをまだサポートしていないブラウザに「バックポート」することができます。
  • 再接続とイベントIDのサポートが組み込まれています
  • よりシンプルなプロトコル
  • パケットインスペクションを行う企業ファイアウォールに問題はありません

SSEに対するWebsocketの利点：

  • リアルタイム、双方向通信。
  • より多くのブラウザでのネイティブサポート

SSEの理想的な使用例：

  • 株式相場表示
  • Twitterフィードの更新
  • ブラウザへの通知

SSEの落とし穴：

  • バイナリサポートなし
  • 最大オープン接続制限
于 2011-03-16T13:40:07.943 に答える
138

caniuse.com によると:

クライアントのみのポリフィルを使用して、SSE のサポートを他の多くのブラウザーに拡張できます。これは、WebSocket ではあまりありません。一部の EventSource ポリフィル:

すべてのブラウザーをサポートする必要がある場合は、WebSocket、SSE、Forever Frame、AJAX ロング ポーリングなどの複数のトランスポートをサポートするweb-socket-js、SignalR、socket.ioなどのライブラリの使用を検討してください。これらは、多くの場合、サーバー側にも変更を加える必要があります。

SSE の詳細については、次を参照してください。

WebSocket の詳細については、次を参照してください。

その他の違い:

  • WebSockets は任意のバイナリ データをサポートし、SSE は UTF-8 のみを使用します
于 2014-01-23T11:38:26.770 に答える
18

Opera、Chrome、SafariはSSE、Chromeをサポートし、SafariはSharedWorker内のSSEをサポートしますFirefoxはXMLHttpRequest readyStateインタラクティブをサポートするため、FirefoxのEventSourceポリフィルを作成できます

于 2011-03-11T18:49:46.487 に答える
7

1 つの注意点:
Websocket と企業のファイアウォールに問題がありました。(HTTPS を使用すると役立ちますが、常にではありません。)

https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software https://github.com/sockjs/sockjs-client/issues/94を参照してください。

Server- Sent Events にはそれほど多くの問題はないと思います。しかし、私は知りません。

とはいえ、WebSocket は非常に楽しいものです。Websockets (Socket.IO 経由) を使用する小さな Web ゲームがあります ( http://minibman.com )

于 2014-04-19T03:04:05.767 に答える