Zum Hauptinhalt springen

WebSocket-Protokoll-Implementierungshandbuch (RFC 6455)

Dieses Dokument ist ein detailliertes technisches Handbuch und eine Implementierungsreferenz für RFC 6455, einschließlich Protokollbeschreibung, Codebeispielen und Best Practices. Für offizielle RFC-Kapitelübersetzungen siehe die jeweiligen Kapiteldokumente.

RFC 6455 - Das WebSocket-Protokoll

Internet Engineering Task Force (IETF)
Request for Comments: 6455
Kategorie: Standards Track

Autoren:
I. Fette (Google Inc.)
A. Melnikov (Isode Ltd.)

Veröffentlichungsdatum: Dezember 2011

Status dieses Memorandums​

Dies ist ein Internet Standards Track-Dokument.

Dieses Dokument ist ein Produkt der Internet Engineering Task Force (IETF) und repräsentiert den Konsens der IETF-Community.

Urheberrechtserklärung​

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

Zusammenfassung​

Das WebSocket-Protokoll ermöglicht Vollduplex-Kommunikation (Full-Duplex Communication) zwischen Client und Server über eine einzelne TCP-Verbindung. Das WebSocket-Protokoll ist für die Implementierung in Webbrowsern und Webservern konzipiert, kann aber von jeder Client- oder Serveranwendung verwendet werden.

Das WebSocket-Protokoll ist ein eigenständiges TCP-basiertes Protokoll. Seine einzige Beziehung zu HTTP besteht darin, dass sein Handshake (Handshake) von HTTP-Servern als Upgrade-Anfrage (Upgrade Request) interpretiert wird.

Durch sein Design soll das WebSocket-Protokoll auf bestehender HTTP-Infrastruktur funktionieren, daher verwendet es HTTP-Ports 80 und 443 und unterstützt HTTP-Proxies und Intermediäre, auch wenn dies eine gewisse Komplexität bedeutet.

Inhaltsverzeichnis​

WebSocket-Kernterminologie​

Grundlegende Konzepte​

Englischer BegriffDeutsche ÜbersetzungBeschreibung
WebSocket ProtocolWebSocket-ProtokollProtokoll zur Vollduplex-Kommunikation über eine einzelne TCP-Verbindung
Full-Duplex CommunicationVollduplex-KommunikationBidirektionale gleichzeitige Kommunikation
Opening HandshakeOpening HandshakeHTTP-Upgrade-Prozess zur Etablierung einer WebSocket-Verbindung
Closing HandshakeClosing HandshakeProzess zum ordnungsgemäßen Schließen einer WebSocket-Verbindung
FrameFrame / RahmenGrundeinheit der WebSocket-Datenübertragung
MessageNachrichtVollständige Anwendungsdaten, bestehend aus einem oder mehreren Frames
ClientClientPartei, die die WebSocket-Verbindung initiiert (normalerweise ein Browser)
ServerServerPartei, die die WebSocket-Verbindung akzeptiert
EndpointEndpunktClient oder Server
ConnectionVerbindungWebSocket-Verbindung zwischen Client und Server

Handshake-bezogen​

Englischer BegriffDeutsche ÜbersetzungBeschreibung
Upgrade RequestUpgrade-AnfrageHTTP-Anfrage zum Upgrade auf WebSocket
Sec-WebSocket-KeyWebSocket-SchlüsselVom Client gesendeter Zufallsschlüssel
Sec-WebSocket-AcceptWebSocket-AcceptVom Server zurückgegebener Verifizierungsschlüssel
Sec-WebSocket-ProtocolWebSocket-SubprotokollAusgehandeltes Anwendungsschicht-Subprotokoll
Sec-WebSocket-ExtensionsWebSocket-ErweiterungenAusgehandelte Protokollerweiterungen
Sec-WebSocket-VersionWebSocket-VersionProtokollversionsnummer (aktuell 13)
OriginOrigin / UrsprungHerkunft der Webseite, die die Verbindung initiiert

Frame-Struktur-bezogen​

Englischer BegriffDeutsche ÜbersetzungBeschreibung
FINFIN / EndbitKennzeichnet dies als letzten Frame einer Nachricht
RSVRSV / Reservierte BitsFür Erweiterungen reservierte Flag-Bits
OpcodeOpcode / OperationscodeDefiniert den Frame-Typ
MaskMaskeClient-zu-Server-Daten müssen maskiert werden
Masking-keyMaskierungsschlüssel32-Bit-Schlüssel für Datenmaskierung
Payload LengthNutzdatenlängeDatenlänge
Payload DataNutzdatenTatsächlich übertragene Daten
Extension DataErweiterungsdatenDurch Erweiterungen ausgehandelte zusätzliche Daten
Application DataAnwendungsdatenTatsächliche Daten der Anwendungsschicht

Frame-Typen​

Englischer BegriffDeutsche ÜbersetzungOpcodeBeschreibung
Continuation FrameFortsetzungsframe0x0Nachfolgende Frames einer Nachricht
Text FrameTextframe0x1UTF-8-codierte Textdaten
Binary FrameBinärframe0x2Binärdaten
Close FrameSchließen-Frame0x8Kontrollframe zum Verbindungsschließen
Ping FramePing-Frame0x9Heartbeat-Erkennungsanfrage
Pong FramePong-Frame0xAHeartbeat-Erkennungsantwort
Control FrameKontrollframe0x8-0xFFrames zur Verbindungssteuerung
Data FrameDatenframe0x1-0x2Frames zur Übertragung von Anwendungsdaten

Schließen-bezogen​

Englischer BegriffDeutsche ÜbersetzungBeschreibung
Close CodeSchließcodeNumerischer Code, der den Grund für das Verbindungsschließen angibt
Close ReasonSchließgrundTextbeschreibung des Schließens
Normal ClosureNormales SchließenCode 1000, ordnungsgemäßes Schließen nach Zweckerfüllung
Going AwayWeggangCode 1001, Endpunkt geht weg (z.B. Seitennavigation)
Protocol ErrorProtokollfehlerCode 1002, Protokollverletzung
Unsupported DataNicht unterstützte DatenCode 1003, inakzeptabler Datentyp empfangen
Invalid Frame Payload DataUngültige Frame-NutzdatenCode 1007, inkonsistente Daten
Policy ViolationRichtlinienverletzungCode 1008, Verletzung von Richtlinien
Message Too BigNachricht zu großCode 1009, Nachricht zu groß zum Verarbeiten
TLS Handshake FailureTLS-Handshake-FehlerCode 1015, TLS-Handshake fehlgeschlagen

Dokumentstruktur-Erklärung​

Abschnitt 1: Einführung und Übersicht​

  • Hintergrund und Anforderungen von WebSocket
  • Design-Ziele und Prinzipien des Protokolls
  • Beziehung zu HTTP/TCP
  • Sicherheitsmodell und Design-Philosophie

Abschnitte 2-3: Grundlegende Anforderungen​

  • Konformitätsanforderungen und Terminologiedefinitionen
  • WebSocket-URI-Format (ws:// und wss://)

Abschnitt 4: Opening Handshake (Kern)​

  • Wie Clients den Handshake initiieren
  • Wie Server auf den Handshake antworten
  • Aushandlung von Subprotokollen und Erweiterungen
  • Unterstützung mehrerer Versionen

Abschnitt 5: Datenrahmen (Kern)​

  • Detaillierte Beschreibung der Frame-Struktur
  • Maskierungsmechanismus
  • Fragmentierung (Übertragung großer Nachrichten in mehreren Frames)
  • Kontrollrahmen und Datenrahmen

Abschnitte 6-7: Datenübertragung und Verbindungsschließen​

  • Regeln zum Senden und Empfangen von Nachrichten
  • Normaler Schließablauf
  • Ausnahmebehandlung
  • Schließstatuscodes

Abschnitte 8-10: Erweiterungen, Fehler und Sicherheit​

  • Erweiterungsmechanismus
  • Fehlerbehandlung
  • Detaillierte Sicherheitsüberlegungen

WebSocket-Verbindungsaufbau-Ablauf​

1. Client initiiert HTTP-Upgrade-Anfrage

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

2. Server antwortet mit Upgrade

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

3. Verbindung etabliert, bidirektionale Kommunikation beginnt

Client ←→ Server
  ↓         ↓
Text/Binary Frames
Ping/Pong Frames
Close Frame

4. Verbindung schließen

Client → Server: Close Frame (Code: 1000)
Server → Client: Close Frame (Code: 1000)
TCP-Verbindung schließen

Handshake-Schlüssel-Berechnung​

Berechnungsmethode für Sec-WebSocket-Accept​

// 1. Client generiert zufälligen Sec-WebSocket-Key (Base64-codierte 16-Byte-Zufallszahl)
const clientKey = "dGhlIHNhbXBsZSBub25jZQ==";

// 2. Magic String (von RFC 6455 definierte feste GUID)
const magicString = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11";

// 3. Verketten und SHA-1-Hash berechnen
const concatenated = clientKey + magicString;
const hash = SHA1(concatenated);

// 4. Base64-Codierung ergibt Sec-WebSocket-Accept
const serverAccept = Base64Encode(hash);
// Ergebnis: "s3pPLMBiTxaQ9kYGzzhZRbK+xOo="

Dieser Mechanismus stellt sicher:

  • Server versteht das WebSocket-Protokoll (nicht nur ein normaler HTTP-Server)
  • Verhindert, dass Caching-Proxies falsche Antworten zurückgeben
  • Bietet grundlegende Handshake-Verifizierung

WebSocket-Frame-Struktur im Detail​

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+

Feldbeschreibungen​

FIN (1 bit):

  • 0 = weitere Frames folgen
  • 1 = dies ist der letzte (oder einzige) Frame der Nachricht

RSV1, RSV2, RSV3 (je 1 bit):

  • Für Erweiterungen reserviert
  • Muss 0 sein, wenn keine Erweiterung ausgehandelt wurde

Opcode (4 bits):

  • 0x0 = Continuation (Fortsetzungsframe)
  • 0x1 = Text (Textframe, UTF-8)
  • 0x2 = Binary (Binärframe)
  • 0x8 = Close (Schließen)
  • 0x9 = Ping
  • 0xA = Pong
  • 0x3-0x7, 0xB-0xF = Reserviert

MASK (1 bit):

  • Client zu Server: muss 1 sein
  • Server zu Client: muss 0 sein

Payload Length (7 bits, 7+16 bits, oder 7+64 bits):

  • 0-125: tatsächliche Länge
  • 126: nächste 16 Bits sind die tatsächliche Länge
  • 127: nächste 64 Bits sind die tatsächliche Länge

Masking-key (0 oder 4 bytes):

  • Wenn MASK=1, enthält 32-Bit-Maskierungsschlüssel

Payload Data:

  • Extension data + Application data

Maskierungsmechanismus-Erklärung​

Warum ist Maskierung erforderlich?​

Sicherheitsgründe: Verhindert Cache-Poisoning-Angriffe. Einige Intermediär-Proxies könnten WebSocket-Frames fälschlicherweise cachen, Maskierung stellt sicher, dass Daten unvorhersehbar sind.

Maskierungsalgorithmus​

// Beim Senden von Daten durch den Client
function maskData(data, maskingKey) {
  const masked = new Uint8Array(data.length);
  for (let i = 0; i < data.length; i++) {
    masked[i] = data[i] ^ maskingKey[i % 4];
  }
  return masked;
}

// Beim Empfangen von Daten durch den Server (gleicher Algorithmus zur Dekodierung)
function unmaskData(maskedData, maskingKey) {
  return maskData(maskedData, maskingKey);  // XOR ist selbstinvers
}

Schlüsselpunkte:

  • Verwendet XOR-Operation (^)
  • Schlüssellänge ist 4 Bytes
  • Zyklische Verwendung des Schlüssels
  • Client→Server: muss maskiert sein
  • Server→Client: verboten zu maskieren

Nachrichtenfragmentierung (Fragmentation)​

Große Nachrichten können in mehreren Frames gesendet werden:

Beispiel: Senden einer großen Textnachricht

Frame 1: FIN=0, Opcode=0x1 (Text), Payload="Hello "
Frame 2: FIN=0, Opcode=0x0 (Continuation), Payload="World"
Frame 3: FIN=1, Opcode=0x0 (Continuation), Payload="!"

Endgültige Nachricht: "Hello World!"

Regeln:

  • Erster Frame: FIN=0, Opcode=Datentyp (0x1 oder 0x2)
  • Mittlere Frames: FIN=0, Opcode=0x0 (Continuation)
  • Letzter Frame: FIN=1, Opcode=0x0 (Continuation)
  • Kontrollrahmen können nicht fragmentiert werden und können zwischen fragmentierten Datenframes eingefügt werden

Kontrollrahmen im Detail​

Close-Frame (0x8)​

Struktur:
+--------+--------+------------------+
| Code   | Reason |
| (2 Bytes) | (UTF-8-Text)           |
+--------+--------+------------------+

Beispiel:
Close Code: 1000 (Normales Schließen)
Close Reason: "Going away"

Häufig verwendete Schließcodes:

  • 1000: Normal Closure (Normales Schließen)
  • 1001: Going Away (Endpunkt geht weg, z.B. Seitennavigation)
  • 1002: Protocol Error (Protokollfehler)
  • 1003: Unsupported Data (Nicht unterstützter Datentyp)
  • 1006: Abnormal Closure (Abnormales Schließen, kein Close-Frame gesendet)
  • 1009: Message Too Big (Nachricht zu groß)
  • 1011: Internal Server Error (Interner Serverfehler)

Ping-Frame (0x9)​

  • Kann von Client oder Server gesendet werden
  • Verwendet für Heartbeat-Erkennung (Verbindung aktiv halten)
  • Kann Anwendungsdaten tragen (maximal 125 Bytes)
  • Empfänger muss mit Pong-Frame antworten

Pong-Frame (0xA)​

  • Wird verwendet, um auf Ping-Frame zu antworten
  • Muss dieselbe Payload wie der Ping-Frame enthalten
  • Kann auch proaktiv gesendet werden (unidirektionaler Heartbeat)

Schließablauf​

Normales Schließen (Clean Close)​

1. Initiator sendet Close-Frame
   Client → Server: Close Frame (Code: 1000)

2. Empfänger antwortet mit Close-Frame
   Server → Client: Close Frame (Code: 1000)

3. Initiator schließt TCP-Verbindung
   Client: TCP-Verbindung schließen

4. Empfänger schließt auch TCP-Verbindung
   Server: TCP-Verbindung schließen

Abnormales Schließen​

  • TCP-Verbindung plötzlich unterbrochen (kein Close-Frame)
  • Ungültige Frame-Daten empfangen
  • Timeout ohne Antwort
  • Protokollregel-Verletzung

Statuscode: 1006 (Abnormal Closure) - Dieser Code wird nicht in Close-Frames gesendet, nur für Berichterstattung verwendet

WebSocket-URI-Format​

ws:// (unverschlüsselt)​

ws://example.com/socket
ws://example.com:8080/chat
ws://192.168.1.1/data
  • Standard-Port: 80
  • Entspricht http:// Sicherheitsstufe

wss:// (TLS-verschlüsselt)​

wss://example.com/socket
wss://secure.example.com:443/chat
  • Standard-Port: 443
  • Entspricht https:// Sicherheitsstufe
  • Stark empfohlen für Produktionsumgebungen wss:// zu verwenden

Subprotokoll (Subprotocol)​

WebSocket ist ein Transportschichtprotokoll, Subprotokolle definieren das Nachrichtenformat der Anwendungsschicht:

Client-Anfrage:
Sec-WebSocket-Protocol: chat, superchat

Server-Antwort:
Sec-WebSocket-Protocol: chat

Etablierte Verbindung verwendet "chat"-Subprotokoll

Häufige Subprotokolle:

  • STOMP: Simple Text Oriented Messaging Protocol
  • MQTT: Message Queuing Telemetry Transport
  • WAMP: Web Application Messaging Protocol
  • Benutzerdefinierte Anwendungsprotokolle

Erweiterungen (Extensions)​

Erweiterungen können WebSocket-Funktionen erweitern:

Client-Anfrage:
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

Server-Antwort:
Sec-WebSocket-Extensions: permessage-deflate

Häufig verwendete Erweiterungen:

  • permessage-deflate: Nachrichtenkomprimierung (RFC 7692)
  • permessage-bzip2: Bzip2-Komprimierung
  • Benutzerdefinierte Erweiterungen

Wichtige Sicherheitsüberlegungen​

1. Origin-Validierung​

// Server-seitige Origin-Validierung
const allowedOrigins = ['https://example.com', 'https://app.example.com'];
const origin = request.headers['origin'];

if (!allowedOrigins.includes(origin)) {
  // Verbindung ablehnen
  response.status(403).send('Forbidden');
}

2. TLS-Verschlüsselung​

  • Muss wss:// in Produktionsumgebungen verwenden
  • Verhindert Man-in-the-Middle-Angriffe
  • Schützt Datenvertraulichkeit und -integrität

3. Authentifizierung und Autorisierung​

Methode 1: Authentifizierung während des Handshakes über Cookies
GET /socket HTTP/1.1
Cookie: session=abc123

Methode 2: Token über Subprotokoll übergeben
ws://example.com/socket?token=jwt_token

Methode 3: Authentifizierungsinformationen in erster Nachricht nach Verbindung

4. Rate Limiting​

  • Anzahl der Verbindungen begrenzen (DoS-Prävention)
  • Nachrichtengröße begrenzen
  • Nachrichtenfrequenz begrenzen

5. Eingabevalidierung​

  • UTF-8-Codierung validieren (Textframes)
  • Nachrichtenformat validieren
  • Injection-Angriffe verhindern

Best Practices für die Implementierung​

Client (Browser)​

// 1. WebSocket-Verbindung erstellen
const ws = new WebSocket('wss://example.com/socket', ['chat']);

// 2. Event-Listener registrieren
ws.addEventListener('open', (event) => {
  console.log('Verbindung hergestellt');
  ws.send('Hello Server!');
});

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

ws.addEventListener('error', (event) => {
  console.error('WebSocket-Fehler:', event);
});

ws.addEventListener('close', (event) => {
  console.log('Verbindung geschlossen', event.code, event.reason);
  // Wiederverbindungslogik implementieren
  if (event.code !== 1000) {
    setTimeout(() => reconnect(), 5000);
  }
});

// 3. Daten senden
ws.send('Textnachricht');
ws.send(new Blob(['Binärdaten']));
ws.send(new ArrayBuffer(8));

// 4. Verbindung schließen
ws.close(1000, 'Normales Schließen');

Server-Seite (Node.js-Beispiel)​

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

wss.on('connection', (ws, request) => {
  // Origin validieren
  const origin = request.headers.origin;
  // ...Validierungslogik
  
  // Heartbeat-Erkennung
  ws.isAlive = true;
  ws.on('pong', () => { ws.isAlive = true; });
  
  // Nachrichten empfangen
  ws.on('message', (data) => {
    console.log('Empfangen:', data);
    
    // An alle Clients broadcasten
    wss.clients.forEach((client) => {
      if (client.readyState === WebSocket.OPEN) {
        client.send(data);
      }
    });
  });
  
  // Fehlerbehandlung
  ws.on('error', (error) => {
    console.error('Fehler:', error);
  });
  
  // Schließen
  ws.on('close', (code, reason) => {
    console.log('Verbindung geschlossen:', code, reason);
  });
});

// Heartbeat-Erkennung
const interval = setInterval(() => {
  wss.clients.forEach((ws) => {
    if (ws.isAlive === false) {
      return ws.terminate();
    }
    ws.isAlive = false;
    ws.ping();
  });
}, 30000);

Häufige Anwendungsszenarien​

1. Echtzeit-Chat-Anwendungen​

  • Instant Messaging
  • Online-Status-Anzeige
  • Tippt-Indikator

2. Echtzeit-Kollaborationstools​

  • Gemeinsame Dokumentbearbeitung (wie Google Docs)
  • Whiteboard-Sharing
  • Kollaborativer Code-Editor

3. Echtzeit-Datenströme​

  • Aktienkurse
  • Sportergebnisse
  • IoT-Daten

4. Online-Spiele​

  • Mehrspieler-Online-Spiele
  • Echtzeit-Spielzustands-Synchronisation
  • Niedrige Latenz-Interaktion

5. Push-Benachrichtigungen​

  • Browser-Push
  • Echtzeit-Warnungen
  • Systemüberwachung

Vergleich mit anderen Technologien​

WebSocket vs HTTP Long Polling​

FeatureWebSocketLong Polling
VerbindungPersistente VerbindungWiederholte HTTP-Anfragen
LatenzSehr niedrigHöher (HTTP-Overhead)
BidirektionalEcht bidirektionalPseudo-bidirektional
RessourcenNiedrig (eine Verbindung)Hoch (mehrere Verbindungen)
KomplexitätMittelEinfacher

WebSocket vs Server-Sent Events (SSE)​

FeatureWebSocketSSE
Bidirektionale Kommunikation✅ Bidirektional❌ Nur Server→Client
DatenformatBinär oder TextText (UTF-8)
ProtokollEigenständiges ProtokollBasierend auf HTTP
Browser-UnterstützungWeit verbreitetWeit verbreitet (außer IE)
WiederverbindungManuelle ImplementierungAutomatische Wiederverbindung

Debug-Tools​

Browser-Entwicklertools​

  • Chrome DevTools → Network → WS
  • Frame-Senden und -Empfangen anzeigen
  • Verbindungsstatus anzeigen

Befehlszeilen-Tools​

# wscat (Node.js)
npm install -g wscat
wscat -c ws://echo.websocket.org

# websocat (Rust)
websocat ws://echo.websocket.org

Online-Test-Tools​

  • websocket.org Echo Test
  • Hoppscotch (ehemals Postwoman)
  • Firecamp

Referenzressourcen​

Verwandte RFC-Standards​

  • RFC 6455: WebSocket-Protokoll (dieses Dokument)
  • RFC 7692: WebSocket-Komprimierungserweiterung
  • RFC 8441: WebSocket-Bootstrapping über HTTP/2
  • RFC 8307: Well-Known URI für WebSocket

Empfohlene Implementierungsbibliotheken​

JavaScript (Browser):

  • Native WebSocket-API

Node.js:

  • ws (leichtgewichtig)
  • Socket.IO (funktionsreich, automatisches Fallback)
  • uWebSockets.js (hochperformant)

Python:

  • websockets (asyncio)
  • ws4py
  • Tornado

Java:

  • Java WebSocket API (JSR 356)
  • Netty
  • Spring WebSocket

Go:

  • gorilla/websocket
  • nhooyr/websocket

Nächste Lernschritte​

  1. Grundlagen: WebSocket-Handshake und Frame-Struktur verstehen
  2. Praxis: Einfache Chat-Anwendung implementieren
  3. Fortgeschritten: Subprotokolle und Erweiterungen lernen
  4. Optimierung: Heartbeat, Wiederverbindung, Fehlerbehandlung implementieren
  5. Sicherheit: Sicherheitsüberlegungen und Best Practices vertiefen

Zusammenfassung​

Das WebSocket-Protokoll ist der Grundstein für Web-Echtzeit-Kommunikation:

  • Genauigkeit: Präzise Implementierung bidirektionaler Kommunikation
  • Übermittlung: Klare Protokollspezifikation
  • Eleganz: Elegantes Design und Implementierung

Kernwerte:

  1. 🔄 Echte Vollduplex-Kommunikation
  2. ⚡ Niedrige Latenz-Echtzeit-Datenübertragung
  3. 📦 Leichtgewichtiges Frame-Protokoll
  4. 🔐 Integrierte Sicherheitsmechanismen

Beste Anwendungsszenarien:

  • Echtzeit-Chat
  • Kollaborative Bearbeitung
  • Echtzeit-Spiele
  • Echtzeit-Datenströme
  • Push-Benachrichtigungen

Verwandte RFCs:

  • RFC 6455: WebSocket-Protokoll (dieses Dokument)
  • RFC 7692: WebSocket-Komprimierungserweiterung
  • RFC 8441: WebSocket-Bootstrapping über HTTP/2

Zurück zur RFC-Liste

Letztes Update am