Zum Hauptinhalt springen

1. Introduction (Einführung)

Das WebSocket-Protokoll (WebSocket Protocol) ermöglicht Vollduplex-Kommunikation (Full-Duplex Communication) zwischen einem Client und einem Server über eine einzelne TCP-Verbindung. Das Protokoll besteht aus einem Eröffnungs-Handshake (Opening Handshake), gefolgt von grundlegendem Nachrichten-Framing (Message Framing), das über TCP geschichtet ist.

Das Ziel dieser Spezifikation ist es, einen Mechanismus für browserbasierte Anwendungen bereitzustellen, die bidirektionale Kommunikation mit Servern benötigen, ohne auf das Öffnen mehrerer HTTP-Verbindungen angewiesen zu sein (z. B. unter Verwendung von XMLHttpRequest oder <iframe>s und Long Polling).

1.1 Background (Hintergrund)​

Historisch gesehen erforderte die Erstellung von Webanwendungen, die bidirektionale Kommunikation zwischen einem Client und einem Server benötigen (z. B. Instant-Messaging- und Gaming-Anwendungen), einen Missbrauch von HTTP, um den Server nach Updates abzufragen und gleichzeitig Upstream-Benachrichtigungen als separate HTTP-Aufrufe zu senden.

Dies führt zu verschiedenen Problemen:

  • Der Server ist gezwungen, eine Reihe verschiedener zugrunde liegender TCP-Verbindungen für jeden Client zu verwenden: eine zum Senden von Informationen an den Client und eine neue für jede eingehende Nachricht
  • Das Drahtprotokoll (Wire Protocol) hat einen hohen Overhead, da jede Client-zu-Server-Nachricht einen HTTP-Header hat
  • Das clientseitige Skript ist gezwungen, eine Zuordnung von den ausgehenden Verbindungen zur eingehenden Verbindung zu pflegen, um Antworten zu verfolgen

Eine einfachere Lösung wäre die Verwendung einer einzelnen TCP-Verbindung für den Verkehr in beide Richtungen. Dies ist es, was das WebSocket-Protokoll bietet. In Kombination mit der WebSocket-API bietet es eine Alternative zum HTTP-Polling für bidirektionale Kommunikation von einer Webseite zu einem entfernten Server.

1.2 Protocol Overview (Protokollübersicht)​

Das Protokoll besteht aus zwei Teilen: einem Handshake und der Datenübertragung (Data Transfer).

Der Handshake vom Client sieht wie folgt aus:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

Der Handshake vom Server sieht wie folgt aus:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

Wichtige Punkte des Handshakes:

  • Die Client-Anfrage ist eine gültige HTTP-Upgrade-Anfrage (HTTP Upgrade Request)
  • Mehrere WebSocket-spezifische Header werden hinzugefügt
  • Der Server antwortet mit Statuscode 101

Sobald die Verbindung hergestellt ist, können Client und Server jederzeit Daten in beide Richtungen senden und empfangen.

1.3 Design Philosophy (Designphilosophie)​

Das WebSocket-Protokoll wurde auf Grundlage der folgenden Prinzipien entwickelt:

  1. Frame-basiertes statt stream-basiertes Protokoll: Ein frame-basiertes Protokoll (Frame-based Protocol) ermöglicht es, Metadaten jedem Frame zuzuordnen und dem Protokoll, Nachrichtengrenzen (Message Boundaries) bis zur Anwendungsschicht zu erhalten
  2. Origin-Modell: Verwendet das Browser-Origin-Modell (Origin Model), um Sicherheit zu gewährleisten
  3. Einzelne TCP-Verbindung: Um über HTTP-Ports 80 und 443 zu funktionieren
  4. Unabhängig von HTTP: Obwohl der Handshake von HTTP-Servern als Upgrade-Anfrage interpretiert wird, ist das Protokoll selbst unabhängig
  5. Erweiterbarkeit: Unterstützt zukünftige Erweiterungen durch Erweiterungs- und Unterprotokoll-Mechanismen

1.4 Security Model (Sicherheitsmodell)​

Das WebSocket-Protokoll verwendet das Origin-Modell (Origin Model), das üblicherweise von Webbrowsern verwendet wird. Das Protokoll enthält ein Origin-Header-Feld (Origin Header Field), das der Server verwenden kann, um zu entscheiden, ob er eine WebSocket-Verbindung von einem bestimmten Origin akzeptiert.

Zusätzlich:

  • TLS-verschlüsselte Verbindungen (wss://) werden empfohlen
  • Frames vom Client zum Server müssen maskiert werden (Masking)
  • Das Protokoll enthält Frame-Typen, Opcodes (Opcode) usw., um Cache-Poisoning zu verhindern
Letztes Update am