WebSocket

Entstehung und Beteiligte

WebSocket wurde im Umfeld der WHATWG- und HTML5-Arbeit von Ian Hickson entworfen. Die IETF standardisierte das Protokoll 2011 in RFC 6455. Es nutzt einen HTTP-Handshake und wechselt danach zu einer bidirektionalen Verbindung.

Welches Problem sollte gelöst werden?

Browser konnten Serverdaten nur durch wiederholte HTTP-Anfragen, Long Polling oder proprietäre Plugins empfangen. Chats, Börsenkurse und Spiele benötigten eine dauerhafte Verbindung in beide Richtungen.

Technische Hürden und Lösungen

Das Protokoll musste bestehende Proxys und Firewalls durchqueren, ohne HTTP zu imitieren. Maskierung schützt bestimmte Zwischenserver vor Cache-Angriffen. Backpressure, Verbindungsabbrüche und horizontale Skalierung bleiben Anwendungsaufgaben.

Standardisierung und Einordnung

Internetprotokolle werden überwiegend in offenen RFC-Dokumenten beschrieben. Ein RFC kann ein historischer Vorschlag, ein aktueller Standard oder inzwischen überholt sein. Implementierungen müssen nicht nur das Papier befolgen, sondern mit fehlerhaften Gegenstellen, Paketverlust, Zeitüberschreitungen, Sicherheitsangriffen und jahrzehntealten Erweiterungen umgehen. Interoperabilität entsteht dadurch, dass unabhängige Hersteller dieselben Zustandsautomaten, Nachrichtenformate und Fehlerfälle testen.

Technik im praktischen Betrieb

Für den produktiven Einsatz zählt die konkrete Protokollversion. Alte und neue Varianten können denselben Port verwenden, besitzen aber völlig unterschiedliche Sicherheits- und Funktionsmerkmale. Administratoren sollten daher Aushandlung, Zertifikate, Timeouts, maximale Nachrichtengrößen und Fehlercodes sichtbar machen. Proxys, NAT und Firewalls verändern häufig den Datenpfad. Gute Tests erfolgen aus derselben Netzposition wie die betroffene Anwendung und prüfen nicht nur einen offenen Port, sondern einen vollständigen gültigen Vorgang.

Warum das Thema heute noch relevant ist

Die ursprüngliche Entstehungszeit erklärt viele heutige Sicherheitslücken: Frühe Internetgemeinschaften waren klein und Vertrauen wurde vorausgesetzt. Authentifizierung, Verschlüsselung und Missbrauchsschutz kamen oft erst später als Erweiterung hinzu. Moderne Implementierungen müssen deshalb sichere Voreinstellungen verwenden, alte Varianten abschalten und dennoch mit Gegenstellen kommunizieren, die einen älteren Stand besitzen. Versionsnummer, Aushandlung und tatsächlich aktive Option sind aussagekräftiger als der bloße Protokollname.

Daten und Meilensteine

• 2011: RFC 6455 standardisiert WebSocket.
• ws und wss entsprechen ungeschütztem und TLS-geschütztem Transport.
• Nach dem Upgrade gelten eigene Frames statt HTTP-Anfragen.
• WebSocket definiert Transport, nicht das Format der Anwendungsnachrichten.

Was ist WebSocket?

WebSocket (RFC 6455, 2011) ist ein Netzwerkprotokoll, das eine dauerhafte, bidirektionale Kommunikationsverbindung über eine einzige TCP-Verbindung ermöglicht. Es überwindet die fundamentale Einschränkung von HTTP: Dort kann immer nur der Client eine Anfrage stellen, der Server antwortet.

Mit WebSocket kann der Server jederzeit Daten an den Client senden, ohne dass dieser zuvor gefragt hat. Diese "Push"-Fähigkeit revolutionierte Echtzeit-Webanwendungen.

Der WebSocket-Handshake

WebSocket beginnt als normale HTTP-Anfrage und wird dann "upgraded". Der Browser sendet GET mit speziellen Headern (Upgrade: websocket, Sec-WebSocket-Key). Der Server antwortet mit HTTP 101 Switching Protocols und dem gehashten Key als Bestätigung.

Ab diesem Punkt ist die TCP-Verbindung nicht mehr HTTP – es werden WebSocket-Frames direkt ausgetauscht. Der Overhead pro Nachricht: nur 2–14 Byte (Frame-Header) statt ~200–800 Byte HTTP-Header.

Protokoll-Details

WebSocket-Kommunikation läuft über Frames (nicht Pakete). Frame-Typen:

• Text-Frames: UTF-8 Text (z.B. JSON-Daten)
• Binary-Frames: Binärdaten (z.B. Bilder, Audiodaten)
• Ping/Pong-Frames: Keep-alive, Latenzmessung
• Close-Frame: Geordnetes Schließen der Verbindung
• ws:// läuft unverschlüsselt über TCP (wie HTTP)
• wss:// läuft verschlüsselt über TLS (wie HTTPS) – Pflicht für Produktivsysteme

Anwendungsfälle und Alternativen

Typische WebSocket-Einsatzgebiete: Echtzeit-Chat (WhatsApp Web), Live-Sportliveticker, Multiplayer-Browser-Spiele, Kollaborations-Tools (Google Docs-ähnlich), Trading-Plattformen mit Live-Kursen, IoT-Dashboards.

Alternativen: Server-Sent Events (SSE) für reine Server→Client-Streams (unidirektional, einfacher). HTTP/2 Push (veraltet, kaum noch genutzt). Long-Polling als Fallback für ältere Browser. Libraries wie Socket.io abstrahieren WebSocket und fallen automatisch auf Polling zurück.