Diese Seite wurde von der Cloud Translation API übersetzt.

Updates mit vom Server gesendeten Ereignissen streamen

Eric Bidelman

Vom Server gesendete Ereignisse senden automatische Updates von einem Server über eine HTTP-Verbindung an einen Client. Sobald die Verbindung hergestellt ist, können die Server die Datenübertragung initiieren.

Sie können SEs verwenden, um Push-Benachrichtigungen von Ihrer Webanwendung zu senden. SSEs senden Informationen in eine Richtung, sodass Sie keine Aktualisierungen vom Client erhalten.

Das Konzept der SSEs ist Ihnen vielleicht schon bekannt. Eine Webanwendung „meldet sich für“ einen Stream von Updates an, der von einem Server generiert wird. Jedes Mal, wenn ein neues Ereignis auftritt, wird eine Benachrichtigung an den Client gesendet. Um serverseitige Ereignisse wirklich zu verstehen, müssen wir jedoch die Einschränkungen ihrer AJAX-Vorgänger kennen. Dazu zählen:

Polling: Die Anwendung fragt wiederholt einen Server nach Daten ab. Diese Technik wird von der Mehrheit der AJAX-Anwendungen verwendet. Beim HTTP-Protokoll dreht sich das Abrufen von Daten um ein Anfrage- und Antwortformat. Der Client stellt eine Anfrage und wartet, bis der Server mit Daten antwortet. Ist keine verfügbar, wird eine leere Antwort zurückgegeben. Zusätzliche Abfragen führen zu einem höheren HTTP-Overhead.
Long Polling (hängender GET-/COMET-Vorgang): Wenn auf dem Server keine Daten verfügbar sind, hält der Server die Anfrage offen, bis neue Daten verfügbar sind. Daher wird dieses Verfahren oft als „hängender GET“ bezeichnet. Sobald Informationen verfügbar sind, antwortet der Server, schließt die Verbindung und der Vorgang wird wiederholt. Der Server antwortet also ständig mit neuen Daten. Dazu verwenden Entwickler in der Regel Hacks, z. B. das Anhängen von Skript-Tags an einen "unendlichen" iFrame.

Servergesendete Ereignisse wurden von Grund auf für Effizienz entwickelt. Bei der Kommunikation mit SSEs kann ein Server jederzeit Daten an Ihre App pushen, ohne dass eine anfängliche Anfrage erforderlich ist. Mit anderen Worten: Updates können direkt vom Server an den Client gestreamt werden. SSEs öffnen einen einzelnen unidirektionalen Kanal zwischen Server und Client.

Der Hauptunterschied zwischen servergesendeten Ereignissen und Long-Polling besteht darin, dass SSEs direkt vom Browser verarbeitet werden und der Nutzer nur auf Nachrichten warten muss.

Servergesendete Ereignisse im Vergleich zu WebSockets

Warum sollten Sie servergesendete Ereignisse gegenüber WebSockets wählen? Gute Frage.

WebSockets hat ein umfangreiches Protokoll mit bidirektionaler Vollduplex-Kommunikation. Ein Zwei-Wege-Kanal eignet sich besser für Spiele, Messaging-Apps und alle Anwendungsfälle, bei denen Sie in beiden Richtungen nahezu in Echtzeit aktuelle Informationen benötigen.

Manchmal ist jedoch nur eine einseitige Kommunikation von einem Server erforderlich. Das kann beispielsweise der Fall sein, wenn ein Freund seinen Status aktualisiert, wenn Aktienkurse angezeigt werden oder wenn Nachrichtenfeeds oder andere automatisierte Push-Mechanismen für Daten verwendet werden. Mit anderen Worten, eine Aktualisierung einer clientseitigen Web SQL-Datenbank oder eines IndexedDB-Objektspeichers. Wenn Sie Daten an einen Server senden müssen, ist XMLHttpRequest immer eine gute Wahl.

SSEs werden über HTTP gesendet. Es gibt kein spezielles Protokoll oder keine spezielle Serverimplementierung. WebSockets erfordern Vollduplex-Verbindungen und neue WebSocket-Server, um das Protokoll zu verarbeiten.

Außerdem bieten serverseitig gesendete Ereignisse eine Vielzahl von Funktionen, die WebSockets von Natur aus nicht haben, darunter automatische Neuverbindungen, Ereignis-IDs und die Möglichkeit, beliebige Ereignisse zu senden.

EventSource mit JavaScript erstellen

Wenn Sie einen Ereignisstream abonnieren möchten, erstellen Sie ein EventSource-Objekt und übergeben Sie ihm die URL Ihres Streams:

const source = new EventSource('stream.php');

Richten Sie als Nächstes einen Handler für das Ereignis message ein. Optional kannst du auch nach open und error lauschen:

source.addEventListener('message', (e) => {
  console.log(e.data);
});

source.addEventListener('open', (e) => {
  // Connection was opened.
});

source.addEventListener('error', (e) => {
  if (e.readyState == EventSource.CLOSED) {
    // Connection was closed.
  }
});

Wenn Updates vom Server gepusht werden, wird der onmessage-Handler ausgelöst und neue Daten sind in der zugehörigen e.data-Property verfügbar. Das Tolle daran ist, dass der Browser nach etwa drei Sekunden automatisch wieder eine Verbindung zur Quelle herstellt, wenn die Verbindung geschlossen wird. Ihre Serverimplementierung kann sogar das Zeitlimit für die Wiederverbindung steuern.

Das war's. Ihr Kunde kann jetzt Ereignisse von stream.php verarbeiten.

Format des Ereignisstreams

Zum Senden eines Ereignisstreams von der Quelle muss eine Antwort in Form von Nur-Text erstellt werden, die mit einem text/event-stream-Content-Typ bereitgestellt wird, der dem SSE-Format entspricht. In der grundlegenden Form sollte die Antwort eine data:-Zeile enthalten, gefolgt von Ihrer Nachricht, gefolgt von zwei „\n“-Zeichen, um den Stream zu beenden:

data: My message\n\n

Mehrzeilige Daten

Wenn Ihre Nachricht länger ist, können Sie sie mithilfe mehrerer data:-Zeilen aufteilen. Zwei oder mehr aufeinanderfolgende Zeilen, die mit data: beginnen, werden als ein einzelnes Datenelement behandelt. Das bedeutet, dass nur ein message-Ereignis ausgelöst wird.

Jede Zeile sollte mit einem einzelnen „\n“ enden, mit Ausnahme der letzten, die mit zwei enden sollte. Das Ergebnis, das an den message-Handler übergeben wird, ist ein einzelner String, der mit Zeilenumbruchzeichen verkettet ist. Beispiel:

data: first line\n
data: second line\n\n</pre>

Dadurch wird in e.data „erste Zeile\nzweite Zeile“ ausgegeben. Mit e.data.split('\n').join('') kann die Nachricht dann ohne die Zeichen „\n“ rekonstruiert werden.

JSON-Daten senden

Wenn Sie mehrere Zeilen verwenden, können Sie JSON senden, ohne die Syntax zu brechen:

data: {\n
data: "msg": "hello world",\n
data: "id": 12345\n
data: }\n\n

Und hier ein möglicher clientseitiger Code für die Verarbeitung dieses Streams:

source.addEventListener('message', (e) => {
  const data = JSON.parse(e.data);
  console.log(data.id, data.msg);
});

ID mit einem Ereignis verknüpfen

Sie können eine eindeutige ID mit einem Streamereignis senden, indem Sie eine Zeile mit id: beginnen:

id: 12345\n
data: GOOG\n
data: 556\n\n

Wenn Sie eine ID festlegen, kann der Browser das letzte ausgelöste Ereignis im Blick behalten. Wenn die Verbindung zum Server getrennt wird, wird mit der neuen Anfrage ein spezieller HTTP-Header (Last-Event-ID) festgelegt. So kann der Browser ermitteln, welches Ereignis ausgelöst werden soll. Das Ereignis message enthält die Eigenschaft e.lastEventId.

Zeitüberschreitung bei erneuten Verbindung festlegen

Ungefähr drei Sekunden nach dem Beenden jeder Verbindung versucht der Browser, die Verbindung zur Quelle wiederherzustellen. Sie können dieses Zeitlimit ändern, indem Sie eine Zeile mit retry: beginnen, gefolgt von der Anzahl der Millisekunden, die gewartet werden sollen, bevor versucht wird, eine neue Verbindung herzustellen.

Im folgenden Beispiel wird nach 10 Sekunden versucht, eine Verbindung herzustellen:

retry: 10000\n
data: hello world\n\n

Ereignisnamen angeben

Eine einzelne Ereignisquelle kann durch Einfügen eines Ereignisnamens verschiedene Ereignistypen generieren. Wenn eine Zeile mit event: beginnt und von einem eindeutigen Namen für das Ereignis gefolgt wird, wird dem Ereignis dieser Name zugeordnet. Auf dem Client kann ein Ereignis-Listener für dieses Ereignis eingerichtet werden.

In der folgenden Serverausgabe werden beispielsweise drei Ereignistypen gesendet: ein generisches „message“-Ereignis, „userlogon“ und „update“:

data: {"msg": "First message"}\n\n
event: userlogon\n
data: {"username": "John123"}\n\n
event: update\n
data: {"username": "John123", "emotion": "happy"}\n\n

Wenn Ereignis-Listener auf dem Client eingerichtet sind:

source.addEventListener('message', (e) => {
  const data = JSON.parse(e.data);
  console.log(data.msg);
});

source.addEventListener('userlogon', (e) => {
  const data = JSON.parse(e.data);
  console.log(`User login: ${data.username}`);
});

source.addEventListener('update', (e) => {
  const data = JSON.parse(e.data);
  console.log(`${data.username} is now ${data.emotion}`);
};

Serverbeispiele

Hier ist eine einfache Serverimplementierung in PHP:

<?php
header('Content-Type: text/event-stream');
header('Cache-Control: no-cache'); // recommended to prevent caching of event data.

/**
* Constructs the SSE data format and flushes that data to the client.
*
* @param string $id Timestamp/id of this connection.
* @param string $msg Line of text that should be transmitted.
**/

function sendMsg($id, $msg) {
  echo "id: $id" . PHP_EOL;
  echo "data: $msg" . PHP_EOL;
  echo PHP_EOL;
  ob_flush();
  flush();
}

$serverTime = time();

sendMsg($serverTime, 'server time: ' . date("h:i:s", time()));
?>

Hier ist eine ähnliche Implementierung in Node.js mit einem Express-Handler:

app.get('/events', (req, res) => {
    // Send the SSE header.
    res.writeHead(200, {
        'Content-Type': 'text/event-stream',
        'Cache-Control': 'no-cache',
        'Connection': 'keep-alive'
    });

    // Sends an event to the client where the data is the current date,
    // then schedules the event to happen again after 5 seconds.
    const sendEvent = () => {
        const data = (new Date()).toLocaleTimeString();
        res.write("data: " + data + '\n\n');
        setTimeout(sendEvent, 5000);
    };

    // Send the initial event immediately.
    sendEvent();
});

sse-node.html

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
  </head>
  <body>
    <script>
    const source = new EventSource('/events');
    source.onmessage = (e) => {
        const content = document.createElement('div');
        content.textContent = e.data;
        document.body.append(content);
    };
    </script>
  </body>
</html>

Ereignisstream abbrechen

Normalerweise stellt der Browser automatisch eine Verbindung zur Ereignisquelle her, wenn die Verbindung geschlossen wird. Dieses Verhalten kann jedoch entweder vom Client oder vom Server aufgehoben werden.

Wenn du einen Stream vom Client aus abbrechen möchtest, ruf Folgendes auf:

source.close();

Wenn Sie einen Stream vom Server abbrechen möchten, antworten Sie mit einem Nicht-text/event-stream-Content-Type oder geben einen anderen HTTP-Status als 200 OK zurück (z. B. 404 Not Found).

Beide Methoden verhindern, dass der Browser die Verbindung wiederherstellt.

Sicherheit

Anfragen, die von EventSource generiert werden, unterliegen den Same-Origin-Richtlinien wie andere Netzwerk-APIs wie fetch. Wenn der SSE-Endpunkt auf deinem Server von verschiedenen Ursprüngen aus zugänglich sein soll, lies den Hilfeartikel zum Aktivieren mit Cross-Origin Resource Sharing (CORS).