2012-11-07 11 views
9

Kürzlich habe ich von Server-Gesendete Ereignisse als eine viel einfachere Alternative zu WebSockets für Push vom Server gefunden. Die meisten Orte, die sie vergleichen (wie here, here und here) sagen, dass, wenn Sie keine Vollduplex-Kommunikation zwischen Client und Server benötigen, WebSockets Overkill und SSE gut genug sind.Nachteil der Verwendung von Server-Sent-Ereignissen für die bidirektionale Client-Server-Kommunikation (anstelle von WebSockets)

Meine Frage ist, was wäre der Nachteil der Verwendung von SSE, wenn Sie bidirektionale Kommunikation (wie ein Chat zum Beispiel) benötigen, regelmäßige ajax Anfragen zum Senden von Nachrichten vom Client und den Server-Stream für den Empfang von ihnen? Wenn man bedenkt, dass ich auf der Server-Seite wenig oder gar keine Konfiguration von SSE machen muss, scheint dies eine viel attraktivere Option zu sein.

Antwort

14

SSE Vorteile über WebSockets:

  • keine speziellen Web-Server oder Web-Proxy-Änderungen erforderlich.
  • definieren benutzerdefinierte Ereignisse (ansonsten Client-API ist im Grunde das gleiche)
  • Einfachere Integration bestehender Authentifizierungsmechanismen (OAuth, OpenID, etc)

SSE Nachteile Vergleich zu WebSockets:

  • Unidirektionaler Kommunikationskanal (Server zu Client). Client zu Server erfordert einen separaten Kanal.
  • Browser-Unterstützung ist begrenzt (keine native IE Unterstützung während WebSockets wird in IE 10 unterstützt): WebSockets, SSE
  • auf Client setzt Herkunft (möglicherweise anfälliger für XSS-Angriffe als WebSockets)
  • keine native Unterstützung zu überprüfen für binäre Typen (WebSockets unterstützt rohe Frames mit ArrayBuffers und Blobs).
  • Erfordert einen vollwertigen Webserver, selbst wenn der SSE-Endpunkt keinen statischen Webinhalt bereitstellt (ein eigenständiger WebSocket-Server kann ziemlich einfach sein)
  • SSE mit AJAX für bidirektionale Kommunikation wird VIEL höhere Round-Trip-Latenz haben und höhere Client-> Server-Bandbreite als über eine WebSocket-Verbindung. Dies ist auf den Overhead des Verbindungsaufbaus für jede Client-> Server-AJAX-Anfrage zurückzuführen. Server-> Client-Latenz kann auch Spikes mit SSE haben, da in vielen Konfigurationen die lang gehaltene Verbindung schließlich geschlossen wird (oft alle 30 Sekunden) und erneut geöffnet werden muss, was ebenfalls eine temporäre Erhöhung der Server-> Client-Latenz verursacht .

Referenzen:

+2

Gute Punkte, aber ich bin nicht ganz mit der Komplexität eines eigenständigen Servers einverstanden. SSE-Protokoll ist tot einfach - viel einfacher als WebSockets (kein Handshake, Framing, Maskierung, binär). In beiden Fällen müssen Sie HTTP-ähnliche Header analysieren. Sie können SSE-Server in einem Bash-Skript implementieren :) – Kornel

+0

@porneL, Sie haben Recht, ein einfacher SSE-Server könnte ziemlich einfach zu implementieren sein (obwohl ich Ihre Bash-Version sehen möchte), aber auch ein einfacher WebSocket-Server. Aber egal, mein Punkt war nicht, dass WebSocket-Server einfacher sind, sondern dass SSE normalerweise einen Webserver annimmt, WebSockets dagegen nicht (obwohl es sicherlich so konzipiert ist, dass es leicht in die bestehende Web-Infrastruktur integriert werden kann). – kanaka

2

Ajax-Anfragen sind im Vergleich zu kleinen WebSocket-Nachrichten enorm. Standard-HTTP-Anforderungen (Ajax) enthalten viele Header einschließlich Cookies bei jeder Anfrage, während WebSocket-Nachrichten nur ein paar Bytes umfassen.

Die gute Sache mit HTTP (Ajax) Anfrage ist, dass sie einfacher zu cachen sind, wenn das ein Vorteil für Ihr Problem ist.

+0

Für die bidirektionale Kommunikation wird AJAX in der Lage, Anfragen zwischenzuspeichern nicht hilfreich sein würde . Wenn Sie AJAX verwenden, um Bilder oder andere statische Daten asynchron zu laden, wäre Caching nützlich, aber das ist für Server-> Client-Kommunikation und hilft nicht mit Client-> Server, für den AJAX in diesem Szenario verwendet wird. – kanaka

Verwandte Themen