WebSockets einfach erklärt: Echtzeit-Kommunikation im Web

Klassisches HTTP basiert auf dem Request-Response-Prinzip: Der Client stellt eine Anfrage, der Server antwortet, und die Verbindung wird sofort wieder geschlossen. Was für das Laden statischer Dokumente hervorragend funktioniert, erweist sich bei modernen Echtzeitanwendungen wie Live-Chats, kollaborativen Editoren, Finanz-Tickern oder Multiplayer-Games als unbrauchbar. WebSockets lösen dieses Problem elegant, indem sie eine dauerhafte, bidirektionale Verbindung zwischen Client und Server etablieren.

Wie WebSockets funktionieren

Der Aufbau einer WebSocket-Verbindung beginnt mit einer gewöhnlichen HTTP-Anfrage – dem sogenannten „Handshake“ (Händeschütteln). Der Client signalisiert dem Server über den Header Upgrade: websocket den Wunsch nach einem Protokollwechsel. Unterstützt der Server diese Technologie, antwortet er mit dem Statuscode 101 Switching Protocols. Ab diesem Moment ist der Kommunikationskanal in beide Richtungen offen, sodass Daten ohne den Overhead ständiger neuer HTTP-Anfragen ausgetauscht werden können.

Client → Server:
GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

Server → Client:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

HTTP vs. WebSockets im direkten Vergleich

• HTTP: Vom Client initiiert, anfrage- und antwortbasiert, zustandslos. Hoher Daten-Overhead bei jeder Nachricht, da die Header-Informationen jedes Mal komplett neu übertragen werden müssen.
• WebSockets: Bidirektional und persistent. Die Verbindung bleibt offen (zustandsbehaftet), und der Overhead pro Nachricht ist mit nur 2 bis 14 Byte extrem gering.
• SSE (Server-Sent Events): Ein reiner Push-Kanal vom Server zum Client, basierend auf HTTP. Deutlich einfacher zu implementieren als WebSockets, falls Daten nur in eine Richtung fließen müssen.

Implementierung im Browser (Client-Side)

const ws = new WebSocket("wss://api.example.com/ws");

// Verbindung erfolgreich geöffnet
ws.addEventListener("open", () => {
  console.log("Erfolgreich verbunden!");
  ws.send(JSON.stringify({ type: "join", room: "general" }));
});

// Auf eingehende Nachrichten lauschen
ws.addEventListener("message", (event) => {
  const data = JSON.parse(event.data);
  console.log("Nachricht empfangen:", data);
});

// Verbindung geschlossen
ws.addEventListener("close", (event) => {
  console.log(`Verbindung getrennt: ${event.code} ${event.reason}`);
});

// Fehlerbehandlung
ws.addEventListener("error", (error) => {
  console.error("WebSocket-Fehler aufgetreten:", error);
});

Node.js Server-Beispiel mit der Bibliothek ws

import { WebSocketServer } from "ws";

const wss = new WebSocketServer({ port: 8080 });

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

  ws.on("message", (message) => {
    const data = JSON.parse(message);

    // Nachricht an alle aktiven Clients senden (Broadcast)
    wss.clients.forEach((client) => {
      if (client.readyState === 1) {
        client.send(JSON.stringify({
          type: "message",
          text: data.text,
          timestamp: Date.now()
        }));
      }
    });
  });

  ws.on("close", () => {
    console.log("Client-Verbindung geschlossen");
  });
});

Wann sollten Sie WebSockets nutzen?

• ✅ Hervorragend geeignet für: Echtzeit-Chats, sofortige Push-Benachrichtigungen, kollaborative Produktivitäts-Tools (wie Google Docs), Multiplayer-Games, Live-Sport-Ticker, Krypto- oder Aktien-Kursdaten sowie interaktive IoT-Dashboards.
• ❌ Nicht empfohlen für: Standardmäßige CRUD-Datenabfragen, Datei-Uploads, seltene oder unregelmäßige Aktualisierungen (hier sind klassische REST-Schnittstellen oder Server-Sent Events oft wartungsärmer und stabiler).

Wichtige Aspekte für den Produktivbetrieb

• Automatische Wiederverbindung (Reconnection): Da Netzwerkverbindungen instabil sein können, sollte der Client im Falle eines Abbruchs versuchen, die Verbindung automatisch neu aufzubauen (am besten mit einem exponentiellen Backoff-Verfahren).
• Heartbeats (Ping/Pong): Senden Sie in regelmäßigen Abständen Ping- und Pong-Signale, um verwaiste Verbindungen (Dead Connections) schnell zu erkennen und Server-Ressourcen freizugeben.
• Sichere Authentifizierung: Da der initiale Handshake über HTTP abläuft, sollten Sie Authentifizierungstoken (wie JWTs) direkt während des Verbindungsaufbaus oder in der allerersten WebSocket-Nachricht validieren.
• Skalierung im Cluster: Da WebSockets zustandsbehaftet sind, müssen Sie beim Betrieb mehrerer Server-Instanzen ein Pub/Sub-System (wie Redis oder NATS) vorschalten, um Nachrichten instanzübergreifend an alle Clients zu verteilen.
• Load Balancing: Nicht jeder Load Balancer ist standardmäßig für Protokoll-Upgrades konfiguriert. Stellen Sie sicher, dass Ihre Infrastruktur persistente Sessions (Sticky Sessions) sowie das WebSocket-Protokoll nativ unterstützt.