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

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

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

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

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

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

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

落とし穴：

• SSEは、開いている接続の最大数に制限があるため、ブラウザごとに制限があり、非常に低い数に設定されているため、さまざまなタブを開くときに特に痛いことがあります（6）。この問題は、ChromeおよびFirefoxでは「修正されません」とマークされています。この制限はブラウザー+ドメインごとにあるため、すべてのタブで6つのSSE接続を開くことができwww.example1.com、さらに6つのSSE接続を開くことができますwww.example2.com（Phateに感謝）。
• バイナリデータとUTF-8の両方を送信できるのはWSのみであり、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は、プロトコルを処理するために、全二重接続と新しいWeb Socketサーバーを必要とします。さらに、サーバー送信イベントには、自動再接続、イベントID、任意のイベントを送信する機能など、WebSocketには設計上欠けているさまざまな機能があります。

TLDRの概要：

Webソケットに対するSSEの利点：

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

SSEに対するWebsocketの利点：

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

SSEの理想的な使用例：

• 株価ティッカーストリーミング
• Twitterフィードの更新
• ブラウザへの通知

SSEの落とし穴：

• バイナリサポートなし
• 最大オープン接続制限

caniuse.comによると：

• グローバルユーザーの96％が WebSocketをネイティブでサポート
• グローバルユーザーの％92がサーバー送信イベントをネイティブでサポート

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

• 他のライブラリに依存しないRemy SharpのEventSource（IE7 +）
• Rick WaldronによるjQuery.EventSource
• EventSourceによってYaffle（ネイティブ実装を置き換え、ブラウザ間で正規化行動）

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

SSEの詳細については、以下をご覧ください。

• HTML5 Rocksの記事
• W3C仕様（公開バージョン、編集者の下書き）

WebSocketの詳細については、以下をご覧ください。

• HTML5 Rocksの記事
• W3C仕様（公開バージョン、編集者の下書き）

その他の違い：

• WebSocketsは任意のバイナリデータをサポートし、SSEはUTF-8のみを使用します

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

Websocket VS SSE

Webソケット-単一のTCP接続で全二重通信チャネルを提供するプロトコルです。たとえば、サーバーとブラウザ間の双方向通信プロトコルはより複雑であるため、サーバーとブラウザは、WebSocketのライブラリに依存する必要があります。socket.io

Example - Online chat application.

SSE（サーバー送信イベント）- サーバー送信イベントの場合、通信はサーバーからブラウザーにのみ行われ、ブラウザーはサーバーにデータを送信できません。この種の通信は主に、更新されたデータを表示する必要がある場合に使用され、データが更新されるたびにサーバーがメッセージを送信します。たとえば、サーバーからブラウザへの一方向の通信です。このプロトコルはそれほど複雑ではないため、外部ライブラリJAVASCRIPT自体に依存する必要はなくEventSource、サーバーから送信されたメッセージを受信するためのインターフェースを提供します。

Example - Online stock quotes or cricket score website.

注意すべき点の1つ：
Webソケットと企業ファイアウォールに問題がありました。（HTTPSの使用は役立ちますが、常にではありません。）

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

サーバー送信イベントにはそれほど問題はないと思います。しかし、私にはわかりません。

とはいえ、WebSocketは非常に楽しいものです。（Socket.IO経由で）WebSocketを使用する小さなWebゲームを持っています（http://minibman.com）

ここでは、Webソケットとサーバー送信イベントの違いについて説明します。Java EE 7から、WebSocket APIはすでに仕様の一部であり、サーバー送信イベントはエンタープライズ版の次のバージョンでリリースされるようです。

最大接続制限は、http2 + sseの問題ではありません。

http 1の問題でした