Programmierung · Web · Netzwerk
Was ist ein WebSocket?
Der Großteil des Webs funktioniert nach dem Prinzip Anfrage und Antwort: Der Browser fragt, der Server antwortet, die Verbindung wird geschlossen. Das ist gut zum Laden einer Seite, scheitert aber, sobald man Live-Aktualisierungen will — eine Chat-Nachricht, einen Börsenkurs, einen Spielzug im Mehrspielermodus — die der Server in dem Moment pushen muss, in dem sie eintreten. Ein WebSocket ist die Standardantwort. Dieser Leitfaden erklärt, was ein WebSocket ist, wie er sich von gewöhnlichem HTTP unterscheidet und wann Sie ihn wirklich brauchen.
Die Kernidee: eine Verbindung, beide Richtungen
Ein WebSocket ist eine dauerhafte, bidirektionale (full-duplex) Verbindung zwischen einem Client — meist einem Browser — und einem Server. Sobald sie offen ist, kann jede Seite jederzeit eine Nachricht senden, ohne dass die andere Seite zuerst fragen muss. Das ist der entscheidende Unterschied zu einer gewöhnlichen HTTP-API: HTTP ist eine Anfrage, eine Antwort, dann fertig; ein WebSocket bleibt offen und befördert Nachrichten in beide Richtungen, so lange Sie ihn brauchen.
Weil die Verbindung bereits offen ist, treffen Nachrichten mit sehr wenig Overhead und nahezu ohne Verzögerung ein. Es gibt keine wiederholten Header, keinen neuen Handshake pro Nachricht — nur eine kleine Frame an Daten in jede Richtung. Genau das macht WebSockets für alles geeignet, was sich sofort anfühlen muss.
Wie ein WebSocket startet: der HTTP-Handshake
Ein WebSocket erscheint nicht aus dem Nichts — er beginnt als gewöhnliche HTTP-Anfrage. Der Browser sendet eine normale Anfrage mit einem Upgrade: websocket-Header und bittet den Server im Grunde, das Protokoll zu wechseln. Stimmt der Server zu, antwortet er mit Status 101 Switching Protocols, und von da an hört dieselbe TCP-Verbindung auf, HTTP zu sprechen, und beginnt, das WebSocket-Protokoll zu sprechen. Deshalb laufen WebSockets über dieselben Ports wie das Web (80 und 443) und passieren die meisten Firewalls, die Web-Verkehr bereits zulassen.
Nach dem Handshake bewegen sich Daten als leichtgewichtige Frames. Jede Nachricht kann Text sein — sehr oft JSON — oder binär, und es gibt keine feste Anfrage/Antwort-Form: Nachrichten fließen einfach, wenn es etwas zu senden gibt.
ws vs wss
WebSocket-URLs verwenden ihr eigenes Schema. ws:// ist eine unverschlüsselte Verbindung, und wss:// ist die verschlüsselte Variante, mit TLS abgesichert, genau wie es https:// ist. In der Praxis sollten Sie in Produktion immer wss:// verwenden — es ist verschlüsselt und wird weit seltener von Proxys und Firmennetzen blockiert, die unverschlüsseltem ws://-Verkehr misstrauen.
WebSocket-Objekt und warten dann auf Nachrichten, sobald sie eintreffen.Wann man einen WebSocket nutzt (und wann nicht)
WebSockets glänzen immer dann, wenn der Server Daten an den Client pushen muss, sobald sie eintreten:
- Chat und Messaging — Nachrichten erscheinen in dem Moment, in dem sie gesendet werden.
- Live-Dashboards und Kurse — Börsenticker, Metriken, Sportergebnisse.
- Zusammenarbeit — gemeinsame Dokumente und Whiteboards, deren Änderungen live synchronisieren.
- Mehrspieler-Spiele — latenzarme Zustandsaktualisierungen in beide Richtungen.
- Benachrichtigungen — alles, was der Nutzer ohne Neuladen sehen soll.
Sie sind nicht für alles das richtige Werkzeug. Wenn der Client immer nur fragt und der Server immer nur antwortet — eine Seite laden, ein Formular absenden, einen Datensatz abrufen — ist eine schlichte HTTP-API einfacher, cachebar und leichter zu skalieren. Greifen Sie zu einem WebSocket, wenn der Server das Gespräch beginnen muss.
WebSockets vs. Polling vs. SSE
Vor WebSockets war der übliche Trick für „Live"-Daten das Polling: Der Client fragt den Server alle paar Sekunden „etwas Neues?". Das funktioniert, ist aber verschwenderisch — die meisten Anfragen kommen leer zurück, und Aktualisierungen hinken weiterhin um das Polling-Intervall hinterher. Ein WebSocket ersetzt all das durch eine offene Verbindung und null verschwendete Anfragen.
Es gibt außerdem Server-Sent Events (SSE), die Ihnen einen einseitigen Stream vom Server zum Client über schlichtes HTTP geben. SSE ist einfacher, wenn nur der Server pushen muss (ein Nachrichten-Feed, ein Fortschrittsbalken). Wählen Sie einen WebSocket, wenn Nachrichten in beide Richtungen fließen müssen, und SSE, wenn eine Richtung genügt.
Eine Anmerkung zur Infrastruktur
Weil ein WebSocket eine Verbindung offen hält, verändert er, wie Sie deployen. Langlebige Verbindungen brauchen einen Server und einen Reverse Proxy, die so konfiguriert sind, dass sie sie am Leben halten, statt sie per Timeout zu beenden, und das Skalieren vieler gleichzeitiger Verbindungen ist ein eigenes Designproblem. Das ist der Kompromiss: Ein WebSocket verschafft Ihnen sofortige, bidirektionale Kommunikation im Tausch dafür, dass auf dem Server ein Zustand offen gehalten wird.
Das Fazit
Ein WebSocket ist eine einzige, dauerhafte, bidirektionale Verbindung, über die Server und Browser Nachrichten in dem Moment austauschen, in dem sie eintreten — ohne den Frage-und-Warte-Rhythmus von HTTP. Er beginnt sein Leben als HTTP-Anfrage, die upgegradet wird, und befördert dann leichtgewichtige Frames in beide Richtungen. Nutzen Sie wss://, greifen Sie zu ihm, wenn der Server Live-Daten pushen muss, und bleiben Sie bei einer normalen HTTP-API, wenn eine einfache Anfrage und Antwort genügt.