Fuer die Echtzeit-Kommunikation zwischen Client und Server gibt es drei Hauptansaetze, jeder mit eigenen Vorteilen und idealem Anwendungsfall. Die Wahl haengt davon ab, ob Sie bidirektionale Kommunikation, einen unidirektionalen Datenstrom oder nur Kompatibilitaet mit aelterer Infrastruktur benoetigen. Die richtige Wahl beeinflusst Latenz, Skalierbarkeit und Implementierungskomplexitaet.
WebSocket¶
Ein voll duplexes Protokoll — Client und Server koennen jederzeit Daten ueber eine einzelne persistente TCP-Verbindung senden. Nach dem initialen HTTP-Handshake wird die Verbindung auf WebSocket aktualisiert und bleibt offen.
const ws = new WebSocket('wss://api.example.com/ws');
ws.onmessage = (e) => console.log(e.data);
ws.send('Hello');
WebSocket ist ideal fuer Szenarien mit hochfrequenten Nachrichten in beide Richtungen — Chat, Multiplayer-Spiele, kollaborative Editoren. Nachteil: komplexere Skalierung (Sticky Sessions oder Redis Pub/Sub fuer Nachrichtenverteilung), Reconnect-Logik muss explizit behandelt werden, und Load Balancer muessen WebSocket-Upgrade unterstuetzen.
SSE¶
Server-Sent Events bieten einen unidirektionalen Stream vom Server zum Client ueber Standard-HTTP. Einfacher als WebSocket mit automatischem Reconnect und nativer Browser-Unterstuetzung.
const es = new EventSource('/events');
es.onmessage = (e) => console.log(e.data);
SSE eignet sich fuer Benachrichtigungen, Live-Feeds, Dashboards und Streaming von AI-Antworten (LLM Token Streaming). Es funktioniert ueber HTTP/2 und erfordert keine spezielle Infrastruktur. Einschraenkungen: nur Server-to-Client und maximal 6 Verbindungen pro Domain in HTTP/1.1 (HTTP/2 loest dies durch Multiplexing).
Long Polling¶
Request → Server haelt die Verbindung bis Daten vorhanden → Antwort → Client sendet sofort einen neuen Request. Simuliert Push ueber Standard-HTTP.
Am einfachsten zu implementieren, funktioniert ueberall ohne spezielle Infrastruktur. Hoehere Latenz und Overhead durch wiederholte HTTP-Requests. Nur als Fallback geeignet, wenn weder WebSocket noch SSE verfuegbar sind.
Wann was¶
- WebSocket — Chat, Spiele, Collaboration, Echtzeit-Trading (bidirektional, hohe Frequenz)
- SSE — Benachrichtigungen, Feeds, Dashboards, LLM-Streaming (unidirektional, Server Push)
- Long Polling — Fallback fuer Legacy-Umgebungen
WebSocket fuer Duplex, SSE fuer Streaming¶
Long Polling nur als Fallback. Fuer die meisten modernen Anwendungen ist SSE ausreichend und einfacher zu implementieren als WebSocket.