it-swarm.com.de

WebSockets vs. Server-Sent Ereignisse / EventSource

Sowohl WebSockets als auch Server-Sent Events können Daten an Browser senden. Für mich scheinen sie konkurrierende Technologien zu sein. Was ist der Unterschied zwischen ihnen? Wann würden Sie eine der anderen vorziehen?

739
Mads Mobæk

Sowohl Websockets als auch SSE (Server Sent Events) können Daten an Browser senden, sie sind jedoch keine konkurrierenden Technologien.

Websockets-Verbindungen können sowohl Daten an den Browser senden als auch Daten vom Browser empfangen. Ein gutes Beispiel für eine Anwendung, die Websockets verwenden könnte, ist eine Chat-Anwendung.

SSE-Verbindungen können nur Daten an den Browser senden. Online-Börsenkurse oder Twitters, die den Zeitplan oder Feed aktualisieren, sind gute Beispiele für eine Anwendung, die von SSE profitieren könnte.

Da in der Praxis alles, was mit SSE gemacht werden kann, auch mit Websockets gemacht werden kann, wird Websockets viel aufmerksamer und liebevoller und viel mehr Browser unterstützen Websockets als SSE.

Für einige Anwendungstypen kann es jedoch zu einem Overkill kommen, und die Implementierung des Backends mit einem Protokoll wie SSE ist möglicherweise einfacher.

Darüber hinaus kann SSE in älteren Browsern, die es nicht nativ unterstützen, mit nur JavaScript mehrfach ausgefüllt werden. Einige Implementierungen von SSE Polyfills finden Sie auf der Seite Modernizr github .

Fallstricke:

  • SSE leidet unter einer Beschränkung der maximalen Anzahl offener Verbindungen, die beim Öffnen verschiedener Registerkarten besonders schmerzhaft sein kann, da die Beschränkung pro Browser und auf eine sehr niedrige Anzahl (6) festgelegt ist. . Das Problem wurde in Chrome und Firefox als "Wird nicht behoben" markiert
  • Nur WS kann sowohl Binärdaten als auch UTF-8 übertragen. SSE ist auf UTF-8 beschränkt. (Danke an Chado Nihi).
  • Einige Unternehmensfirewalls mit Paketprüfung haben Probleme mit WebSockets (Sophos XG Firewall, WatchGuard, McAfee Web Gateway).

HTML5Rocks hat einige gute Informationen zu SSE. Von dieser Seite:

Vom Server gesendete Ereignisse im Vergleich zu WebSockets

Warum sollten Sie Server-Sent Events anstelle von WebSockets wählen? Gute Frage.

Ein Grund, warum SSEs im Schatten bleiben, ist, dass spätere APIs wie WebSockets ein umfangreicheres Protokoll für die bidirektionale Vollduplex-Kommunikation bieten. Ein bidirektionaler Kanal ist attraktiver für Spiele, Messaging-Apps und Fälle, in denen Aktualisierungen nahezu in Echtzeit in beide Richtungen erforderlich sind. In einigen Szenarien müssen jedoch keine Daten vom Client gesendet werden. Sie benötigen lediglich Aktualisierungen von einer Serveraktion. Einige Beispiele sind Statusaktualisierungen von Freunden, Börsenticker, Newsfeeds oder andere automatisierte Data-Push-Mechanismen (z. B. Aktualisieren einer clientseitigen Web SQL-Datenbank oder eines IndexedDB-Objektspeichers). Wenn Sie Daten an einen Server senden müssen, ist XMLHttpRequest immer ein Freund.

SSEs werden über herkömmliches HTTP gesendet. Das bedeutet, dass sie kein spezielles Protokoll oder eine spezielle Server-Implementierung benötigen, um arbeiten zu können. Für WebSockets hingegen sind Vollduplex-Verbindungen und neue Web Socket-Server erforderlich, um das Protokoll zu verarbeiten. Darüber hinaus verfügen von Servern gesendete Ereignisse über eine Reihe von Funktionen, die WebSockets aufgrund ihres Designs nicht bieten, z. B. automatische Wiederverbindung, Ereignis-IDs und die Möglichkeit, beliebige Ereignisse zu senden.


TLDR-Zusammenfassung:

Vorteile von SSE gegenüber Websockets:

  • Transport über einfaches HTTP anstelle eines benutzerdefinierten Protokolls
  • Kann mit Javascript mehrfach gefüllt werden, um SSE für Browser zu "backportieren", die es noch nicht unterstützen.
  • Eingebaute Unterstützung für Wiederverbindung und Event-ID
  • Einfacheres Protokoll
  • Keine Probleme mit Unternehmensfirewalls bei der Paketüberprüfung

Vorteile von Websockets gegenüber SSE:

  • Echtzeitkommunikation in zwei Richtungen.
  • Native Unterstützung in mehr Browsern

Ideale Anwendungsfälle von SSE:

  • Börsenticker-Streaming
  • Aktualisierung des Twitter-Feeds
  • Benachrichtigungen an den Browser

SSE-Fallstricke:

  • Keine binäre Unterstützung
  • Maximale Anzahl offener Verbindungen
872
Alex Recarey

Laut caniuse.com:

Sie können eine reine Client-Polyfüllung verwenden, um die Unterstützung von SSE auf viele andere Browser auszudehnen. Dies ist bei WebSockets weniger wahrscheinlich. Einige EventSource-Polyfills:

Wenn Sie alle Browser unterstützen müssen, sollten Sie eine Bibliothek wie web-socket-js , SignalR oder socket.io verwenden, die mehrere Transporte unterstützt wie WebSockets, SSE, Forever Frame und AJAX langes Polling. Diese erfordern häufig auch Änderungen auf der Serverseite.

Weitere Informationen zu SSE erhalten Sie von:

Weitere Informationen zu WebSockets finden Sie unter:

Andere Unterschiede:

  • WebSockets unterstützt beliebige Binärdaten, SSE verwendet nur UTF-8
99
Drew Noakes

Opera, Chrome, Safari unterstützt SSE, Chrome, Safari unterstützt SSE in SharedWorker Firefox unterstützt XMLHttpRequest readyState interactive, sodass EventSource polyfil für Firefox erstellt werden kann

15
Yaffle

Websocket VS SSE


Web Sockets - Dies ist ein Protokoll, das einen Vollduplex-Kommunikationskanal über eine einzelne TCP Verbindung bereitstellt. Zum Beispiel eine bidirektionale Kommunikation zwischen dem Server und dem Browser Da das Protokoll komplizierter ist, müssen sich der Server und der Browser auf die Bibliothek des Websockets verlassen, die socket.io ist.

Example - Online chat application.

SSE (Server-Sent Event) - Im Falle eines vom Server gesendeten Ereignisses wird die Kommunikation nur vom Server zum Browser ausgeführt und der Browser kann keine Daten an den Server senden. Diese Art der Kommunikation wird hauptsächlich verwendet, wenn nur die aktualisierten Daten angezeigt werden sollen. Der Server sendet die Nachricht dann, wenn die Daten aktualisiert werden. Zum Beispiel eine einseitige Kommunikation zwischen dem Server und dem Browser. Dieses Protokoll ist weniger kompliziert, sodass Sie sich nicht auf die externe Bibliothek verlassen müssen. JAVASCRIPT selbst bietet die Schnittstelle EventSource, um die vom Server gesendeten Nachrichten zu empfangen.

Example - Online stock quotes or cricket score website.
6
Gaurav Tiwari

Eine Sache zu beachten:
Ich hatte Probleme mit Websockets und Unternehmensfirewalls. (Die Verwendung von HTTPS hilft aber nicht immer.)

Siehe https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-softwarehttps://github.com/sockjs/sockjs-client)/issues/94

Ich nehme an , dass es nicht so viele Probleme mit vom Server gesendeten Ereignissen gibt. Aber ich weiß es nicht.

Das heißt, WebSockets machen jede Menge Spaß. Ich habe ein kleines Web-Spiel, das Websockets verwendet (via Socket.IO) ( http://minibman.com )

4
Drew LeSueur

Hier ist ein Vortrag über die Unterschiede zwischen Web-Sockets und vom Server gesendeten Ereignissen. Da Java EE 7 eine WebSocket API bereits Teil der Spezifikation ist, werden anscheinend vom Server gesendete Ereignisse in der nächsten Version des Unternehmens veröffentlicht Auflage.

1