WebSockets gegen SSE gegen Long Polling – Echtzeit ohne Panik

Die meisten Entwickler greifen standardmäßig auf WebSockets zurück. Das ist meistens falsch.

Nicht weil WebSockets schlecht sind – sie sind hervorragend in ihrem Bereich. Doch sie bringen erhebliche Infrastrukturüberhead: festgehaltene Sitzungen auf Lastverteilern, benutzerdefinierte Herzschlaglogik, Authentifizierung umgehen und Proxykonfigurationen, die nur dann funktionieren, wenn jemand Ihre App in einem Unternehmen öffnet. Für die meisten „Echtzeit“-Anforderungen ist dieser Overhead nicht gerechtfertigt.

Die kurze Version: Wenn Daten nur von Server zu Client fließen, verwenden Sie Server-Sent Events (SSE). Wenn der Client Daten mit geringer Latenz zurücksenden muss, verwenden Sie WebSockets. Wenn Ihre Aktualisierungsfrequenz in Sekunden gemessen wird und Sie die einfachste mögliche Bereitstellung wünschen, funktioniert langfristige Polling noch – und daran gibt es nichts Schlechtes.

Der Vergleich

Langfristige Polling

Langfristige Polling ist standardmäßige HTTP-Polling, bei der der Server die Anfrage offen hält, bis etwas zurückgegeben wird – oder ein Timeout auslöst. Der Client sendet eine Anfrage, der Server wartet, gibt die Antwort zurück, sobald Daten verfügbar sind, und der Client startet sofort die nächste Anfrage. Es ist ein Schleifenmuster, das als Netzwerkaufruf verkleidet ist.

Das ist tatsächlich für eine Reihe von Anwendungsfällen völlig in Ordnung:

• Benachrichtigungsabzeichen — ungelesene Zähler, die alle 30 Sekunden aktualisiert werden, benötigen keine persistente Verbindung.
• Admin-Dashboards mit vermindertem Frischelevel — Metriken, die alle 15–60 Sekunden aktualisiert werden, funktionieren gut mit Polling.
• Mobile Apps mit unzuverlässigen Verbindungen — Persistente Verbindungen werden durch aggressive Netzwerkverwaltung getötet; Polling verbindet sich sauber bei jeder Anfrage.
• Hinter Unternehmens-Proxy-Servern — Viele Unternehmens-Proxy-Server buffer oder beenden nicht-standardisierte Verbindungen. HTTP-Polling funktioniert überall, ohne Ausnahmen.

Die Skalierungsbeschränkung ist echt. Jede offen gehaltene Anfrage verbraucht einen Verbindungslot. Auf threadbasierten Servern wird dies teuer; auf event-loop-basierten Servern (Node.js, Tornado, Go mit Goroutinen) ist es machbar, aber nicht kostenlos. Bei zehntausenden gleichzeitiger Benutzer beginnt die Berechnung der Serverressourcen zu zählen.

Server-Sent Events (SSE)

SSE ist die Option, die die meisten Entwickler bei ihrem Weg zu WebSockets verpassen. Das ist ein Fehler für alle Anwendungsfälle, bei denen Daten nur in eine Richtung fließen: von Server zu Client.

Es läuft über einfaches HTTP. Der Server setzt Content-Type: text/event-stream und schreibt zeilengetrennte Nachrichten in den Antwortkörper unendlich lang. Der Browser-Standard-API behandelt automatisch die Wiederverbindung – einschließlich eines EventSource Headers, damit der Server nach einem Abbruch eine Stream-Verbindung wieder aufnehmen kann. Sie erhalten benannte Ereignistypen, konfigurierbare Wiederholungsintervalle und benötigen keine Bibliothek. Last-Event-ID Was SSE richtig macht:

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

source.addEventListener('priceUpdate', (e) => {
  const { price, symbol } = JSON.parse(e.data);
  updateTicker(symbol, price);
});

source.onerror = () => {
  // EventSource reconnects automatically — nothing to do here
};

Standard-HTTP

• — funktioniert durch Lastverteilern, Reverse-Proxy-Servern und CDNs ohne Konfiguration. Keine festgehaltene Sitzungen. Automatische Wiederverbindung
• — eingebaut in der Spezifikation. Setzen Sie das Feld in der Stream-Verbindung, um das Intervall zu konfigurieren; der Client kümmert sich um den Rest. retry: HTTP/2-Multiplexing
• — entfernt die alte Grenze von 6 Verbindungen pro Domain aus HTTP/1.1. Wenn Sie auf HTTP/2 (Sie sollten) sind, ist das keine Sorge mehr. Einfachere Serverimplementierung
• — halten eine Verbindung offen und schreiben darauf. Kein Protokollhandshake, keine Frame-Parsing, keine Herzschlaglogik. Die einzige echte Beschränkung: SSE ist einseitig. Client können Daten über eine SSE-Verbindung nicht senden. In der Praxis ist das selten ein Problem – verwenden Sie reguläre POST-Anfragen für alles, was der Client senden muss, zusammen mit dem SSE-Stream für Server-Ereignisse. Beide funktionieren ohne Probleme zusammen.

Das HTTP/1.1-Verbindungslimit ist wertvoll zu wissen. Browser begrenzen auf 6 gleichzeitige Verbindungen pro Domain über alle Tabs. Drei Browser-Tabs, die jeweils zwei SSE-Streams verbrauchen, führen zum Limit. HTTP/2 beseitigt dies durch Multiplexing. Wenn Sie nicht sicherstellen können, dass HTTP/2 geliefert wird (einige ältere CDN-Konfigurationen, einige Unternehmens-Proxy-Server), halten Sie das im Auge.

WebSockets sind das richtige Werkzeug, wenn Sie tatsächlich bidirektionale, niedrige Latenz-Messaging benötigen. Die Anwendungsfälle, die die Komplexität rechtfertigen:

WebSockets

Chat

• — Nachrichten von jedem Benutzer müssen in nahezu reellen Zeit an andere gelangen. WebSockets sind hier das Standardwerkzeug, und das hat gute Gründe. Multiplayer-Spiele
• — Spielzustände synchronisieren zwischen Clients ständig, oft mit 20–60 Updates pro Sekunde. Keine andere Methode kommt der gleichen Effizienz pro Frame nahe. Gemeinsame Bearbeitung
• — CRDT- oder OT-basierte reale Zeitbearbeitung (Notion, Figma, Google Docs-artig) erfordert, dass jeder Tastendruck mit minimalem Latenz verbreitet wird. Trading-Terminals
• — Preise mit Sub-100ms und Auftragsabgabe auf derselben Verbindung. WebSockets wurden dafür entwickelt. Die Infrastrukturkosten, die SSE und Polling vermeiden:

Festgehaltene Sitzungen

• — WebSocket-Verbindungen sind Zustandsbasiert und verknüpft mit einem einzelnen Serverprozess. Lastverteilern benötigen Sitzungsaffinität (IP-Hash oder Cookie-basiert), um Wiederverbindungen korrekt zu leiten. Ohne sie kann ein wiederverbindender Client auf einen Server landen, der keine Kenntnis über ihre Sitzung hat. Proxy- und CDN-Konfiguration
• — Nginx, HAProxy und Cloudflare unterstützen WebSockets, erfordern jedoch explizite Konfiguration ( Headers,Upgrade und Connection in Nginx). Einige Unternehmens-Feuertore blockieren proxy_http_version 1.1 . Sie werden dies in Support-Tickets von Benutzern in bestimmten Büros erfahren. 101 Switching ProtocolsAuthentifizierungs-Komplexität
• — WebSockets können nach dem ersten Handshake keine benutzerdefinierten Headers setzen. Token-Authentifizierung bedeutet normalerweise, den Token in der Abfragezeichenkette (schlecht, häufig) oder in der ersten Nachricht nach der Verbindung (besser, aber erfordert Serverseitige Gate-Logik) zu übergeben. Herzschläge
• — Die Spezifikation erfordert keine Keepalives. Ohne benutzerdefinierte Ping/Pong-Logik werden tote Verbindungen erst dann erkannt, wenn das nächste Nachrichtenversagen auftritt. Entweder implementieren Sie Herzschläge oder akzeptieren Sie veraltete Verbindungen, die sich anhäufen. Keine davon sind Blocker – sie sind lösbare Komplexitäten. Sie existieren nicht bei SSE oder HTTP-Polling. Wenn Sie WebSockets für eine Benachrichtigungs-Feed oder ein Live-Dashboard wählen, zahlen Sie dafür für keinen Grund.

Wie man wählt

Arbeiten Sie diese Schritte nacheinander ab:

Bedarf der Client, um Daten mit hoher Frequenz an den Server zu senden, oder ist eine Latenz unter 200ms entscheidend?

1. Nein → WebSockets überspringen. Fließen Daten nur von Server zu Client?
2. Ja → SSE ist wahrscheinlich die richtige Wahl. Sind Sie auf HTTP/2?
3. Wenn ja, hat SSE für die meisten Anwendungsfälle keine sinnvollen Beschränkungen. Wenn nein, berücksichtigen Sie die 6-Verbindungsgrenze. Ist Ihre Bereitstellung serverlos oder hinter Infrastruktur, die persistente Verbindungen nicht unterstützt?
4. SSE funktioniert auf den meisten serverlosen Plattformen (Vercel, Cloudflare Workers über die Streams-API); WebSockets auf serverlosen Plattformen erfordern zusätzliche Infrastruktur. Ist Ihre Aktualisierungsfrequenz 15 Sekunden oder mehr?
5. Langfristige Polling. Halten Sie es einfach. Wenn Sie diese Schritte durchlaufen und die Antwort immer noch WebSockets ist – gut. Jetzt verwenden Sie sie für den richtigen Grund, anstatt für den Standard.

Debugging von Ereignis-Payloads

Felder und WebSocket-Nachrichten tragen fast immer JSON. Wenn Sie eine störende Stream-Verbindung debuggen, ist das schnellste Verfahren, den Rohinhalt in

SSE data: zu kopieren, um die Struktur auf einen Blick zu sehen – besonders bei verschachtelten Ereignisobjekten, bei denen ein fehlender Klammern oder ein zusätzlicher Komma die Parse schlichtig töten. IO Tools’ JSON Formatter WebSockets vs SSE vs Long Polling — Real-Time Without the Panic 2

Das könnte Ihnen auch gefallen

Neu

OAuth 2.0-Flows: Authorization Code, PKCE, and Client Credentials

Mehr lesen "

Aktualisiert am 13. Juni 2026

Neu

HTTP/2 vs HTTP/3: Was tatsächlich geändert wurde (und ob Ihre API es beachtet)

Mehr lesen "

Aktualisiert am 12. Juni 2026

Neu

BIP39 Samenphrasen: Was diese 12 Wörter tatsächlich sind und wie die HD-Wallet-Ableitung funktioniert

Mehr lesen "

Veröffentlicht am 12. Juni 2026

Neu

Validierung des OpenAPI-Spezifikations: Fehler in Ihrer Swagger-Datei vor dem Versagen der Clients erkennen

Mehr lesen "

Aktualisiert am 9. Juni 2026