WebSocket: Annäherung an Echtzeit im Web

Für "Echtzeit" im Web kamen in der Vergangenheit Hacks zum Einsatz. Mit WebSocket haben Entwickler nun einen Standard zur bidirektionalen Kommunikation.

In Pocket speichern vorlesen Druckansicht 1 Kommentar lesen
Lesezeit: 11 Min.
Von
  • Matthias Wessendorf
Inhaltsverzeichnis

Für die Realisierung von "Echtzeit" im Web kamen in der Vergangenheit Hacks zum Einsatz. Mit WebSocket haben Entwickler nun einen Standard in der Hand, der ihnen bidirektionale Kommunikation über eine TCP-Verbindung bietet.

In traditionellen Anwendungen (Client/Server) ist es nichts Ungewöhnliches, dass bei der Veränderung des Zustands eine sofortige Aktualisierung der GUI erfolgt. Unter Verwendung des Observer Patterns lässt sich etwa eine Liste von Einträgen in "Echtzeit" aktualisieren, sobald ein Objekt beispielsweise in der Datenbank gelöscht wurde. Die Aktualisierung erfolgt automatisch, ohne dass ein Benutzer (oder die Anwendung) erfragen muss, ob es einen neuen Zustand gibt.

Mittlerweile werden vermehrt Anwendungen ins Web gebracht. Die Anwendungen sind anschaulich, allerdings fehlt eine vernünftige Integration von "Echtzeit". In Webanwendungen wird "Echtzeit" häufig durch Polling oder Long Polling simuliert. Oft werden diese Techniken (oder Hacks) durch die Begriffe Comet oder Bayeux beschrieben. Im Fall von Polling wird der Server in einem festgelegten Intervall, beispielsweise alle zwei Sekunden, gefragt, ob er neue Informationen hat. Beim Long Polling wird eine separate HTTP-Verbindung zum Server erst geschlossen, wenn neue Daten verfügbar sind. Nachdem der Browser sie verarbeitet hat, sendet er einen neuen Request zum Server, um auf weitere Updates zu warten. HTTP ist von Natur aus "nur" halbduplex. Das bedeutet, dass für die bidirektionale Kommunikation zwischen Browser und Server ein separater HTTP Request für jede Richtung benötigt wird.

Abb. 2: Long Polling

Abb. 1: Polling

Das erzeugt natürlich einen Menge Overhead. Neben dem zusätzlichen I/O-Handling auf dem Server kommt noch der Netzverkehr hinzu: HTTP Request/Response Header können schnell ein paar Hundert Bytes veranschlagen. Hinzu kommt ab und an die eigentlich wertlose Information, dass es keine Änderungen am Zustand des Servers gab.

Diese Tatsachen erschweren die effiziente Programmierung von Webanwendungen, die auf einen schnellen Datentransfer angewiesen sind. Beispiele dafür gibt es genug, etwa:

  • kollaborative Websites
  • Internet-Support
  • Spiele (auf Basis von HTML5)
  • Finanzanwendungen
  • Server-Monitoring-Anwendungen im Web