SSE vs WebSocket: Welche Echtzeit-Option du nutzen solltest | We.Inc
Server-Sent Events vs WebSockets: EventSource und WebSocket im Vergleich, Wiederverbindung, Binärdaten, Verbindungslimits, eine Entscheidungshilfe und minimale Node-Server für beide.
Server-Sent Events streamen Text vom Server zum Browser über eine gewöhnliche HTTP-Antwort, und die EventSource-API verbindet sich selbstständig neu. Ein WebSocket wandelt die Verbindung in einen bidirektionalen Kanal um, der Text oder Binärdaten in beide Richtungen überträgt. Nutze SSE für Feeds, Benachrichtigungen und Fortschrittsanzeigen; nutze WebSockets, wenn der Browser häufig Nachrichten zurücksenden muss.
Direkter Vergleich
Merkmal
Server-Sent Events
WebSocket
Richtung
Nur vom Server zum Client
In beide Richtungen gleichzeitig
Browser-API
EventSource
WebSocket
Protokoll
Einfaches HTTP, text/event-stream
HTTP Upgrade, danach ws:// oder wss://
Daten
Nur UTF-8-Text
Text oder Binärdaten
Wiederverbindung
Automatisch, setzt mit Last-Event-ID fort
Musst du selbst schreiben
Offene Verbindungen bei HTTP/1
6 pro Browser und Domain
Eigene Limits, von jedem Browser festgelegt
Du bist nicht sicher, was deine Funktion braucht? Hake in der Hilfe unten die Aussagen an, die auf sie zutreffen. Sie wendet dieselben Regeln wie die Tabelle oben an und sagt dir, welche API passt und warum.
Hake jede Aussage an, die deine Funktion beschreibt.
Lies die Empfehlung und die Begründung dazu.
Kopiere den passenden Client- und Servercode aus den Abschnitten weiter unten.
Ändere URL und Event-Namen auf deine eigenen und starte den Server mit Node.
Sende auf einem SSE-Stream alle 15 bis 30 Sekunden eine Kommentarzeile, einen Doppelpunkt gefolgt von Text, damit inaktive Proxys ihn nicht kappen.
Gib jedem SSE-Event eine id. Wenn der Browser sich neu verbindet, sendet er diesen Wert im Header Last-Event-ID zurück, und dein Server kann Verpasstes erneut senden.
Liefere SSE nach Möglichkeit über HTTP/2 aus, denn das Limit von sechs Verbindungen bei HTTP/1 gilt gemeinsam für alle Tabs, die deine Website geöffnet haben.
Achte bei WebSockets vor großen Sendeschüben auf bufferedAmount; die API selbst hat keinen Backpressure-Mechanismus.
Häufige Fragen
Kann der Browser mit SSE Daten an den Server senden?
Nicht über den Stream selbst. Der Event-Stream fließt nur vom Server zum Client, daher sendet der Browser seine Nachrichten mit gewöhnlichen fetch-Requests. Für chatähnlichen Verkehr in beide Richtungen ist ein WebSocket die sauberere Lösung.
Wie verhindere ich, dass EventSource sich neu verbindet?
Rufe auf dem Client close() auf. Auf Serverseite sagt der HTML-Standard, dass eine Antwort mit 204 No Content dem Client mitteilt, keine neue Verbindung mehr aufzubauen.
Kann ich mit EventSource einen Authorization-Header senden?
Nein. Der Konstruktor nimmt nur eine URL und ein Optionsobjekt, dessen einzige Einstellung withCredentials ist. Nutze ein Cookie, ein kurzlebiges Token in der URL oder einen fetch-basierten Reader, wenn du eigene Header brauchst.
Ist SSE veraltet, seit es WebSockets gibt?
Nein. Das Format text/event-stream ist für Einweg-Feeds weiterhin eine gute Wahl, weil es ohne Protokollwechsel über normale HTTP-Server, Proxys und Authentifizierung läuft.
Was verbraucht weniger Serverressourcen?
Beide halten pro Client eine langlebige Verbindung, der Unterschied ist also gering. Wichtiger ist, ob dein Hoster langlebige Antworten oder Protokoll-Upgrades überhaupt erlaubt, prüfe also zuerst seine Limits für die Request-Dauer.
Wie Server-Sent Events funktionieren
Der Server beantwortet ein normales GET mit Content-Type text/event-stream und hält die Antwort offen. Jede Nachricht besteht aus ein paar Zeilen wie event:, data: und id:, abgeschlossen durch eine Leerzeile. Mehrere data:-Zeilen in einer Nachricht werden mit Zeilenumbrüchen verbunden.
EventSource im Browser parst diesen Stream, löst für unbenannte Nachrichten ein message-Event und für alle anderen ein benanntes Event aus und verbindet sich nach einem Abbruch von selbst neu. Eine retry:-Zeile legt die Wartezeit in Millisekunden vor dem nächsten Versuch fest.
Wie WebSockets funktionieren
Der Client beginnt mit einem HTTP-Request mit Upgrade-Header, und der Server antwortet mit 101 Switching Protocols. Ab dann trägt die Verbindung WebSocket-Frames statt HTTP, und beide Seiten können jederzeit senden.
Diese Freiheit hat ihren Preis. Du schreibst deine eigene Logik für die Wiederverbindung, dein eigenes Nachrichtenformat, oft JSON mit einem type-Feld, und deinen eigenen Heartbeat. Ein Proxy, der den Upgrade-Header nicht weiterreicht, stoppt die Verbindung außerdem, bevor sie beginnt.
Eine schnelle Faustregel
Wenn der Browser hauptsächlich zuhört, wähle SSE. Live-Ergebnisse, Build-Logs, Bestellstatus, Benachrichtigungen und gestreamter Text passen alle dazu.
Wenn der Browser genauso viel spricht wie zuhört oder die Daten binär sind, wähle einen WebSocket. Multiplayer-Spiele, kollaborative Editoren und Chaträume passen dorthin.
Server-Sent Events: minimaler Code
SSE-Server in reinem Node
Keine Bibliothek nötig. Die Antwort bleibt offen; jeder Schreibvorgang ist ein Event, und die Kommentarzeile verhindert, dass inaktive Proxys sie schließen.
EventSource im Browser
addEventListener nutzt den Event-Namen aus dem Stream. Die Wiederverbindung passiert ohne eigenen Code.
WebSocket: minimaler Code
WebSocket-Server mit dem Paket ws
Installiere es mit npm install ws. Der Server sendet jede Nachricht in Großbuchstaben an den Client zurück, der sie geschickt hat.
WebSocket im Browser, mit einfacher Wiederverbindung
Anders als bei EventSource verbindet sich nichts automatisch neu, daher wartet dieser Code nach close kurz und öffnet einen neuen Socket.
Der Browser sendet viele Nachrichten zurück, mehrere pro Sekunde oder mehr
Die Daten sind binär, etwa Audio-Chunks oder Puffer mit Spielzuständen
Clients müssen nach einem Verbindungsabbruch verpasste Events nachholen
Der Verkehr läuft über Proxys oder Hosting, die nur einfaches HTTP verarbeiten
Server-Sent Events passen. Nichts, was du angehakt hast, braucht einen bidirektionalen Kanal, und EventSource liefert dir Wiederverbindung und Fortsetzung gratis.
Ein WebSocket passt. Du brauchst häufige Nachrichten vom Browser oder Binärdaten, die ein Event-Stream nicht übertragen kann.