WebSocket
WebSocket hält eine Leitung zwischen Browser und Server dauerhaft offen, damit beide jederzeit senden können.
Ein Browser und ein Server. Zwischen ihnen läuft normalerweise HTTP: der Browser fragt, der Server antwortet.
In 30 Sekunden
WebSocket ist eine Standard-Web-Technologie für eine dauerhafte, beidseitige Verbindung zwischen einem Browser (oder einer App) und einem Server. Normales HTTP (das Grundprotokoll des Webs) funktioniert nur nach dem Muster Anfrage und dann Antwort, der Server kann von sich aus nichts schicken. WebSocket löst genau das, indem die Verbindung offen bleibt und beide Seiten jederzeit Daten senden dürfen. So kann der Server Live-Daten sofort an den Browser schicken, ohne dass dieser ständig nachfragen muss. Gestartet wird über eine ganz normale HTTP-Anfrage, die dann per Handshake (ein kurzes Aushandeln zwischen Browser und Server) auf WebSocket umgeschaltet wird. Typisch ist das für Chats, Live-Dashboards, Ticker und Benachrichtigungen. Genormt ist WebSocket als RFC 6455 der Internet-Normungsorganisation IETF aus dem Jahr 2011.
Stell dir HTTP wie einen Briefverkehr vor. Du schickst einen Brief mit einer Frage, wartest, und irgendwann kommt eine Antwort zurück. Willst du wissen, ob es etwas Neues gibt, musst du immer wieder von dir aus einen Brief schreiben und nachfragen. Das ist umständlich und langsam. WebSocket ist stattdessen wie ein Telefongespräch, bei dem beide den Hörer nicht auflegen. Das Besondere: Man ruft nicht neu an, sondern das laufende Brief-Gespräch wird mitten drin in ein Telefonat umgewandelt, also dieselbe Verbindung, nur ab jetzt in beide Richtungen offen. Die Leitung bleibt bestehen, und sobald einer etwas zu sagen hat, spricht er einfach, egal welche Seite gerade dran ist. Der Server muss nicht warten, bis der Browser fragt, sondern kann von sich aus sofort Bescheid geben, wenn zum Beispiel eine neue Nachricht eintrifft oder ein Kurs sich ändert.
Wo trifft man WebSocket an?
Chat und Messaging
Neue Nachrichten erscheinen sofort bei allen Teilnehmern, ohne dass die App nachfragen muss. Team-Chats wie Slack oder Support-Chats auf Webseiten nutzen dieses Prinzip.
Live-Dashboards
Kennzahlen, Serverzustände oder Verkaufszahlen aktualisieren sich in Echtzeit im Browser. Ein Betriebs-Dashboard zeigt so laufende Bestellungen an, sobald sie eintreffen.
Börsen- und Sportticker
Kurse, Spielstände oder Wettquoten werden in dem Moment aktualisiert, in dem sie sich ändern. Eine Trading-Oberfläche zeigt Preisbewegungen ohne merkliche Verzögerung.
Multiplayer-Spiele
Bewegungen und Aktionen aller Spieler müssen sofort bei allen anderen ankommen. Browser-basierte Echtzeitspiele halten so alle Teilnehmer auf demselben Stand.
Benachrichtigungen und Mitteilungen
Der Server stösst Hinweise aktiv an, etwa wenn eine Aufgabe fertig ist oder jemand dich erwähnt. Die kleine rote Zahl in der Menüleiste erscheint so ohne Neuladen der Seite.
IoT-Telemetrie im Browser
Sensorwerte von Maschinen oder Gebäuden laufen live in eine Weboberfläche. Ein Temperatur- oder Füllstand-Wert aktualisiert sich fortlaufend, ohne dass die Seite ständig neu lädt.
Gut geeignet für
- Für Live-Daten, die der Server von sich aus schicken soll, weil WebSocket genau dafür gebaut ist und der Browser nicht ständig nachfragen muss.
- Für beidseitigen Austausch in Echtzeit, weil beide Seiten über dieselbe offene Leitung jederzeit senden können, auch gleichzeitig (der Fachbegriff dafür ist Vollduplex).
- Für viele kleine, häufige Nachrichten, weil die Daten als schlanke Frames (kleine Datenpakete mit sehr wenig Verpackung drumherum) fliessen und so fast kein unnötiger Ballast mitgeschickt wird.
- Für Anwendungen, die durch Firmen-Schutzsysteme müssen, weil WebSocket über die normalen Web-Zugänge läuft (Ports 80 und 443, dieselben, die auch jede Webseite nutzt) und dort meist ohne Sonderfreigabe durch Firewalls durchkommt.
- Für Web- und App-Oberflächen direkt, weil WebSocket fest in jeden modernen Browser eingebaut ist und keine zusätzliche Software beim Nutzer braucht.
Weniger geeignet für
- Für einfache, seltene Abfragen ist WebSocket überdimensioniert, weil das Offenhalten der Leitung unnötig Ressourcen bindet. Hier reicht ein klassischer HTTP- beziehungsweise REST-Aufruf (Anfrage und Antwort über HTTP).
- Für reines Datenabholen ohne Server-Push lohnt sich der Aufwand nicht, weil du die Live-Fähigkeit gar nicht nutzt. Besser ist ein normaler HTTP-Aufruf, bei Bedarf ergänzt um Server-Sent Events (eine einfachere Einweg-Technik, bei der nur der Server sendet).
- Für die Vernetzung von Maschinen in der Fertigung ist WebSocket nicht gedacht, weil es das taktgenaue, garantierte Timing nicht bietet, das Maschinen brauchen (dass ein Signal zum Beispiel verlässlich innerhalb weniger Millisekunden ankommt). Dafür gibt es spezielle Industrie-Protokolle wie PROFINET.
- Für Netze aus sehr vielen Geräten, die nach dem Muster Publish/Subscribe arbeiten, ist WebSocket allein umständlich. Publish/Subscribe funktioniert wie ein Zeitungs-Abo: Ein Sender veröffentlicht zu einem Thema, viele Empfänger, die dieses Thema abonniert haben, bekommen es automatisch. Dafür passt oft MQTT besser (ein schlankes Protokoll für genau diesen Fall), das seinerseits teils über WebSocket transportiert wird.
Fakten
- RFC 6455 der IETF (Internet-Normungsorganisation)
- 2011
- WHATWG Living Standard (Gremium für Web-Standards, löste die frühere W3C-Spezifikation ab)
- Vollduplex (gleichzeitig in beide Richtungen) über eine einzige TCP-Verbindung (Netzwerkverbindung zwischen zwei Rechnern)
- ws:// (unverschlüsselt), wss:// (per TLS/Verschlüsselung abgesichert)
- 80 (ws) und 443 (wss), also die üblichen Web-Ports
- HTTP-Handshake mit Upgrade-Header, Antwort 101 Switching Protocols
- Frames mit sehr geringem Overhead, Text oder Binärdaten
Im Detail
Das Problem: HTTP kann nur antworten, nicht anrufen
Das Web basiert von Anfang an auf HTTP (Hypertext Transfer Protocol), dem Grundprotokoll, mit dem Browser Seiten und Daten abrufen. HTTP funktioniert nach einem klaren Muster: Der Browser stellt eine Anfrage, der Server antwortet, und danach ist die Sache erledigt. Der Server kann von sich aus nichts nachschicken, denn er hat keine offene Leitung zum Browser, über die er einfach lossenden könnte.
Für Live-Daten ist das ein echtes Problem. Wenn eine neue Chat-Nachricht ankommt oder ein Kurs sich ändert, weiss der Browser davon nichts, solange er nicht selbst nachfragt. Der übliche Notbehelf heisst Polling: Der Browser fragt in kurzen Abständen immer wieder nach, ob es etwas Neues gibt. Das ist langsam, weil zwischen zwei Anfragen immer eine Lücke liegt, und es verschwendet Ressourcen, weil die meisten Anfragen mit der Antwort nichts Neues zurückkommen.
Genau hier setzt WebSocket an. Statt immer wieder neu zu fragen, wird einmal eine dauerhafte Verbindung aufgebaut, die offen bleibt. Über diese Leitung kann der Server sofort senden, sobald etwas passiert, und der Browser sofort reagieren.
Der Handshake: aus HTTP wird WebSocket
Eine WebSocket-Verbindung fängt bewusst ganz normal an, nämlich als HTTP-Anfrage. Das ist wichtig, weil sie so über dieselben Wege läuft wie jede andere Webseite und durch Firewalls und Proxies (Zwischenstationen im Netz, die den Verkehr weiterleiten) kommt. In dieser ersten Anfrage steht ein besonderer Hinweis, der Header Upgrade: websocket. Damit bittet der Browser darum, die Verbindung auf WebSocket umzuschalten.
Ist der Server einverstanden, antwortet er mit dem Statuscode 101 Switching Protocols. Das ist das Signal: Wir wechseln jetzt das Protokoll. Ab diesem Moment ist aus der HTTP-Anfrage eine dauerhafte WebSocket-Verbindung geworden, und zwar über dieselbe, eine einzige TCP-Verbindung (die zugrundeliegende Netzwerkverbindung zwischen zwei Rechnern). Es wird also keine zweite Leitung aufgemacht, sondern die bestehende weitergenutzt.
Nach diesem Handshake gelten neue Spielregeln. Die Leitung bleibt offen, und beide Seiten dürfen jederzeit senden. Wie eine Webadresse mit http:// oder https:// beginnt, hat auch WebSocket eigene Adress-Vorsilben: ws:// für unverschlüsselte und wss:// für verschlüsselte Verbindungen. Das doppelte s steht wie bei https für die abgesicherte, per TLS (Transport Layer Security, die Standard-Verschlüsselung im Web) geschützte Variante. In der Praxis solltest du fast immer wss:// verwenden.
Vollduplex und Frames: die offene Leitung im Betrieb
Der entscheidende Gewinn ist der Vollduplex-Betrieb. Vollduplex heisst, dass beide Seiten gleichzeitig und unabhängig voneinander senden können, so wie bei einem Telefongespräch. Der Server wartet nicht mehr auf eine Frage, sondern pusht Daten von sich aus, sobald es etwas gibt, etwa eine neue Chat-Nachricht oder einen aktuellen Sensorwert. Das macht Anwendungen spürbar schneller und lebendiger.
Damit das effizient bleibt, fliessen die Daten als Frames. Ein Frame ist ein kleines Datenpaket mit sehr wenig Zusatzinformationen drumherum. Das ist ein grosser Unterschied zu klassischem HTTP, bei dem jede einzelne Anfrage einen kompletten Satz an Kopfzeilen (Header) mitschleppt. Bei vielen kleinen Nachrichten pro Sekunde spart WebSocket dadurch deutlich Datenmenge und Rechenaufwand.
Weil die Verbindung dauerhaft offen ist, tragen beide Seiten etwas Verantwortung. Damit man merkt, ob die Gegenseite noch da ist, sendet eine Seite (meist der Server) in Abständen einen sogenannten Ping. Die Gegenseite antwortet automatisch mit einem Pong. Bleibt der Pong aus, gilt die Verbindung als tot und wird sauber neu aufgebaut. Das ist der Preis für die dauerhafte Leitung, aber gut beherrschbar und in fertigen Software-Bausteinen (Bibliotheken, die Entwickler nur einbinden müssen) meist schon gelöst.
Wann WebSocket passt und wann nicht
WebSocket ist die richtige Wahl, wenn Daten in Echtzeit und in beide Richtungen fliessen sollen und wenn der Server von sich aus etwas mitteilen muss. Chats, Live-Dashboards, Ticker, Multiplayer-Spiele und Benachrichtigungen sind Musterbeispiele. Auch IoT-Telemetrie, also laufende Messwerte von Geräten, lässt sich damit gut direkt in eine Weboberfläche bringen.
Nicht jede Aufgabe braucht diese Dauerleitung. Für seltene, einfache Abfragen ist ein normaler HTTP- beziehungsweise REST-Aufruf einfacher und sparsamer. Muss nur der Server senden und der Browser nie zurück, sind Server-Sent Events oft die leichtere Lösung. Beides zu wählen, wo es passt, hält die Anwendung schlank.
Auch technisch hat WebSocket klare Grenzen. Für die Maschinenvernetzung in der Fertigung mit hartem, garantiertem Timing sind industrielle Protokolle wie PROFINET gedacht, nicht WebSocket. Und für Netze aus sehr vielen Geräten nach dem Muster Publish/Subscribe ist häufig MQTT die passendere Wahl, das seinerseits interessanterweise oft selbst über WebSocket transportiert wird, damit es auch im Browser und durch Firewalls funktioniert.