WebSockets vs SSE vs Long Polling — Wählen Sie das richtige Muster für echte Zeit-Verbindungen, bevor Ihre Chat-Anwendung auseinanderfällt

Sie haben eine Dashboard-App entwickelt. Benutzer benötigen Live-Daten-Updates. Sie haben auf WebSockets zurückgegriffen – weil das, was alle tun. Jetzt debuggen Sie anständige Sitzungen um 2 Uhr morgens, weil Ihr Load Balancer die Clients immer an die falsche Pod-Instanz weiterleitet. Die Daten, die Sie übermitteln? Eine einzelne JSON-Zahl alle 10 Sekunden. WebSockets waren übertrieben.

Das passiert ständig. Entwickler behandeln WebSockets als Standardlösung für reale Zeit-Features, während SSE oder Long Polling schneller, besser skalierbar und kostengünstiger operiert hätten. Hier ist, wie Sie tatsächlich entscheiden können.

Die Entscheidungstabelle

Bevor die tiefere Analyse beginnt, hier die vollständige Vergleichstabelle. Verwenden Sie diese, um eine Entscheidung zu treffen, und lesen Sie dann die Abschnitte unten, wenn Sie die Begründung benötigen.

Besonderheit	Langfristige Polling	Server-Sent Events	WebSockets
Protokoll	HTTP/1.1	HTTP/1.1+ (chunked)	WS (HTTP-Upgrade)
Richtung	Klient zieht nur	Server → Klient nur	Vollständig bidirektional
Browserunterstützung	Alle Browser	Alle moderne Browser (kein IE11)	Alle modernen
Automatischer Wiederverbindung	Manuell – Sie schreiben den Loop	Bereitgestellt über EventSource	Manuell oder über eine Bibliothek
CDN / Proxy freundlich	Ja	Hauptsächlich (Ablaufzeiten beobachten)	NEIN
Horizontale Skalierung	Stateless, trivial	Stateless, trivial	Erfordert sticky Sessions oder Pub/Sub-Broker
Infrastrukturkomplexität	Niedrig – einfaches HTTP	Niedrig – einfaches HTTP	Hoch – stateful Verbindungen, LB-Konfiguration, Broker
Latenz	Poll-Intervall + Rundreise	Näherungsweise Echtzeit	Näherungsweise Echtzeit
APIs, Microservices, Authentifizierung über mehrere Domänen	Niedrigfrequente Updates, alte Infrastruktur	Dashboards, Feeds, Benachrichtigungen	Chat, gemeinsame Bearbeitung, Spiele

Long Polling: Das unattraktive Arbeitspferd

Long Polling ist nicht „alt“ oder „falsch“ – es ist einfach HTTP. Der Client macht eine Anfrage, der Server hält sie offen, bis etwas zu sagen ist (oder eine Timeout-Verzögerung eintritt), der Client erhält die Antwort und startet sofort die nächste Anfrage. Wiederholen Sie.

Es existiert schon lange vor der Einführung von WebSockets und läuft weiterhin in Millionen von Produktionsanwendungen. Der Grund: Es ist einfach HTTP. Ihr bestehendes Reverse Proxy, CDN, Load Balancer und Monitoring verstehen es ohne Konfiguration. Keine sticky Sessions, kein Protokoll-Upgrade, kein WS-ähnliches Infrastruktur-System.

Die Nachteile sind jedoch echt. Jede „Aktualisierung“ ist ein vollständiger HTTP-Request-Zyklus – Header, TCP-Überhead (außer bei HTTP/2), Serverseitige Anfrage-Warteschlangen. Unter hohem Konkurrenzverhalten wird dies auf dem Server teuer. Und die Latenz-Untergrenze ist die Rundreisezeit jedes Polls, nicht die Latenz des Ereignisses selbst. Wenn Sie alle 5 Sekunden pollen und ein Ereignis bei der Sekunde 1 ausgelöst wird, wartet der Benutzer 4 weitere Sekunden.

Wann wird es verwendet: Legacy-Systeme, in denen die Einführung einer persistierenden Verbindungsschicht nicht die Infrastrukturänderung wert ist. Niedrigfrequente Updates (einmal pro Minute oder weniger). Umgebungen, in denen SSE durch zu überzogenen Proxies getötet wird. Polling, das von Clients explizit kontrolliert wird – z. B. Statusprüfungen von Aufgaben, Ergebnisse asynchroner Aufgaben.

Server-Sent Events: Das, was jeder vergisst

SSE ist ein Standard (HTML Living Standard) der eine Server-Push-Strömung von Text-Ereignissen über eine einzelne, langwierige HTTP-Verbindung ermöglicht. Der Browser führt automatisch Wiederherstellung durch. Sie schreiben keinen Wiederherstellungsschleife – die EventSource API verbindet sich automatisch mit dem letzten Ereignis-ID, die sie gesehen hat, sodass Sie nach einem Netzwerk-Problem eine Strömung fortsetzen können.

Die Wire-Format ist beinahe einfach:

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache

id: 1
event: price-update
data: {"symbol":"BTC","price":67420}

id: 2
event: price-update
data: {"symbol":"ETH","price":3521}

Jedes Ereignis ist ein einfacher Text mit optionalen id, event, dataund retry Feldern, getrennt durch Leerzeilen. Sie können SSE-Endpunkte direkt mit cURL testen – verwenden Sie die cURL Befehlsersteller um die Anfrage mit dem richtigen Accept-Header (text/event-stream) und die Antwort zu streamen.

Auf der Client-Seite:

const es = new EventSource('/api/events');

es.addEventListener('price-update', (e) => {
  const payload = JSON.parse(e.data);
  updateDashboard(payload);
});

es.onerror = () => {
  // EventSource will auto-reconnect. You don't need to do anything here
  // unless you want to log or update UI state.
};

SSE hat eine echte Beschränkung: Es ist nur serverseitig-klientseitig. Der Client kann keine Daten über die gleiche Verbindung senden – alle vom Client initiierten Aktionen erfolgen über normale HTTP-Anfragen. Für die meisten Dashboard-, Benachrichtigungs- und Feed-Anwendungen ist das in Ordnung. Sie haben die clientseitige Richtung nicht verwendet.

Das andere Problem: Einige Proxies buffer den Antworttext und leiten ihn erst nach Schließen der Verbindung weiter, was die Streaming-Funktion vollständig unterbricht. NGINX benötigt proxy_buffering off. Cloudflare’s Free-Tier bufferiert SSE. Wenn Ihre Infrastruktur einen Buffer-Proxy in der Mitte hat und Sie diese nicht konfigurieren können, funktioniert SSE nicht und Sie benötigen WebSockets oder Long Polling.

Wann wird es verwendet: Live-Dashboards, Benachrichtigungsfeeds, Aktivitätsprotokolle, AI-Response-Streaming (genau das, was ChatGPTs Streaming-API verwendet), Aktienkurse, Bereitstellungsbau-Log-Stream. Jede Anwendung, in der der Server Daten senden muss und der Client keine Rückmeldungen senden muss.

WebSockets: Wann sie tatsächlich wert sind

WebSockets bieten eine vollständig bidirektionale, persistente Verbindung über eine einzelne TCP-Verbindung. Nach dem HTTP-Upgrade-Handshake können beide Seiten gegebenenfalls gezielt Nachrichten senden. Die Latenz ist so niedrig wie möglich – keine neue Anfrage pro Nachricht, keine Header pro Frame.

Die Abwägung ist, dass sie stateful sind. Der Server muss jede offene Verbindung verfolgen. Dies führt sofort zu Problemen bei Skalierung: Load Balancer leiten nach Verbindung (nicht nach Anfrage), sodass sticky Sessions oder ein Pub/Sub-Broker (z. B. Redis) erforderlich sind, um Nachrichten über mehrere Server-Instanzen zu verteilen. Ihr CDN kann WebSocket-Verkehr nicht cache. Ihr Reverse Proxy benötigt explizite Konfiguration für das Upgrade. Ihre Monitoring-Tools müssen WS-Frames verstehen, um Payload-Ebene-Überblick zu erhalten.

Nichts davon ist unüberwindbar, aber es ist realer Aufwand. Wenn Sie ein Projekt starten und Optionen bewerten, ist „es ist einfach HTTP“ im Vergleich zu „stateful WS-Verbindungen mit einer Redis-Pub/Sub-Schicht“ ein bedeutender Unterschied in der Komplexität.

WebSocket-Payloads sind typischerweise JSON. Wenn Sie eine WS-Integration debuggen und die Nachrichten inspizieren oder formatieren müssen, erleichtert die JSON-Formatierer es, minimierte Payloads aus der Netzwerk-Option in den Entwicklertools zu lesen.

Wann verwenden Sie sie: Chat-Anwendungen (wirklich bidirektional – jede Nachricht ist client-initiiert). Gemeinsame Bearbeitung (z. B. Figma, Google Docs – mehrere Clients schreiben an einem gemeinsamen Zustand). Mehrspieler-Spiele (hochfrequente, niedrige Latenz-Zustandsynchronisierung). Finanzhandels-Terminals (Sub-100ms Latenz auf Orderbooks). Im Grunde: alles, was die Client häufig Daten senden muss, nicht nur empfängt.

Das Skalierungsproblem, das niemand erwähnt, bis es zu spät ist

Long Polling und SSE sind stateless auf der HTTP-Ebene. Jede Anfrage kann auf jede Server-Instanz landen. Ihre horizontale Skalierung ist langweilig – und das ist ein Vorteil: Fügen Sie einfach mehr Instanzen hinzu, fertig. Verbindungszustand besteht nur während der offenen HTTP-Verbindung, und Load Balancer leiten frei.

WebSockets sind stateful. Client A’s Verbindung befindet sich auf Server 1. Wenn Sie eine Nachricht an Client A von Server 2 senden wollen (weil das Ereignis dort begann), muss Server 2 über diese Verbindung Bescheid wissen. Die Standardlösung ist ein Pub/Sub-Broker – Redis Pub/Sub, Kafka oder verwaltet Services wie Pusher oder Ably, die all diese Komplexitäten abstrahieren. Sie bauen diese Schicht selbst oder zahlen dafür.

Pusher kostet $49/Monat für 500 gleichzeitige Verbindungen. Ably ist ähnlich preisgünstig. Wenn Ihr „real-time-Funktion“ eine Benachrichtigungs-Abzeichen ist, das aktualisiert wird, wenn jemand Ihren Beitrag liken, ist das eine Menge Geld für SSE, die Sie kostenlos neben Ihrer bestehenden API hosten könnten.

HTTP/2 verändert die Long Polling-Mathematik

Klassische HTTP/1.1 Long Polling ist eine Anfrage pro Verbindung pro laufender Halt. Bei HTTP/2 bedeutet Multiplexing mehrere Streams über eine einzelne TCP-Verbindung. Die Überhead ist geringer. Das ist kein Grund, Long Polling gegenüber SSE zu wählen, aber es bedeutet, dass die Kritik „HTTP-Überhead ist teuer“ in 2024 weniger gilt als in 2012, als diese Vergleiche erstmals geschrieben wurden.

Wenn Sie end-to-end auf HTTP/2 sind (Client zu Server, ohne intervenierenden Proxy, der heruntergegriffen wird), skaliert Long Polling besser als die meisten älteren Benchmark-Schätzungen nahezu.

Schnelle Entscheidungsleitfaden

Stoppen Sie das Lesen, wenn Ihr Anwendungsfall einer dieser Fälle entspricht:

• Aktualisierungsfrequenz < 1/Minute, alte Infrastruktur, einfache Polling-Logik: Long Polling. Komplizieren Sie es nicht.
• Server sendet Daten, Client liest hauptsächlich, standardmäßige HTTP-Infrastruktur: SSE. Dies deckt 80% „real-time“-Features ab.
• Client sendet Daten häufig, Latenz < 100ms ist entscheidend, vollständig bidirektional: WebSockets. Jetzt ist die Komplexität wert.
• Sie verwenden AI-Streaming (OpenAI, Anthropic usw.): SSE – das ist genau das, was ihre Streaming-APIs verwenden.
• Mehrspieler-Spiel oder gemeinsame Bearbeitung: WebSockets oder ein speziell entwickeltes Framework (Liveblocks, PartyKit usw.).

Die Standardantwort ist nicht WebSockets. Es ist SSE – bis Sie einen speziellen Grund dafür haben, dass es nicht ausreicht. Die Anzahl der Produktionsanwendungen, die tatsächlich eine vollständig bidirektionale Echtzeitfunktion benötigen, ist viel kleiner als die Anzahl der Anwendungen, die verwenden Sie WebSockets verwenden. Dieser Abstand ist ein technischer Schuld, die sich am frühen Morgen vor einem Load Balancer-Konfigurations-Problem ansammelt.

Das könnte Ihnen auch gefallen