SSE — was es ist, Server-Sent Events und unidirektionales Streaming

Was ist SSE?

SSE (Server-Sent Events) ist eine Technologie, die es einem Webserver ermöglicht, nach dem Aufbau einer Verbindung jederzeit Daten an den Client zu senden. Sie wird von WHATWG als Teil des HTML Living Standard standardisiert und verwendet den MIME-Typ text/event-stream. SSE unterstützt die Übertragung von Textdaten mit der Möglichkeit, eine Nachrichten-ID, einen Ereignistyp und eine Wiederverzögerungszeit anzugeben.

Im Gegensatz zu WebSocket, das ein bidirektionales Protokoll und eine Upgrade-Anfrage erfordert, arbeitet SSE über gewöhnliches HTTP. Der Server setzt den Header Content-Type: text/event-stream, sendet Daten in Blöcken und hält die Verbindung offen. Der Client empfängt Daten über die browserinterne EventSource API, die den Stream automatisch parst und Ereignisse generiert.

Laut CanIUse (2025) wird die EventSource API in 97,5 % der Browser weltweit unterstützt. Sie wird nicht unterstützt in Internet Explorer und einigen mobilen Browsern (Samsung Internet vor Version 7.0). Für diese Fälle gibt es Polyfills, die EventSource über XHR-Streaming emulieren. SSE funktioniert nicht mit HTTP/1.1 Pipelining, ist aber vollständig kompatibel mit HTTP/2 Server Push.

Geschichte und Standardisierung

SSE wurde 2009 als Teil der HTML5-Spezifikation unter dem Namen Server-Sent DOM Events vorgeschlagen. Die erste Implementierung erschien in Opera 9.0, dann in Firefox 6.0 (2011), Chrome 9.0 (2011) und Safari 5.0 (2010). 2015 wurde die Spezifikation in einen eigenen Abschnitt des HTML Living Standard verschoben. Trotz einer zehnjährigen Geschichte ist SSE aufgrund seiner unidirektionalen Natur weniger beliebt als WebSocket.

Wie SSE funktioniert

Die Funktionsweise von SSE ist wie folgt: Der Client erstellt eine EventSource-Instanz mit der URL des Server-Endpunkts. Der Browser sendet eine GET-Anfrage mit dem Header Accept: text/event-stream. Der Server antwortet mit Status 200 OK und dem Header Content-Type: text/event-stream und beginnt dann mit dem Senden von Daten im Event-Stream-Format. Die Verbindung bleibt offen, bis der Server ein Beendigungssignal sendet oder der Client close() aufruft.

Auf der Serverseite werden die Daten in Blöcken (Chunked Transfer Encoding) gesendet. Jeder Datenblock ist eine Textnachricht, die aus Feldzeilen (event, data, id, retry) besteht. Der Server kann jederzeit Nachrichten senden, was SSE ideal für Benachrichtigungen und Statusaktualisierungen macht. Die Verbindung benötigt keinen ständigen Heartbeat-Paketaustausch (wie WebSocket), obwohl das retry-Feld die Häufigkeit der Wiederverbindung steuert.

Laut Leistungstests (2024) bietet SSE einen Durchsatz von bis zu 10.000 Nachrichten pro Sekunde pro Verbindung bei einer Nachrichtengröße von 256 Bytes. Auf der Serverseite verbraucht jede SSE-Verbindung etwa 5–10 KB Speicher, sodass ein Server mit 1 GB RAM über 50.000 gleichzeitige Verbindungen unterstützen kann. Dies ist aufgrund des Fehlens eines binären Protokolls deutlich weniger als bei WebSocket.

Event-stream-Format

Das text/event-stream-Format ist ein einfaches Textprotokoll, bei dem jede Nachricht aus benannten Feldern besteht, die durch Zeilenumbruchzeichen getrennt sind. Jedes Feld hat das Format „Feldname: Wert“. Nachrichten werden durch zwei Zeilenumbruchzeichen (\n\n) getrennt.

Unterstützte Felder: event (Ereignistyp, Standard ist message), data (Datenzeichenfolge, kann mehrzeilig sein), id (letzter Ereignisbezeichner, gespeichert in Last-Event-ID), retry (Wiederverbindungszeit in Millisekunden). Kommentare beginnen mit einem Doppelpunkt (:) und werden vom Parser ignoriert, können aber für Heartbeat verwendet werden.

Event-Stream-Beispiel

: heartbeat comment
event: update
data: {"user": "Alice", "action": "typing"}
id: 1001

event: notification
data: {"type": "info", "text": "New version available"}
data: {"type": "action", "url": "/upgrade"}
retry: 3000

event: close
data: Session ended

EventSource API auf dem Client

Die EventSource API ist eine integrierte Browser-Schnittstelle zum Empfangen von SSE. Zum Aufbau einer Verbindung rufen Sie einfach den Konstruktor mit der Endpunkt-URL auf. EventSource stellt automatisch die Verbindung her, behandelt die Wiederverbindung und parst eingehende Nachrichten in JavaScript-Ereignisse.

EventSource-Ereignisse: open (Verbindung hergestellt), message (Nachricht ohne Ereignisangabe empfangen), error (Verbindungsfehler). Für benutzerdefinierte Ereignisse (event: custom) können Sie addEventListener mit dem Ereignisnamen verwenden. EventSource sendet bei der Wiederverbindung automatisch den Last-Event-ID-Header, sodass der Server den Stream an der unterbrochenen Stelle fortsetzen kann.

Laut MDN-Dokumentation (2025) unterstützt EventSource CORS und die Übertragung von Anmeldeinformationen (withCredentials). EventSource eignet sich nicht zum Senden benutzerdefinierter Header oder Anfragekörper — dafür ist eine manuelle Implementierung über fetch + ReadableStream erforderlich. EventSource unterstützt keine binären Daten — nur Text und JSON.

Clientseitiger JavaScript-Code

const eventSource = new EventSource('/api/events/stream');

eventSource.addEventListener('open', () => {
    console.log('SSE-Verbindung geöffnet');
});

eventSource.addEventListener('message', (event) => {
    const data = JSON.parse(event.data);
    console.log('Empfangen:', data);
    renderUpdate(data);
});

eventSource.addEventListener('notification', (event) => {
    const notification = JSON.parse(event.data);
    showNotification(notification.text);
});

eventSource.addEventListener('error', (error) => {
    console.error('SSE-Fehler:', error);
    // Browser stellt automatisch wieder her
});

// Verbindung schließen
eventSource.close();

SSE vs WebSocket: Vergleich

SSE und WebSocket sind unterschiedliche Technologien für die Echtzeitkommunikation, jede mit ihren eigenen Stärken. WebSocket eignet sich für den bidirektionalen Datenaustausch (Chats, Spiele, gemeinsames Bearbeiten), während SSE für unidirektionale Ströme vom Server zum Client (Benachrichtigungen, Nachrichtenfeeds, Ticker) geeignet ist.

Der Hauptunterschied besteht darin, dass WebSocket eine Upgrade-Anfrage von HTTP/1.1 auf das WebSocket-Protokoll (ws://) erfordert, die von Unternehmens-Proxys blockiert werden kann. SSE arbeitet über gewöhnliches HTTP, passiert jeden Proxy und erfordert keine spezielle Serverkonfiguration. SSE ist auch einfacher zu implementieren — der Server benötigt keine zusätzliche Bibliothek, sondern muss nur die HTTP-Antwort korrekt formatieren.

Laut Vergleichstests (2024) unterstützt SSE auf einem einzelnen Serverprozess 30–50 % mehr Verbindungen als WebSocket aufgrund des einfacheren Protokolls. Allerdings hat SSE eine höhere Latenz (50–200 ms gegenüber 10–50 ms bei WebSocket), da SSE gechunkte HTTP anstelle eines vollständigen bidirektionalen Streams mit binären Frames verwendet.

So implementieren Sie SSE auf dem Server

Die Implementierung von SSE auf dem Server erfordert keine Bibliotheken — setzen Sie einfach die richtigen HTTP-Header und senden Sie Daten im text/event-stream-Format. Sehen wir uns ein Beispiel in Node.js mit dem integrierten http-Modul an. Der Server setzt die Content-Type- und Cache-Control-Header und sendet dann alle N Sekunden Nachrichten.

Laut MDN Web Docs (2025) sind die erforderlichen Header für SSE: Content-Type: text/event-stream, Cache-Control: no-cache und Connection: keep-alive. Ohne Cache-Control könnte der Browser den SSE-Stream zwischenspeichern, was die Zustellung stoppen würde. Connection: keep-alive weist den Browser explizit an, die Verbindung offen zu halten.

Server-Code in Node.js

const http = require('http');

http.createServer((req, res) => {
    res.writeHead(200, {
        'Content-Type': 'text/event-stream',
        'Cache-Control': 'no-cache',
        'Connection': 'keep-alive'
    });

    let eventId = 0;
    const interval = setInterval(() => {
        eventId++;
        res.write(`id: ${eventId}\n`);
        res.write(`event: update\n`);
        res.write(`data: {"time": "${new Date().toISOString()}", "id":${eventId}}\n\n`);
    }, 2000);

    req.on('close', () => {
        clearInterval(interval);
    });
}).listen(3000);

SSE in Python (Flask)

from flask import Response, Flask
import time
import json

app = Flask(__name__)

@app.route('/stream')
def stream():
    def generate():
        event_id = 0
        while True:
            event_id += 1
            data = json.dumps(
                {'ticker': 'AAPL', 'price': 150.25})
            yield f'id: {event_id}\nevent: price\ndata: {data}\n\n'
            time.sleep(1)
    return Response(generate(),
        mimetype='text/event-stream')

SSE in mobilen Apps

Die Verwendung von SSE in mobilen Apps ist durch das Fehlen einer nativen EventSource-Implementierung für iOS und Android eingeschränkt. Auf mobilen Plattformen wird SSE über Drittanbieter-Bibliotheken implementiert: auf iOS — über URLSession mit NSURLProtocol, auf Android — über OkHttp mit SSE-Unterstützung (okhttp-sse). Für React Native und Flutter stehen Pakete zur Verfügung, die EventSource emulieren.

Auf iOS ist eine native SSE-Implementierung über URLSessionDataDelegate möglich. Beim Empfang von Daten in der Methode urlSession(_:dataTask:didReceive:) sammelt die App einen Puffer und parst das Event-Stream-Format manuell. Laut iOS-Entwicklungsblog (2024) ist der Batterieverbrauch bei SSE auf iOS aufgrund fehlender Heartbeat-Pakete 40 % niedriger als bei einer konstanten WebSocket-Verbindung.

Auf Android stellt OkHttp die Klasse EventSource.Factory zum Abonnieren von SSE-Streams bereit. Android-Apps können SSE für Benachrichtigungen verwenden, wenn FCM nicht verfügbar ist, oder zur Datensynchronisation im Hintergrund. SSE auf Android funktioniert gut mit WorkManager für langlebige Hintergrundaufgaben. Laut OkHttp-Dokumentation (2025) unterstützt okhttp-sse die automatische Wiederverbindung mit einem benutzerdefinierten Listener.