Wie WebSockets funktionieren

Original in Englisch: https://www.deepintodev.com/blog/how-websockets-work
Übersetzt mit DeepL.com

Wie WebSockets funktionieren

26. November 2025 Zuletzt aktualisiert am: 29. November 2025

Nachdem Sie diesen Artikel gelesen haben, werden Sie ein solides Verständnis für folgende Themen haben:

   Was sind WebSockets?
   Warum WebSockets erfunden wurden
   Die wichtigsten Anwendungsfälle von WebSockets, ihre Vor- und Nachteile
   Optimierungstechniken und praktische Anwendung von WebSockets

Um WebSockets zu verstehen, müssen wir zunächst verstehen, warum WebSockets erfunden wurden. Und dafür müssen wir über einen alten Bekannten sprechen: HTTP.

Als HTTP 1.0 erfunden wurde, war es im Grunde genommen als einfaches Anfrage-Antwort-System konzipiert: Der Client stellt eine Anfrage und der Server sendet eine Antwort zurück. In dieser Konfiguration ist es immer der Client, der den Anfrage-Antwort-Zyklus initiieren muss.

Diese Architektur hatte jedoch einen kleinen Nachteil: Sobald der Client eine Anfrage gestellt und die Antwort erhalten hatte, wurde die TCP-Verbindung sofort geschlossen. Das bedeutete, dass wir für jede einzelne Anfrage eine komplett neue TCP-Verbindung aufbauen mussten.

   Hinweis: Ich habe auch einen ausführlichen Blog, in dem ich das HTTP-Protokoll, HTTPS, TCP/UDP und mehr erkläre. Es ist nicht notwendig, ihn für diesen Artikel zu lesen, aber wenn Sie neugierig sind, erhalten Sie ein solides Verständnis dieser Protokolle und der Funktionsweise der Kommunikation. Wie Daten um die Welt reisen, um auf Ihren Bildschirm zu gelangen: Ein tiefer Einblick in OSI, TCP/UDP, HTTP und mehr.

Stellen Sie sich vor, unsere Website hätte 5 Seiten und 30 Bilder. Für jede einzelne dieser Anfragen müssten wir eine neue TCP-Verbindung herstellen. Das war ineffizient, daher haben wir HTTP 1.1 eingeführt.

Dieses Mal haben wir mit HTTP 1.1 die Verbindung nach der ersten Anfrage offen gehalten.

Diese Architektur funktioniert auch heute noch gut, aber es gibt einige Anwendungsfälle, die Echtzeitmaßnahmen erfordern. Manchmal muss der Server uns Informationen senden, auch wenn wir als Clients keine Anfrage gestellt haben. Und genau aus diesem Grund wurde eine andere Technologie entwickelt.

WebSockets verwenden im Wesentlichen HTTP/1.1, um eine dauerhafte Verbindung herzustellen. Mit anderen Worten: Sie beginnen als normale HTTP/1.1-Verbindung und werden dann zu einer dauerhaften WebSocket-Verbindung aufgewertet.

Um eine WebSocket-Verbindung herzustellen, sendet der Client zunächst eine HTTP/1.1-Anfrage mit einigen speziellen Headern. Unsere Anfrage würde wie folgt aussehen:

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

Mal sehen, was sie damit meinen.

Upgrade: WebSocket – das bedeutet: „Lasst uns das HTTP-Protokoll auf WebSocket upgraden.“

Verbindung: Upgrade – das bedeutet, dass sich „der Verbindungstyp für diese Kommunikation ändern wird“.

Sec-WebSocket-Key – Dies ist ein eindeutiger Schlüssel, der vom Client während des Handshakes gesendet wird, damit der Server überprüfen und bestätigen kann, dass es sich um eine echte WebSocket-Verbindung handelt.

Dann nimmt der Server diese Anfrage entgegen und antwortet, sofern er WebSockets unterstützt, wie folgt:

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

101 Switching Protocols – 101 ist der HTTP-Statuscode, der angibt, dass der Server bereit ist, zu einem anderen vom Client angeforderten Protokoll (z. B. WebSocket) zu wechseln, genau wie andere HTTP-Statuscodes wie 200 oder 404.

Sec-WebSocket-Accept – Mit diesem Schlüssel teilt der Server dem Client mit: „Ich bin ein legitimer WebSocket-Server.“

Der Client sendet also einen Schlüssel (Sec-WebSocket-Key) und der Server antwortet mit Sec-WebSocket-Accept. (Der Server nimmt den Schlüssel des Clients, hängt eine feste GUID an, hasht ihn mit SHA-1 und codiert ihn in Base64. Beispiel: Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=.)

Anschließend überprüft der Client dies, indem er denselben Vorgang mit seinem ursprünglichen Schlüssel durchführt und ihn mit dem Sec-WebSocket-Accept des Servers vergleicht. Stimmen beide überein, ist der Handshake gültig und sicher. Ist dies nicht der Fall, wird die Verbindung abgelehnt. Ein ziemlich einfacher Vorgang, oder?

Ab diesem Zeitpunkt verwenden wir HTTP nicht mehr. Über dieselbe TCP-Verbindung beginnen wir, das WebSocket-Protokoll zu verwenden. Wir haben also nicht einmal die für die HTTP-Anfrage geöffnete TCP-Verbindung geschlossen, sondern lediglich das Protokoll gewechselt. Das finde ich ziemlich cool.

Und jetzt herrscht Wildwest. Der Server und der Client können über die dauerhafte Verbindung frei Nachrichten austauschen, da sie sich gegenseitig kennen. Es gibt keinen strengen Anfrage- und Antwortzyklus wie bei HTTP. Der Client muss nicht nach Daten fragen, der Server kann sie jederzeit senden, auch ohne eine Anfrage des Clients.

Sie können jederzeit Ihren eigenen WebSocket-Server betreiben, wenn Sie möchten, oder Sie können etwas wie Socket.IO verwenden, das Ihnen einen vorgefertigten Server mit zusätzlichen Funktionen bietet.

Nachdem wir nun wissen, was WebSockets sind, ist es an der Zeit, uns ihre Anwendungsfälle anzusehen.

Anwendungsfälle für WebSocket

Online-Chat – Jeder kann jedem anderen eine Nachricht senden, ohne dass die andere Person darum gebeten hat. Man möchte nicht ständig den Server fragen: „Gibt es eine Nachricht für mich? Gibt es eine Nachricht für mich?“ Das ist unnötig und ineffizient. Hier kommt eine dauerhafte Verbindung ins Spiel, die den freien Datenaustausch ermöglicht. Live-Chats sind ein perfektes Beispiel für den Einsatz von WebSockets.

Multiplayer-Gaming – Spieler können ihre Aktionen oder Spielstatus-Updates sofort aneinander senden, ohne darauf warten zu müssen, dass der Server sie abfragt. Es ist keine ständige Abfrage wie „Ist etwas passiert?“ erforderlich. Alles läuft in Echtzeit ab. WebSockets sorgen dafür, dass dies schnell und reibungslos funktioniert.

   Hinweis: Polling: Senden wiederholter Anfragen an den Server in regelmäßigen Abständen mit der Frage: „Gibt es etwas Neues?“

Anzeigen des Client-Fortschritts / Protokollierung -> Der Server kann Aktualisierungen, Protokolle oder Fortschrittsinformationen sofort an den Client weiterleiten. Der Client muss nicht immer wieder nachfragen: „Wie ist der Status?“ WebSockets machen dies sofort und effizient.

Websocket-Nachteile

Auch wenn WebSockets eine erstaunliche Technologie zu sein scheinen, ist nichts perfekt. Sie haben auch einige Nachteile. Bevor wir also loslegen und sie überall einsetzen, sollten wir uns die Nachteile ansehen. Es ist immer besser, von Anfang an zu wissen, womit man es zu tun hat.

Proxying ist knifflig -> Die Verarbeitung von WebSocket-Verbindungen über Proxys kann knifflig sein, da viele Proxys für den Standard-HTTP-Datenverkehr ausgelegt sind und die persistenten Verbindungen von WebSocket möglicherweise nicht vollständig unterstützen.

   Hinweis: Proxying bezeichnet das Weiterleiten von Netzwerkanfragen über einen Zwischenserver, der diese zwischen dem Client und dem Zielserver weiterleitet. Es wird häufig in Unternehmensnetzwerken für Sicherheits- und Inhaltsfilterung, in CDNs für Caching und in VPNs für Datenschutz und die Kontrolle des geografischen Zugriffs verwendet.

Zustandsbehaftet und schwer horizontal skalierbar -> WebSocket-Verbindungen sind zustandsbehaftet, was bedeutet, dass der Server die Verbindung jedes Clients verfolgen muss. Dies erschwert die Verteilung der Last auf mehrere Server (horizontale Skalierung) im Vergleich zu zustandslosen Protokollen wie HTTP.

   Hinweis: Wenn Sie mehr über zustandsbehaftete Architekturen erfahren möchten, lesen Sie diesen Artikel. Zustandsbehaftete vs. zustandslose Architekturen verstehen

Nun, da wir eine ziemlich gute Vorstellung davon haben, was WebSockets sind, lautet die eigentliche Frage: Müssen wir sie tatsächlich verwenden?

Unser Szenario ist wirklich wichtig. Nehmen wir an, wir möchten Live-Updates vom Server an den Client senden, wie Benachrichtigungen, Live-Ergebnisse oder Newsfeed-Updates. Das bedeutet, dass wir nur eine einseitige Kommunikation vom Server zum Client benötigen. Man könnte meinen, dass WebSockets hier nützlich wären, aber tatsächlich wären sie unnötig und ineffizient. Es gibt Ansätze wie EventSource, die speziell für solche Szenarien entwickelt wurden. Mit EventSource kann der Server Daten über eine einzige HTTP-Verbindung an den Client übertragen. Die Verbindung bleibt offen und Aktualisierungen werden sofort gesendet, ohne dass der Client ständig neue Daten anfordert.

EventSource kann also für die Kommunikation zwischen Server und Client eine bessere Wahl sein als WebSockets, da es einfacher ist, gut mit HTTP zusammenarbeitet und automatische Wiederverbindungen ohne den Overhead von Vollduplex-Verbindungen verarbeitet.

Wenn Ihre Anwendung nur einfache Anfrage- und Antwortinteraktionen erfordert, benötigen Sie wahrscheinlich überhaupt keine WebSocket-Verbindung.

Wir müssen nur kluge Entscheidungen treffen. Einfachheit sollte unser Verbündeter sein.

Optimierungstechniken bei der Verwendung von Web-Sockets

Von außen betrachtet scheinen WebSockets eine perfekte Technologie zu sein. In der Praxis jedoch, beispielsweise in einem Multiplayer-Spiel mit Live-Kommunikation, gibt es viele Details zu beachten, bevor man WebSockets einsetzt.

Wenn Sie beispielsweise in einem Multiplayer-Spiel den Status jedes Spielers als JSON-Objekt an den Server senden und dann an alle anderen Spieler übertragen möchten, könnte ein einfaches JSON für einen einzelnen Spieler wie folgt aussehen:

{
  "id": 123,
  "x": 345.5,
  "y": 678.2,
  "health": 100,
  "mana": 50,
  "status": "running"
}

Wenn Sie 100 Spieler in einem Multiplayer-Spiel haben und jeder von ihnen die aktuelle Position, Gesundheit, Mana und andere Spielzustände aller anderen Spieler kennen muss, müssen Sie im Grunde genommen alle relevanten Spielzustandsaktualisierungen in jedem Frame (oder mit einer festen Tickrate, normalerweise 30–60 Mal pro Sekunde) an alle übertragen.

Wenn Sie beispielsweise naiv für jeden Frame ein vollständiges JSON-Objekt für jeden Spieler an alle anderen Spieler senden, summieren sich die Daten schnell:

100 Spieler × 100 JSON-Objekte × jeweils ~100 Byte = ~1 MB pro Frame. Bei 60 FPS sind das ~60 MB/s an Rohdaten im Netzwerk.

Check: https://www.javainuse.com/bytesizejson

Das ist natürlich äußerst ineffizient und würde zu ENORMEN Problemen hinsichtlich Bandbreitennutzung und Latenz führen.

Das Problem sind nicht die WebSockets selbst, sondern die Art und Weise, wie wir Daten senden. Das Senden vollständiger JSON-Daten für jeden Spieler und jeden Frame ist sehr aufwendig. Wir müssen die Daten auf eine viel intelligentere Weise senden.

JSON ist leicht zu lesen, aber groß. Anstatt JSON-Daten zu senden, können wir beispielsweise Binärdaten verwenden, um dieselben Informationen in nur 12 Byte zu senden. Das ist viel kleiner (fast 10-mal) und schneller.

So geht's mit JavaScript:

// Step 1: Create a 12-byte buffer
// id -> 4 bytes (Uint32), x -> 4 bytes (Float32), y -> 4 bytes (Float32)
const buffer = new ArrayBuffer(12);
const view = new DataView(buffer);

// Step 2: Write the data into the buffer
view.setUint32(0, 123); // player id
view.setFloat32(4, 345.5); // x coordinate
view.setFloat32(8, 678.2); // y coordinate

// Step 3: Send the buffer over WebSocket
ws.send(buffer);

So funktioniert es:

   ArrayBuffer(12) erstellt 12 Byte Speicherplatz.
   Mit DataView können Sie Zahlen in verschiedenen Typen (wie Ganzzahlen oder Gleitkommazahlen) in diesen Speicher schreiben.
   setUint32 schreibt eine 4-Byte-Ganzzahl für die Spieler-ID.
   setFloat32 schreibt einen 4-Byte-Float für die x- und y-Koordinaten.
   ws.send(buffer) sendet die Binärdaten direkt an den Server.

Letztendlich mögen WebSockets sehr praktisch erscheinen und uns viel Freiheit bieten. Aber egal, wie magisch sie auch erscheinen mögen, wir müssen bei ihrer Verwendung dennoch andere technische Probleme im Auge behalten.