Server-Sent Events vs. WebSockets vs. Polling: was sollten Sie verwenden?

Polling ist ein Pull-Modell, bei dem Clients wiederholt fragen; SSE und WebSockets halten eine Verbindung offen, damit der Server in Echtzeit senden kann. Die Wahl zwischen ihnen sind eigentlich drei Fragen – in welche Richtung fließen die Daten, wie oft ändern sie sich, und welche Infrastruktur liegt dazwischen – und die ehrliche Antwort fällt pro Feature unterschiedlich aus, nicht pro Anwendung.

Das Wichtigste in Kürze

Der Code, nebeneinander

// 1 · Short Polling — nach Zeitplan fragen
setInterval(async () => {
  const res = await fetch('/api/messages?since=' + lastId);
  render(await res.json());              // meist leer — Header trotzdem bezahlt
}, 2000);

// 2 · Server-Sent Events — ein HTTP-Stream, der Server sendet Textereignisse
const events = new EventSource('/api/stream');
events.onmessage = (e) => render(JSON.parse(e.data));   // verbindet automatisch neu

// 3 · WebSocket — ein Socket, beide Richtungen
const ws = new WebSocket('wss://api.example.com/live');
ws.onmessage = (e) => render(JSON.parse(e.data));
ws.send(JSON.stringify({ type: 'typing' }));            // der Client sendet auch

Was die meisten Anwendungen tatsächlich ausliefern – eine Abonnementschicht, die den Transport für Sie besitzt:

// JavaScript / Node.js — Back4app JS SDK
// The polling replacement: subscribe once, receive pushes
const query = new Parse.Query('Message');
query.equalTo('room', 'general');
const subscription = await query.subscribe();    // WebSocket under the hood
subscription.on('create', (msg) => render(msg)); // pushed, not polled
// subscription.unsubscribe() when the screen closes

// Flutter / Dart — Back4app Flutter SDK
// The polling replacement: subscribe once, receive pushes
final liveQuery = LiveQuery();
final query = QueryBuilder<ParseObject>(ParseObject('Message'))
  ..whereEqualTo('room', 'general');
final subscription = await liveQuery.client.subscribe(query); // WebSocket under the hood
subscription.on(LiveQueryEvent.create, (msg) => render(msg)); // pushed, not polled

// iOS / Swift — Back4app Swift SDK
// The polling replacement: subscribe once, receive pushes
let query = Message.query("room" == "general")
let subscription = try await query.subscribe() // WebSocket under the hood
subscription.handleEvent { _, event in
    if case .created(let msg) = event { render(msg) } // pushed, not polled
}

// Android / Kotlin — Back4app Android SDK
// The polling replacement: subscribe once, receive pushes
val client = ParseLiveQueryClient.Factory.getClient()
val query = ParseQuery.getQuery<ParseObject>("Message")
query.whereEqualTo("room", "general")
val subscription = client.subscribe(query) // WebSocket under the hood
subscription.handleEvent(SubscriptionHandling.Event.CREATE) { _, msg ->
    render(msg) // pushed, not polled
}

So funktioniert jede Technik

Short Polling ist ein setInterval um ein fetch herum: alle n Sekunden fragen, ob sich etwas geändert hat. Jeder Zyklus bezahlt eine vollständige HTTP-Anfrage samt Antwort – Header, Authentifizierung, Routing – meist nur, um “noch nichts” zu hören, und die mittlere Zustellverzögerung beträgt das halbe Intervall plus eine Umlaufzeit.

Long Polling verlagert das Warten auf den Server: Der Client fragt, der Server hält die Anfrage offen, bis Daten eintreffen oder ein Timeout greift, und der Client fragt sofort erneut. Es nähert Push über schlichtes HTTP an – der Behelf aus der Comet-Ära, dessen bekannte Kosten (ständige Wiederverbindungen, Header pro Anfrage, Sorgfalt bei der Reihenfolge) in RFC 6202 katalogisiert sind.

Server-Sent Events machen die gehaltene Antwort dauerhaft: eine HTTP-Antwort mit Content-Type: text/event-stream, die nie endet und in die der Server UTF-8-Ereignisse schreibt (Felder data:, event:, id:, retry:, gemäß WHATWG-Standard). Das EventSource des Browsers konsumiert sie – und verbindet sich automatisch neu, wobei es über Last-Event-ID wieder aufsetzt.

WebSockets verlassen HTTP vollständig: Ein Handshake stuft die Verbindung hoch (101 Switching Protocols, RFC 6455), danach tauschen beide Seiten Text- oder Binärframes mit rund 2–14 Byte Overhead aus, Full-Duplex, bis jemand den Socket schließt. Maximale Leistungsfähigkeit – und alles oberhalb des Frames (Nachrichtenformat, Bestätigungen, Wiederverbindung, Fortsetzen) müssen Sie selbst entwerfen.

SSE vs. WebSockets vs. Long Polling vs. Short Polling

Was kostet Polling? Die Overhead-Rechnung

Der Vergleich, den keine Ranking-Seite durchrechnet – 1.000 Clients mit 2-Sekunden-Poll gegen dieselben 1.000 per Push:

1.000 Clients, 2 s Polling                1.000 Clients, Push
→ 500 Anfragen/Sekunde dauerhaft          → 0 Anfragen im Ruhezustand
→ ~800 B Header pro Zyklus                → SSE-Ereignis-Framing ~5 B
→ ~0,4 MB/s reine Header-Steuer           → WebSocket-Frame-Overhead 2–14 B
→ fast jede Antwort leer                  → Bytes fließen nur bei Daten
→ durchschn. Zustellung: 1 s + RTT        → Zustellverzögerung: ~RTT

Die Lehre schneidet in beide Richtungen. Push gewinnt überwältigend, wenn Aktualisierungen häufig sind und Latenz zählt. Ändern sich die Daten aber stündlich, entstehen diese 500 Anfragen/s nie – ein behutsamer Poll (oder ein Neuladen beim Fokus) ist cachefreundlich, mit curl debuggbar, serverless-tauglich und frei von Verbindungszustand. Polling pauschal abzutun ist Mode, nicht Ingenieurskunst.

Wiederverbindung: der stille Unterschied

Verbindungen brechen ab – Funkzellenwechsel, zugeklappte Laptops, Leerlauf-Timeouts von Proxys (oft 30–120 s, weshalb SSE-Streams Kommentar-Keep-alives senden und WebSockets Ping-/Pong-Frames austauschen). Was danach passiert, trennt die Transporte. Der Vertrag von SSE regelt es: Der Browser versucht es mit der vom Server gesetzten retry-Verzögerung erneut und legt Last-Event-ID vor, sodass ein Server mit kurzem Ereignispuffer den Stream lückenlos fortsetzt. Ein roher WebSocket schließt einfach: Wiederverbindung mit exponentiellem Backoff, Nachholen verpasster Nachrichten und ein Fortsetzungsprotokoll sind allesamt Anwendungscode – der am meisten unterschätzte Posten hinter “wir nehmen einfach WebSockets”. So oder so braucht ein Client, der Minuten offline war, ein Nachholen (das erneute Ausführen der Basisabfrage), nicht nur eine Wiederverbindung – Push-Transporte liefern Deltas, und Deltas setzen eine Ausgangsbasis voraus.

Warum KI-Chats über SSE streamen

Token-für-Token-Ausgabe eines Modells ist die perfekte SSE-Arbeitslast: streng einseitig, Text, schubweise, über schlichtes HTTP, das jeder Proxy und jedes CDN versteht, mit Semantik zum Fortsetzen abgebrochener Generierungen. Deshalb streamen LLM-APIs ihre Completions ganz überwiegend als text/event-stream – und deshalb lohnt sich das Muster über Chatbots hinaus: Fortschrittsanzeigen, Build-Protokolle und Dashboards haben dieselbe Form. WebSockets betreten KI-Produkte an der Sprachebene, wo der Nutzer mitten im Stream unterbricht – in dem Moment, in dem der Client zurücksprechen muss, kauft die Duplex-Steuer etwas ein.

Push skalieren: warum Zustandshaltung zählt

Polling und SSE sind für einen Load Balancer gewöhnliches HTTP; jeder Server kann jede Anfrage beantworten (SSE hält zwar einen Stream, behält aber HTTP-Semantik und braucht nur ungepufferte Proxys). WebSockets sind Zustand: Jeder Socket heftet einen Client an einen Prozess, also bedeutet horizontale Skalierung verbindungsbewusste Lastverteilung, kontrolliertes Leeren bei Deployments und ein Pub/Sub-Backplane (üblicherweise Redis), damit eine auf Server A veröffentlichte Nachricht die Sockets auf Server B erreicht. Über HTTP/1.1 hat SSE seinen eigenen berühmten Fallstrick – sechs Verbindungen pro Origin, gemeinsam über alle Tabs (Warnung bei MDN) –, den HTTP/2 erledigt, wo Streams über eine Verbindung multiplext werden. Nichts davon ist exotisch; all das ist der Grund, warum es verwaltete Echtzeit-Schichten gibt.

Typische Anwendungsfälle

• Benachrichtigungs-Feeds und Ticker – einseitig, Text, häufig: das Heimspiel von SSE.
• Streaming von KI-Antworten – der aktuelle Paradefall für SSE; eine Richtung, Token-Text, Fortsetzen nach Abbruch.
• Chat und Zusammenarbeit – Nachrichten fließen in beide Richtungen mit niedriger Latenz: WebSockets, meist über eine verwaltete Schicht.
• Live-Dashboards – Server-Push von Abfrageergebnissen; in der Praxis ein Live-Query-Abonnement statt eines selbstgebauten Transports.
• Langsam veränderliche Daten – Bestände, die stündlich aktualisiert werden, Einstellungsbildschirme: ehrlicherweise Polling oder Neuladen beim Fokus.

Welchen Transport sollten Sie verwenden? Eine Entscheidungsmatrix

Grenzen und Trade-offs

• SSE ist nur Text und nur einseitig. Binärdaten müssen kodiert werden; jeglicher Verkehr vom Client zum Server läuft über separate HTTP-Anfragen – in Ordnung für Bestätigungen, falsch für Chat.
• WebSockets bringen Sie ins Protokollgeschäft. Framing, Bestätigungen, Wiederverbindung, Fortsetzen, Backpressure: Der Transport ist leicht, der Vertrag darüber ist die Arbeit.
• Die Einfachheit von Polling verbirgt eine Latenzuntergrenze. Keine Feinabstimmung entkommt der mittleren Verzögerung von Intervall/2; ein kürzeres Intervall kauft nur die Header-Steuer zurück.
• Long Polling ist bei Last das Schlechteste aus beiden Welten. Gehaltene Anfragen verbrauchen Serverkapazität wie Push, während sie pro Nachricht den Wiederverbindungs-Overhead wie Pull bezahlen – deshalb überlebt es nur als Rückfallstufe.
• Alle Push-Transporte brauchen kooperative Proxys. Stream-Pufferung bricht SSE stillschweigend; entfernte Upgrade-Header brechen WebSockets – testen Sie durch die echte Infrastruktur, nicht über localhost.

Echtzeit-Transporte mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Die Transportentscheidung nehmen Ihnen weitgehend Live Queries ab: Die Code-Tabs oben abonnieren eine Abfrage und empfangen gesendete Ereignisse über eine WebSocket-Flotte, die die Plattform betreibt – samt Verbindungen, Wiederverbindungen, Berechtigungsprüfungen und Fan-out über Server hinweg –, sodass aus “SSE oder WebSockets?” ein Implementierungsdetail wird, das Sie erben, statt Infrastruktur, die Sie bauen. Wo ein gemächlicherer Takt wirklich passt, läuft dieselbe Abfrage als schlichter Abruf nach Ihrem Zeitplan; eine Parse-Abfrage zu pollen und sie zu abonnieren liegen eine Zeile auseinander, was den richtigen Transport pro Feature zu einem Refactoring macht und nicht zu einer Neuentwicklung.