SSE vs. WebSockets vs. Polling im Vergleich

WebSockets stellen eine persistente TCP-Verbindung zwischen Client und Server her. Beide Seiten können jederzeit Nachrichten senden. Dadurch eignen sich WebSockets ideal für wirklich interaktive Echtzeitkommunikation: Chat-Anwendungen, die gemeinsame Bearbeitung von Dokumenten, Multiplayer-Spiele und Live-Cursor. Die Verbindung bleibt geöffnet, bis eine der beiden Seiten sie ausdrücklich schließt.

SSE (Server-Sent Events) verwendet eine gewöhnliche HTTP-Verbindung, über die der Server Daten als eine Folge von Ereignissen an den Client überträgt. Die Verbindung ist unidirektional: Nur der Server sendet Daten. Der Client kann über die SSE-Verbindung keine Nachrichten zurücksenden, sondern muss dafür separate HTTP-Anfragen stellen. SSE wird über die EventSource-Browser-API implementiert.

Short Polling bedeutet, dass der Client in einem festen Intervall eine HTTP-Anfrage sendet, zum Beispiel alle 5 Sekunden: "Gibt es Aktualisierungen?" Der Server antwortet sofort mit den aktuellen Daten. Dies ist die einfachste Implementierung, aber auch die ineffizienteste: Der Client stellt viele Anfragen, obwohl es nichts Neues gibt. Diese Methode eignet sich nur für Daten, die sich sehr langsam ändern.

Long Polling verbessert Short Polling: Der Client stellt eine Anfrage, und der Server hält die Verbindung offen, bis neue Daten verfügbar sind. Sobald neue Daten eintreffen, antwortet der Server, und der Client stellt sofort eine weitere Anfrage. Dadurch werden unnötige Antworten reduziert. Der Aufwand ist jedoch weiterhin höher als bei SSE, da für jede Antwort eine neue TCP-Verbindung eingerichtet werden muss.

SSE bietet gegenüber WebSockets mehrere praktische Vorteile für Push-Nachrichten vom Server zum Client: SSE funktioniert über gewöhnliches HTTP (ohne Protokoll-Upgrade) und passiert daher Unternehmens-Proxys und Load Balancer ohne besondere Konfiguration. EventSource verfügt über eine integrierte automatische Wiederverbindung. Das textbasierte Protokoll lässt sich im Netzwerk-Tab des Browsers leicht untersuchen.

SSE hat einige echte Einschränkungen: Es unterstützt nur Text (Binärdaten müssen mit Base64 codiert werden), ist unidirektional (der Client kann keine Daten zurücksenden), und HTTP/1.1 begrenzt die Anzahl gleichzeitiger EventSource-Verbindungen pro Domain auf 6. HTTP/2 multiplexed die Verbindungen über eine einzige Verbindung und hebt diese Grenze dadurch auf. Für bidirektionale Kommunikation benötigt SSE ergänzende REST-Aufrufe.

SSE eignet sich ideal für Live-Dashboards mit Echtzeitmetriken, Benachrichtigungs-Feeds mit neuen Meldungen, Fortschrittsbalken für lang laufende Serverprozesse, Live-Feeds sozialer Medien, Ticker für Aktienkurse und Chat-Oberflächen, bei denen Nachrichten nur vom Server zum Client fließen (Nachrichten werden separat per POST gesendet). All dies sind Szenarien, in denen der Server Aktualisierungen initiiert.

WebSockets sind erforderlich, wenn Sie bidirektionale Kommunikation mit geringer Latenz benötigen: Echtzeit-Chats, bei denen Nachrichten über eine Verbindung in beide Richtungen fließen, kollaboratives Bearbeiten (nach dem Vorbild von Google Docs), Multiplayer-Spiele, bei denen sowohl Client-Aktionen als auch Server-Aktualisierungen schnell erfolgen, Live-Auktionen und Handelsplattformen. Die Bidirektionalität rechtfertigt die zusätzliche Komplexität.

HTTP/2 verbessert die Einsatzmöglichkeiten von SSE deutlich. Durch das Multiplexing der Verbindungen nutzen alle SSE-Streams einer Domain eine gemeinsame TCP-Verbindung, wodurch die Verbindungsgrenze pro Domain entfällt. Wenn Ihr Server HTTP/2 unterstützt, wird SSE für Dashboards mit mehreren gleichzeitig aktiven Datenströmen noch praktischer.

Entscheidungshilfe: Wenn Sie bidirektionale Kommunikation mit geringer Latenz benötigen → WebSockets. Wenn der Server Aktualisierungen sendet und der Client nur liest → SSE. Wenn Sie nur gelegentliche Aktualisierungen benötigen und Einfachheit wichtig ist → Polling. Wenn die Server-API bereits vorhanden ist und Sie SSE nicht hinzufügen können → Polling. Beginnen Sie mit der einfachsten Lösung, die Ihre Anforderungen an die Latenz erfüllt.

Das WebSocket-Framing fügt nach dem initialen Handshake pro Nachricht 2–14 Byte hinzu. SSE sendet einmal pro Verbindung HTTP-Header und danach Text, der durch Zeilenumbrüche getrennt ist. Short Polling enthält bei jeder Abfrage vollständige HTTP-Header für Anfrage und Antwort. Bei Daten mit hoher Frequenz haben WebSockets beim Overhead die Nase vorn. Bei seltenen Push-Nachrichten vom Server ist SSE einfacher und der Overhead akzeptabel.

Was ist der entscheidende Unterschied bei der Kommunikationsrichtung zwischen SSE und WebSockets?

WebSockets: bidirektionale persistente TCP-Verbindung (Chat, Spiele, kollaboratives Bearbeiten). SSE: unidirektionaler HTTP-Push vom Server zum Client über die EventSource-API (Benachrichtigungen, Dashboards, Feeds). Short Polling: Anfragen in festen Intervallen (am einfachsten, am ineffizientesten). Long Polling: Der Server hält die Antwort offen, bis Daten verfügbar sind (weniger Anfragen, höhere Latenz). Vorteile von SSE: funktioniert über Proxys, automatische Wiederverbindung. Einschränkungen von SSE: nur Text, unidirektional, Verbindungsgrenzen bei HTTP/1.1.