WebSocket: Was es ist, Vollduplex-Kommunikationsprotokoll und wie es funktioniert

Was ist WebSocket?

WebSocket ist ein Kommunikationsprotokoll, das über TCP arbeitet und einen Vollduplex-Kanal zwischen einem Client und einem Server bereitstellt. Es wurde 2011 von der IETF als RFC 6455 standardisiert und wird von allen modernen Browsern, mobilen Plattformen und Server-Frameworks unterstützt.

Im Gegensatz zu HTTP, bei dem der Client eine Anfrage initiiert und eine Antwort erhält, erlaubt WebSocket beiden Seiten, nach dem Verbindungsaufbau jederzeit Nachrichten zu senden. Dies macht es ideal für Szenarien, die eine sofortige Zustellung von Daten erfordern: Chats, Benachrichtigungen, kollaborative Dokumentenbearbeitung.

Das WebSocket-Protokoll verwendet für den anfänglichen Handshake den HTTP-Port 80 oder den HTTPS-Port 443, danach wechselt es zu einem eigenen Protokoll mit minimalem Header — nur 2 Bytes statt 800+ Bytes bei HTTP. Diese Eigenschaft bietet einen erheblichen Leistungsvorteil bei einer großen Anzahl von Nachrichten.

Wichtigste Protokolleigenschaften

Eine WebSocket-Verbindung beginnt mit einer HTTP-Upgrade-Anfrage (Upgrade), wonach das Protokoll in ein binäres Frame-Format wechselt. Die Frame-Größe reicht von 2 Bytes bis 2^63 Bytes, was die Übertragung sowohl kurzer Textnachrichten als auch großer Binärdaten ermöglicht. Das Protokoll unterstützt Nachrichtenfragmentierung, Datenmaskierung vom Client zum Server und Ping/Pong zur Aufrechterhaltung der Verbindung.

Wie funktioniert WebSocket?

Der Verbindungsaufbau von WebSocket besteht aus zwei Phasen: Handshake und Datenübertragung. Während des Handshakes sendet der Client eine HTTP-Anfrage mit dem Header Upgrade: websocket, und der Server bestätigt den Protokollwechsel mit dem Status 101 Switching Protocols. Danach geht die Verbindung in den Vollduplex-Übertragungsmodus über.

Jede Nachricht in WebSocket wird in Frames unterteilt. Ein Frame enthält einen Opcode (Text, Binärdaten, Schließen, Ping/Pong), die Nutzlastlänge und einen Maskierungsschlüssel für Daten vom Client. Frames können fragmentiert werden — Steuerframes (Ping/Pong) können zwischen Nachrichtenfragmenten übertragen werden, was ein Verbindungs-Timeout bei langen Übertragungen verhindert.

const ws = new WebSocket('wss://example.com/chat')

ws.addEventListener('open', () => {
    console.log('Verbindung hergestellt')
    ws.send('Hallo, Server!')
})

ws.addEventListener('message', (event) => {
    console.log('Empfangen:', event.data)
})

ws.addEventListener('close', () => {
    console.log('Verbindung geschlossen')
})

Im obigen Beispiel erstellt der Client ein WebSocket-Objekt mit der sicheren URL wss://. Nach dem Öffnen der Verbindung wird eine Begrüßungsnachricht gesendet, und der Message-Handler empfängt Antworten vom Server. Beim Schließen wird der Close-Handler ausgelöst — dies ist wichtig für die Wiederverbindung bei Netzwerkunterbrechungen.

WebSocket vs HTTP: Vergleich

Der Hauptunterschied zwischen WebSocket und HTTP liegt im Interaktionsmodell. HTTP arbeitet nach dem Anfrage-Antwort-Schema: Der Client initiiert eine Anfrage, der Server sendet eine Antwort, und die Verbindung wird geschlossen. WebSocket hingegen stellt einen permanenten Kanal her, über den beide Seiten jederzeit eine Übertragung initiieren können.

Für Anwendungen, die eine geringe Latenz und einen konstanten Datenstrom erfordern, ist WebSocket deutlich effizienter. HTTP Long Polling — eine Alternative, bei der der Server die Anfrage offen hält, bis Daten verfügbar sind — erzeugt eine übermäßige Serverlast und erhöht den Speicherverbrauch aufgrund mehrerer gleichzeitiger Verbindungen.

Laut High Performance Browser Networking (Grigorik, O'Reilly) reduziert WebSocket die Netzwerklatenz in Echtzeitszenarien um 40-60% im Vergleich zu HTTP Long Polling, während die Serverlast durch den Wegfall wiederholter Handshakes um das 3- bis 5-fache sinkt.

Wo wird WebSocket eingesetzt?

Dank seiner geringen Latenz und bidirektionalen Kommunikation wird WebSocket in einer Vielzahl von Anwendungen eingesetzt. Zu den wichtigsten Szenarien gehören Instant Messaging, Zustandssynchronisation in Spielen und Marktdatenübertragung in Finanzsystemen.

Chats und Messenger

WebSocket ist zum De-facto-Standard für Chat-Anwendungen geworden. Plattformen wie Slack, Telegram Web und WhatsApp Web nutzen WebSocket für die sofortige Nachrichtenübermittlung. Das Protokoll ermöglicht das Senden von Textnachrichten und Dateien über einen einzigen Kanal, während der Ping/Pong-Mechanismus die Verbindung auch bei Inaktivität aktiv hält.

Online-Spiele

Multiplayer-Browser- und Mobile-Spiele benötigen eine minimale Latenz zur Synchronisation der Spielerzustände. WebSocket überträgt Koordinaten, Aktionen und Ereignisse in Echtzeit ohne die Verzögerungen von HTTP-Anfragen. Frameworks wie Socket.IO und Colyseus abstrahieren die Low-Level-Protokolloperationen und fügen automatische Wiederverbindung und Räume hinzu.

Finanzanwendungen

Handelsplattformen und Trading-Terminals verwenden WebSocket zum Empfang von Echtzeit-Kursen. Eine Verzögerung von wenigen Millisekunden kann Millionen von Dollar kosten, daher bieten Finanz-APIs — wie Binance WebSocket Streams, Coinbase Pro — WebSocket-Schnittstellen für Marktdaten.

Mobile Anwendungen und IoT

In der mobilen Entwicklung wird WebSocket über native APIs genutzt: URLSessionWebSocketTask unter iOS und OkHttp WebSocket unter Android. Für Flutter gibt es die Bibliothek web_socket_channel, für React Native — react-native-websocket. IoT-Geräte verwenden WebSocket zur Übertragung von Telemetriedaten und zum Empfang von Steuerbefehlen, da das Protokoll weniger Energie verbraucht als ständiges HTTP-Polling.

WebSocket-Codebeispiele

Betrachten wir ein serverseitiges Beispiel mit Node.js und der ws-Bibliothek — der beliebtesten WebSocket-Implementierung für JavaScript. Der Server akzeptiert Verbindungen, verarbeitet Nachrichten und sendet sie an alle verbundenen Clients.

const WebSocket = require('ws')
const wss = new WebSocket.Server({ port: 8080 })

wss.on('connection', (ws) => {
    console.log('Neuer Client verbunden')

    ws.on('message', (data) => {
        console.log('Empfangen:', data.toString())
        ws.send('Server hat Ihre Nachricht erhalten')
    })

    ws.on('close', () => {
        console.log('Client getrennt')
    })
})

console.log('WebSocket-Server gestartet auf Port 8080')

Der Server erstellt eine Instanz von WebSocket.Server auf Port 8080 und wartet auf Verbindungen. Jeder neue Client erhält ein separates ws-Objekt, über das der Server einzelne Nachrichten senden kann. Das Broadcasting von Nachrichten an alle Clients wird durch Iteration über das Verbindungsarray implementiert. Bei einer großen Anzahl von Clients (über 1000) wird die Verwendung von Bibliotheken mit Clustering-Unterstützung wie Socket.IO empfohlen, die Redis-basierte Skalierung und automatische Wiederverbindung hinzufügen.

Nachrichten an alle Clients senden

wss.clients.forEach((client) => {
    if (client.readyState === WebSocket.OPEN) {
        client.send('Nachricht für alle Teilnehmer')
    }
})

Die Überprüfung des readyState vor dem Senden ist zwingend erforderlich: Wenn der Client bereits getrennt ist, führt der Aufruf von send zu einem Fehler. Das Flag WebSocket.OPEN stellt sicher, dass die Verbindung aktiv ist und die Nachricht zugestellt wird.

Für iOS-mobile Anwendungen wird WebSocket über URLSessionWebSocketTask implementiert, verfügbar ab iOS 13. Die Sitzung erstellt eine Aufgabe mit einer wss://-Protokoll-URL, wonach die Methoden send und receive aufgerufen werden. Der Nachrichtenempfang kann durch kontinuierliche receive-Rekursion organisiert werden, die nach der Verarbeitung der vorherigen Nachricht auf die nächste wartet und so einen konstanten Datenempfang ohne Wiederverbindung gewährleistet. Für Android wird OkHttp WebSocket verwendet, das eine ähnliche Schnittstelle mit Callbacks onOpen, onMessage, onClosing und onClosed sowie automatische Wiederverbindung bei Verbindungsabbruch bietet.

Bei der Arbeit mit WebSocket in mobilen Anwendungen ist das Lebenszyklus-Management wichtig: Wenn die App in den Hintergrund geht, kann die Verbindung vom System getrennt werden. Unter iOS muss die Verbindung bei der Rückkehr in den Vordergrund über den Delegate sceneDidBecomeActive wiederhergestellt werden. Unter Android sollten Lifecycle-aware-Komponenten oder ein Service zur Aufrechterhaltung der Verbindung verwendet werden. Zusätzlich wird empfohlen, einen exponentiellen Backoff für die Wiederverbindung zu implementieren — das Intervall zwischen den Versuchen von 1 auf 30 Sekunden zu erhöhen — um bei temporären Netzwerkproblemen keine übermäßige Serverlast zu erzeugen.