Zum Hauptinhalt springen

4. Opening Handshake (Eröffnungs-Handshake)

Der Eröffnungs-Handshake (Opening Handshake) des WebSocket-Protokolls ist so konzipiert, dass er mit der bestehenden HTTP-Infrastruktur kompatibel ist. Der Handshake ist eine HTTP-Upgrade-Anfrage.

4.1 Client Requirements (Client-Anforderungen)​

Die vom Client gesendete Handshake-Anfrage muss eine gültige HTTP-Anfrage im folgenden Format sein:

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

Erforderliche Header-Felder​

Host

  • Enthält den Host und die Portnummer des Servers
  • Entspricht der HTTP/1.1-Spezifikation

Upgrade: websocket

  • muss (MUST) diesen Header enthalten
  • Der Wert ist "websocket" (Groß-/Kleinschreibung wird nicht beachtet)

Connection: Upgrade

  • muss (MUST) diesen Header enthalten
  • Zeigt an, dass dies eine Upgrade-Anfrage ist

Sec-WebSocket-Key

  • muss (MUST) diesen Header enthalten
  • Zufällig generierter 16-Byte-Wert, Base64-kodiert
  • Wird verwendet, um zu überprüfen, ob der Server das WebSocket-Protokoll versteht

Sec-WebSocket-Version: 13

  • muss (MUST) diesen Header enthalten
  • Die aktuelle Versionsnummer ist 13

Optionale Header-Felder​

Origin

  • Browser-Clients müssen (MUST) ihn einschließen
  • Nicht-Browser-Clients können (MAY) ihn einschließen
  • Wird für serverseitige Sicherheitsvalidierung verwendet

Sec-WebSocket-Protocol

  • optional (OPTIONAL)
  • Gibt die Liste der vom Client unterstützten Unterprotokolle an
  • Mehrere Werte werden durch Kommas getrennt

Sec-WebSocket-Extensions

  • optional (OPTIONAL)
  • Gibt die vom Client unterstützten Erweiterungen an
  • Format: extension-name [; parameter=value]*

4.2 Server-Side Requirements (Serverseitige Anforderungen)​

Der Server muss den Client-Handshake validieren und eine angemessene Antwort zurückgeben.

4.2.1 Reading the Client's Opening Handshake (Lesen des Client-Handshakes)​

Der Server muss (MUST) Folgendes validieren:

  1. HTTP-Methode: Muss GET sein
  2. HTTP-Version: Mindestens HTTP/1.1
  3. Erforderliche Header: Host, Upgrade, Connection, Sec-WebSocket-Key, Sec-WebSocket-Version müssen vorhanden sein
  4. Sec-WebSocket-Version: Muss 13 sein (oder eine vom Server unterstützte Version)

Wenn die Validierung fehlschlägt, sollte (SHOULD) der Server einen entsprechenden HTTP-Fehlerstatuscode zurückgeben.

4.2.2 Sending the Server's Opening Handshake (Senden des Server-Handshakes)​

Wenn die Validierung erfolgreich ist, muss (MUST) der Server eine Handshake-Antwort senden:

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

Berechnung von Sec-WebSocket-Accept​

Dies ist ein kritischer Teil des Handshakes. Der Server muss wie folgt berechnen:

  1. Den Sec-WebSocket-Key-Wert des Clients nehmen
  2. Mit der festen GUID-Zeichenfolge verketten: 258EAFA5-E914-47DA-95CA-C5AB0DC85B11
  3. SHA-1-Hash auf die verkettete Zeichenfolge anwenden
  4. Das Hash-Ergebnis Base64-kodieren

Algorithmus-Beispiel (JavaScript):

const crypto = require('crypto');

function generateAcceptKey(clientKey) {
  const GUID = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11';
  const concatenated = clientKey + GUID;
  const hash = crypto.createHash('sha1').update(concatenated).digest();
  return hash.toString('base64');
}

// Beispiel
const clientKey = 'dGhlIHNhbXBsZSBub25jZQ==';
const acceptKey = generateAcceptKey(clientKey);
console.log(acceptKey); // s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

4.3 Collecting Extensions and Subprotocols (Sammeln von Erweiterungen und Unterprotokollen)​

Unterprotokoll-Verhandlung​

Der Client kann mehrere Unterprotokolle im Sec-WebSocket-Protocol-Header auflisten:

Sec-WebSocket-Protocol: chat, superchat

Der Server muss (MUST) eines (oder keines) aus der Liste des Clients auswählen und es in der Antwort zurückgeben:

Sec-WebSocket-Protocol: chat

Wenn der Server keines der vom Client angeforderten Unterprotokolle unterstützt, kann er den Sec-WebSocket-Protocol-Header weglassen.

Erweiterungs-Verhandlung​

Die Erweiterungs-Verhandlung erfolgt über den Sec-WebSocket-Extensions-Header:

Client-Anfrage:

Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

Server-Antwort:

Sec-WebSocket-Extensions: permessage-deflate

Der Server kann Erweiterungen akzeptieren, Parameter ändern oder ablehnen.

4.4 Supporting Multiple Versions (Unterstützung mehrerer Versionen)​

Wenn der Server die vom Client angeforderte Version nicht unterstützt, sollte (SHOULD) er HTTP 426 Upgrade Required zurückgeben und einen Sec-WebSocket-Version-Header mit den unterstützten Versionen einschließen:

HTTP/1.1 426 Upgrade Required
Sec-WebSocket-Version: 13, 8, 7

Vollständige Handshake-Beispiele​

Erfolgreicher Handshake​

Client → Server:

GET /chat HTTP/1.1
Host: example.com:8000
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat
Sec-WebSocket-Version: 13
Origin: http://example.com

Server → Client:

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

Beispiele für fehlgeschlagene Handshakes​

Nicht unterstützte Version:

HTTP/1.1 426 Upgrade Required
Sec-WebSocket-Version: 13

Origin nicht akzeptiert:

HTTP/1.1 403 Forbidden

Sicherheitsüberlegungen​

  1. Origin validieren: Server sollten den Origin-Header validieren, um Cross-Site-Angriffe zu verhindern
  2. TLS verwenden: wss:// in Produktionsumgebungen verwenden
  3. Alle Header validieren: Sicherstellen, dass alle erforderlichen Header vorhanden und korrekt formatiert sind
  4. Verbindungen begrenzen: Rate-Limiting implementieren, um DoS-Angriffe zu verhindern
Letztes Update am