Was ist WebSocket? Echtzeitkommunikation einfach erklärt

Was ist WebSocket?

WebSocket ist ein Netzwerkprotokoll, mit dem Browser und Server eine einzige Verbindung offen halten und jederzeit in beide Richtungen Nachrichten austauschen. Sobald die Verbindung steht, kann jede Seite sofort senden. Sie müssen also nicht mehr für jede Information eine neue Anfrage starten.

Stellen Sie sich den Unterschied zwischen einem Brief und einem Telefonat vor. Bei HTTP schreiben Sie zum Beispiel einen Brief, die Gegenseite antwortet, und der Umschlag ist wieder zu. Bei WebSocket rufen Sie einmal an, und beide Seiten können sprechen, solange die Leitung offen bleibt.

Deshalb konzentriert sich dieser Artikel auf genau diesen einen Begriff. Wir erklären, wie die Verbindung beginnt, wofür sie sich eignet, wo sie an Grenzen stößt und wann Sie sie gar nicht brauchen. Zu Nachbarthemen verlinken wir kurz auf unsere anderen Leitfäden. Die Überschriften haben wir als Fragen formuliert, damit Einsteiger und erfahrene Entwickler direkt zum passenden Abschnitt springen können.

Was ist WebSocket, und warum reicht HTTP allein nicht aus?

Kurz gesagt arbeitet HTTP nach dem Prinzip Frage und Antwort. Zunächst sendet der Client eine Anfrage. Dann liefert der Server eine Antwort, und das Gespräch endet. Der Server kann dem Client nicht von sich aus mitteilen, dass etwas passiert ist, denn zuerst muss der Client fragen.

Für das Öffnen einer Seite, das Absenden eines Formulars oder das Laden einer Produktliste passt dieses Modell hervorragend. Allerdings stößt es bei Live Chat, sofortigen Benachrichtigungen oder Live Ergebnissen an Grenzen. Denn dort wissen Sie vorher nicht, wann sich die Daten ändern.

Deshalb füllten Entwickler diese Lücke jahrelang mit Polling. Dabei fragt der Client alle paar Sekunden, ob es etwas Neues gibt. Meistens lautet die Antwort „nein“, und jede Frage ist eine vollständige HTTP Anfrage.

Folglich entstehen unnötiger Datenverkehr und Verzögerung. Fragen Sie häufiger, sinkt die Latenz, aber die Serverlast steigt. Fragen Sie dagegen seltener, sinkt die Last, aber Nutzer warten. WebSocket löst genau dieses Dilemma: Der Server spricht in dem Moment, in dem er etwas zu sagen hat.

Wie beginnt eine WebSocket Verbindung: Was sind Handshake und Protokollwechsel?

Eine WebSocket Verbindung beginnt als gewöhnliche HTTP Anfrage. Der Browser sendet besondere Header, die dem Server mitteilen, dass er die Verbindung auf das WebSocket Protokoll umstellen möchte. Das heißt, diesen Schritt nennt man Handshake.

Stimmt der Server zu, antwortet er mit dem Statuscode „101 Switching Protocols“. Danach spricht dieselbe TCP Verbindung kein HTTP mehr, sondern transportiert WebSocket Frames. Außerdem beschreibt das Dokument RFC 6455 der IETF diesen Ablauf im Detail.

Konzeptionell läuft der Ablauf so:

1. Der Browser möchte sich mit einer Adresse verbinden, die mit ws oder wss beginnt.
2. Dann geht eine normale HTTP Anfrage hinaus, mit einer Umstellungsbitte und einem zufällig erzeugten Schlüssel.
3. Danach leitet der Server aus diesem Schlüssel einen Prüfwert ab und antwortet mit 101.
4. Schließlich prüft der Client den Wert und betrachtet die Verbindung als offen.
5. Danach senden beide Seiten ihre Nachrichten als Frames.

Der Start über HTTP ist also ein echter Vorteil. Bestehende Ports, Proxys und Infrastruktur kennen den Anfang des Austauschs, deshalb kommt WebSocket durch die meisten Netzwerke. Zudem beweist der Prüfwert, dass der Server wirklich WebSocket spricht. Ein beliebiger Webserver nimmt die Verbindung also nicht versehentlich an.

Was ist WebSocket nach dem Verbindungsaufbau: Wie fließen die Nachrichten?

Zunächst reisen die Daten nach dem Handshake in Frames. Ein Frame ist die kleinste Einheit der WebSocket Kommunikation. Eine Nachricht kann zum Beispiel in einen Frame passen oder in mehrere Teile zerfallen. So können Sie eine große Nachricht schon senden, bevor sie komplett vorliegt.

In der Praxis gibt es zwei Nachrichtentypen: Text und Binärdaten. Textnachrichten tragen dann meist Formate wie JSON. Binärnachrichten eignen sich dagegen für Audio, Bildausschnitte oder komprimierte Daten.

Das Protokoll kennt außerdem drei Arten von Kontrollframes:

• Ein Ping Frame prüft, ob die Gegenseite noch lebt.
• Ein Pong Frame ist die automatische Antwort auf einen Ping.
• Ein Close Frame beendet die Verbindung höflich und kann einen Grund enthalten.

Ping und Pong sind vor allem bei ruhigen Verbindungen nützlich. Ein Proxy oder eine Firewall in der Mitte kann eine Verbindung ohne Datenverkehr nach einer Weile stillschweigend kappen. Stattdessen verhindert ein regelmäßiger Ping das.

Welches Nachrichtenformat und welches Subprotokoll wählen Sie für WebSocket?

Zunächst ist WebSocket nur ein Transportkanal. Es legt nicht fest, was in einer Nachricht steht, also müssen Sie diese Lücke selbst füllen. Die meisten Teams wählen JSON als Text, weil es sich leicht lesen und prüfen lässt.

Beim Handshake können sich beide Seiten außerdem auf den Namen eines Subprotokolls einigen. Dabei nennt der Client die unterstützten Namen, und dann wählt der Server einen aus. Somit wissen beide von Anfang an, welche Nachrichtensprache auf diesem Kanal gilt.

Ein paar Gewohnheiten erleichtern den Entwurf der Nachrichten:

• Geben Sie jeder Nachricht einen Typ (zum Beispiel „Bestellung angelegt“) und eine Versionsnummer.
• Halten Sie den Nachrichtenkörper klein, denn dann senden Sie nur geänderte Felder.
• Prüfen Sie jede Client Nachricht auf dem Server gegen ein Schema.
• Ignorieren Sie unbekannte Nachrichtentypen still, damit ältere Clients mit neueren Servern weiterlaufen.

Ein strikter Nachrichtenvertrag zahlt sich vor allem aus, wenn Teams unterschiedlich schnell ausliefern.

Wofür nutzen Sie WebSocket in der Praxis?

WebSocket glänzt dort, wo Sie nicht wissen, wann Informationen eintreffen, und wo Verzögerung das Nutzererlebnis stört. Vor allem ist das gemeinsame Merkmal ein häufiger, unvorhersehbarer Datenfluss vom Server zum Client.

Typische Einsatzgebiete sind:

• Live Chat und Support Fenster, in denen eine Nachricht sofort ankommen muss.
• Sofortige Benachrichtigungen, bei denen neue Bestellungen, Freigaben oder Warnungen den Nutzer direkt erreichen.
• Live Ergebnisse und Verfolgungsansichten, in denen alle im selben Moment dieselben Daten sehen.
• Werkzeuge für die Zusammenarbeit, in denen mehrere Personen am selben Dokument oder Board arbeiten.
• Dashboards, in denen sich Bestand, Bestellungen oder Systemstatus ohne Aktualisieren ändern.
• Mehrspielerspiele und interaktive Live Übertragungen.

In jedem dieser Beispiele gibt es also Verkehr in beide Richtungen oder sehr häufige Updates. Rufen Sie Ihre Daten nur ein paar Mal am Tag ab, genügen oft einfachere Optionen, wie wir unten zeigen.

Was ist der Unterschied zwischen WebSocket, HTTP Polling, Long Polling und SSE?

Für Echtzeitkommunikation gibt es vier verbreitete Ansätze. Jeder setzt allerdings einen anderen Schwerpunkt. Fragen Sie deshalb nicht, welcher am besten ist, sondern welcher zu Ihrer Aufgabe passt.

Aus der Tabelle folgt: Richtung und Häufigkeit Ihres Bedarfs entscheiden. Brauchen Sie häufige Daten in beide Richtungen, ist WebSocket die richtige Wahl. Fließen Neuigkeiten dagegen nur vom Server, genügt häufig SSE.

Wann passt Server Sent Events besser als WebSocket?

Server Sent Events ist ein Datenstrom vom Server zum Client in nur eine Richtung. Browser nutzen ihn daher über die Schnittstelle EventSource. Laut MDN versucht der Browser selbst, die Verbindung wiederherzustellen, wenn sie abbricht. Dieses Verhalten bekommen Sie also fertig mit.

Denken Sie an einen Börsenticker, einen Nachrichtenstrom oder einen Fortschrittsbalken für eine lange Aufgabe. Hier sendet der Client selten Daten, deshalb hört er meist nur zu. Weil SSE über normales HTTP läuft, ist die Verträglichkeit mit Proxys und Firewalls meist unproblematisch.

Allerdings hat SSE Grenzen. Es fließt nur vom Server zum Client, daher brauchen Daten in Gegenrichtung eine eigene HTTP Anfrage. Außerdem transportiert es keine Binärdaten. Für Szenarien in beide Richtungen wie Chat, gemeinsames Bearbeiten oder Spiele ist WebSocket die natürlichere Wahl.

Kurz gesagt lautet die erste Frage: Spricht auch der Client häufig? Lautet die Antwort nein, prüfen Sie dann zuerst SSE. Lautet sie ja, wird die Frage, was ist WebSocket, für Sie zu einem echten Bedarf.

Beispielszenario: Wie funktioniert eine Live Bestelltafel mit WebSocket?

Zum Beispiel: Stellen Sie sich den Küchenbildschirm einer kleinen Restaurantkette vor. Das ist ein Beispielszenario und kein echter Kunde. Kellner erfassen Bestellungen auf einem Tablet, und der Küchenbildschirm muss jede Bestellung sofort zeigen.

Beim Polling fragt der Bildschirm nämlich alle paar Sekunden beim Server nach. Trifft eine Bestellung kurz nach einer Abfrage ein, wartet die Küche auf die nächste. Zur Stoßzeit fällt diese Wartezeit allerdings auf.

Mit WebSocket öffnet der Küchenbildschirm beim Start eine Verbindung und hält sie offen. Sendet ein Kellner eine Bestellung, schickt der Server sofort die Meldung „neue Bestellung“ an diese Verbindungen. Meldet die Küche „fertig“ zurück, zeigt das Tablet des Kellners es unmittelbar an.

Der Fluss in beide Richtungen ist hier entscheidend, denn auch aus der Küche muss eine Nachricht zum Kellner gelangen. Außerdem trägt derselbe Kanal Bestellung und Statuswechsel. Zudem weiß der Server, welcher Bildschirm verbunden ist, und kann einen ausgefallenen Bildschirm bemerken und das Personal warnen.

Auch in diesem Szenario schicken Sie nicht alles über WebSocket. Selten ändernde Daten wie die Speisekarte oder ein alter Bestellbericht bleiben über normales HTTP einfacher.

Welche Probleme entstehen beim Skalieren von WebSocket?

Erstens ist der größte Preis von WebSocket, dass Verbindungen lange offen bleiben. Zum Beispiel bearbeitet der Server bei klassischem HTTP eine Anfrage und gibt die Ressourcen sofort frei. Bei WebSocket belegt dagegen jeder verbundene Nutzer Speicher und einen Verbindungsplatz auf dem Server.

Deshalb müssen Sie zwei getrennte Lasten bedenken: die Nachrichtenrate und die Zahl gleichzeitiger Verbindungen. Folglich verbraucht ein System mit wenigen Nachrichten, aber vielen offenen Verbindungen andere Ressourcen.

Häufige Schwierigkeiten sind:

• Der Verbindungszustand lebt auf einem Server und verschwindet mit ihm.
• Der Server, mit dem ein Nutzer verbunden ist, kann ein anderer sein als der, der die Nachricht erzeugt.
• Ein langsamer Client kann die Warteschlange aufblähen und den Speicher des Servers belasten.
• Bei einem Update brechen alle Verbindungen gleichzeitig ab, und jeder Client versucht es zugleich erneut.

Der letzte Punkt verdient allerdings besondere Aufmerksamkeit. Eine Welle von Wiederverbindungen kann den Server mit den eigenen Nutzern überlasten. Planen Sie die Skalierung daher von Anfang an mit.

Wie wirken sich langsame Clients und Gegendruck auf einen WebSocket Server aus?

Erzeugt der Server Nachrichten schnell und verarbeitet der Client sie langsam, staut sich der Unterschied in einer Warteschlange. Anders gesagt heißt dieses Problem Gegendruck (Backpressure). MDN weist darauf hin, dass die Browser Schnittstelle für WebSocket keine Kontrolle über Gegendruck bietet.

Ignorieren Sie diesen Stau auf der Serverseite, dann füllt sich der Speicher langsam. Schon ein einzelner hängender Client kann nach einer Weile den ganzen Prozess belasten. Legen Sie deshalb für jede Verbindung eine Pufferobergrenze fest.

Diese Maßnahmen helfen:

• Setzen Sie für die Warteschlange jeder Verbindung eine Obergrenze.
• Verwerfen Sie bei Erreichen der Grenze alte Zwischenwerte, denn bei Live Ergebnissen zählt nur der letzte Wert.
• Schließen Sie eine Verbindung, die dauerhaft sehr langsam bleibt, und lassen Sie den Client neu verbinden.
• Fassen Sie häufige Änderungen zusammen und senden Sie sie seltener.

Welche Nachrichten Sie verwerfen dürfen und welche unbedingt ankommen müssen, entscheiden Ihre Geschäftsregeln. Wenn Sie das früh klären, vereinfacht sich der Entwurf somit deutlich.

Was leisten Load Balancer und Message Broker in einer WebSocket Architektur?

Zunächst verteilt ein Load Balancer eingehende Verbindungen auf mehrere Server. Bei WebSocket müssen Sie darauf achten, dass er die Umstellungsanfrage und langlebige Verbindungen unterstützt. Ist sein Zeitlimit für Leerlauf zu kurz, brechen Verbindungen daher unerwartet ab. Den Grundgedanken haben wir in unserem Leitfaden zum Load Balancer erklärt.

Auch jede Schicht in der Mitte des Netzwerks kann eine Verbindung beeinflussen. Reverse Proxys, Content Delivery Netzwerke und Firewalls sind zum Beispiel womöglich nicht auf langlebige Verbindungen eingestellt. Haben Sie Probleme, prüfen Sie zuerst die Schichten auf dem Weg und nicht die Anwendung.

Das zweite Problem ist die Kommunikation zwischen Servern. Wie gelangt die Nachricht eines Nutzers auf Server A zu einem Nutzer auf Server B? In der Praxis ist die übliche Antwort ein Message Broker.

Ein Broker bietet ein Muster aus Veröffentlichen und Abonnieren. Dazu abonniert jeder WebSocket Server den Broker. Kommt eine Nachricht an, verteilt der Broker sie an alle betroffenen Server, und jeder Server gibt sie an seine eigenen Clients weiter.

Dieses Muster ist übrigens eine kleine Anwendung ereignisgesteuerter Architektur. Das ganze Konzept lesen Sie in unserem Artikel zur Event Driven Architecture. Bei der Planung, welche Komponente welche Verbindung hält, hilft zudem unser Leitfaden zur Microservices Architektur.

Was ist WebSocket Sicherheit: Worin unterscheiden sich ws und wss?

Erstens steht das Schema ws für eine ungeschützte WebSocket Verbindung. Zweitens schützen Sie das Schema wss mit TLS, genau wie bei http und https. Deshalb empfehlen wir wss in jeder Live Umgebung.

Denn bei einer unverschlüsselten Verbindung kann jemand in der Mitte Nachrichten lesen oder ändern. Außerdem stören manche Proxys unverschlüsselten WebSocket Verkehr. Eine verschlüsselte Verbindung mindert diese Probleme dagegen deutlich.

Ob Ihr Zertifikat gültig und die Kette vollständig ist, prüfen Sie mit unserem SSL Check. Wird eine Seite über https geladen, blockieren Browser meist auch eine unverschlüsselte ws Verbindung, wegen der Regel zu gemischten Inhalten.

Denken Sie daran: wss schützt nur die Transportschicht, also nicht mehr. Fragen wie, wer sich verbinden darf und welche Nachrichten er senden darf, brauchen einen eigenen Entwurf auf Anwendungsebene.

Warum braucht eine WebSocket Verbindung eine Prüfung der Herkunft?

Startet ein Browser einen WebSocket Handshake, fügt er einen Header namens Origin hinzu, der die Herkunftsseite der Anfrage nennt. Konkret sagt RFC 6455, dass ein Server diesen Header lesen und nicht akzeptierte Herkünfte ablehnen kann.

Warum ist das wichtig? Weil WebSocket nicht in der gewohnten Weise der Same Origin Policy des Browsers folgt. Deshalb kann eine Seite auf einer anderen Website versuchen, aus dem Browser des Besuchers eine Verbindung zu Ihrem Server aufzubauen. Hängt die Anmeldung allein an einem Cookie, lässt sich die Sitzung des Besuchers ohne dessen Wissen nutzen. Wir nennen dieses Risiko daher Cross Site WebSocket Hijacking.

Die Abwehr ist einfach:

• Führen Sie eine ausdrückliche Liste erlaubter Herkünfte.
• Dann lehnen Sie jeden Handshake von einer Herkunft ab, die nicht auf der Liste steht.
• Nutzen Sie Cookie Sitzungen, verlangen Sie zusätzlich einen Prüfwert.

Der Origin Header ist für Browser verlässlich, aber ein Client außerhalb des Browsers kann beliebige Werte eintragen. Er reicht daher allein nicht aus. Betrachten Sie ihn deshalb gemeinsam mit der Authentifizierung.

Wie richten Sie die Authentifizierung für eine WebSocket Verbindung ein?

Die WebSocket Schnittstelle im Browser erlaubt es nicht, beim Handshake eigene Header wie Authorization zu senden. Folglich prägt diese Einschränkung Ihren Entwurf für die Anmeldung. Ebenso verweist die MDN Dokumentation auf diese Grenze.

Verbreitete Ansätze sind:

• Sich auf das Sitzungscookie derselben Domain verlassen und es mit einer Herkunftsprüfung absichern.
• Zuerst über einen normalen HTTP Aufruf ein kurzlebiges Ticket für die einmalige Nutzung holen und es beim Verbinden vorlegen.
• Sich in der ersten Nachricht nach dem Öffnen anmelden und jede Verbindung schließen, die dabei scheitert.

Nutzen Sie Token, schreiben Sie keinen langlebigen Schlüssel in die Adresse, weil Adressen in Protokollen und Proxy Aufzeichnungen bleiben können. Aufbau und Signaturlogik von Token haben wir in unserem JWT Leitfaden auf konzeptioneller Ebene erklärt.

Die Autorisierung ist dagegen ein eigener Schritt. Nur weil eine Verbindung offen ist, darf sie nicht jeden Kanal abonnieren. Fragen Sie bei jedem Abonnement erneut auf dem Server, ob dieser Nutzer diesen Kanal sehen darf.

Wie entwerfen Sie die Wiederverbindung, wenn die Verbindung abbricht?

Zunächst gilt: Echte Netzwerke brechen ab. Ein Handy fährt in einen Tunnel, ein Nutzer wechselt vom WLAN ins Mobilfunknetz, ein Server startet neu. Anders als SSE verbindet sich die WebSocket Schnittstelle im Browser nicht von selbst neu, also müssen Sie diese Logik schreiben.

Ein gutes Konzept für die Wiederverbindung hat mehrere Teile:

1. Verlängern Sie die Wartezeit nach jedem Versuch, was man exponentielles Backoff nennt.
2. Dann fügen Sie eine kleine Zufallsverzögerung hinzu, damit nicht alle Clients im selben Moment zurückkehren.
3. Legen Sie fest, wie Sie verpasste Nachrichten nach der Wiederverbindung holen, zum Beispiel über die zuletzt gesehene Nachrichtennummer.
4. Schließlich zeigen Sie dem Nutzer den Verbindungsstatus ehrlich an.

Allerdings übergehen viele Teams das Problem verpasster Nachrichten. WebSocket verspricht keine Zustellung, daher kann eine Nachricht verloren gehen, wenn die Verbindung abriss. Bei wichtigen Daten sollten Sie auf dem Server einen dauerhaften Eintrag halten, damit der Client dort weitermachen kann, wo er aufgehört hat.

Wie überwachen und messen Sie WebSocket Verbindungen?

Offene Verbindungen sind unsichtbar, deshalb fallen Probleme spät auf. Aus diesem Grund ist Überwachung bei WebSocket Systemen noch wichtiger als bei einer gewöhnlichen API. In der Praxis zeigen einige Grundmessungen die meisten Probleme früh.

• Aktuelle Zahl offener Verbindungen: Plötzliche Einbrüche deuten auf Massenabbrüche, stetiges Wachstum auf ein Leck.
• Verbindungen und Abbrüche pro Sekunde, denn sie zeigen Wellen von Wiederverbindungen.
• Gründe für das Schließen, weil ein Netzwerkabbruch etwas anderes ist als eine Entscheidung des Servers.
• Latenz der Nachrichten, also die Zeit zwischen Erzeugung und Ankunft beim Client.
• Länge der Warteschlange pro Verbindung, denn sie macht langsame Clients sichtbar.

Möchten Sie diese Messwerte mit Logs, Metriken und Traces verbinden, hilft der Ansatz in unserem Artikel zu Observability. Die Grundlagen der Netzwerklatenz finden Sie außerdem in unserem Leitfaden zu Ping und Latenz.

Können Sie WebSocket auch außerhalb des Browsers nutzen?

Ja. RFC 6455 sagt, dass das Protokoll für Skripte in Webseiten entworfen wurde, aber jeder Client es sprechen kann. Mobile Apps, Desktop Programme und Verbindungen von Server zu Server sind zum Beispiel möglich.

Zum Beispiel kann eine mobile App eine offene WebSocket Verbindung halten, um eine eingehende Nachricht sofort zu zeigen. Ein Überwachungsdienst kann auf diesem Weg den Ereignisstrom eines anderen Dienstes mithören. Somit nutzen auch Clients außerhalb des Browsers dasselbe Nachrichtenmodell.

Es gibt allerdings einen Unterschied. Bei Clients außerhalb des Browsers ist der Origin Header keine verlässliche Identität, weil der Client ihn frei schreiben kann. Dafür dürfen diese Clients eigene Header senden, sodass Sie die Anmeldung über Header aufbauen können. Bedenken Sie daher das Bedrohungsmodell für jeden Clienttyp getrennt.

Auf dem Handy wechselt das Netz häufig, deshalb wird die Logik zur Wiederverbindung noch wichtiger. Vergessen Sie auch den Akkuverbrauch nicht, denn eine dauerhaft offene Verbindung kann für eine selten genutzte App überflüssig sein.

Wie leiten Kanäle und Räume WebSocket Nachrichten weiter?

Zunächst weiß das WebSocket Protokoll nicht, für wen eine Nachricht bestimmt ist. Daten, die Sie auf eine Verbindung schreiben, gehen nur an diese Verbindung. Regeln wie „diese Bestellung nur an die Bildschirme dieser Filiale“ bauen Sie selbst in der Anwendungsschicht.

Dafür nutzen Sie die Idee von Kanälen oder Räumen, denn so bleibt die Logik einfach. Jede Verbindung abonniert die Kanäle, die sie interessieren. Eine Filialnummer, ein Chatraum oder eine Dokumentkennung kann ein Kanalname sein. Schreiben Sie eine Nachricht in einen Kanal, liefert der Server sie nur an dessen Abonnenten.

Dieser Ansatz hat drei Vorteile:

• Nutzer erhalten nur relevante Daten, deshalb sinkt die Netzwerklast.
• Die Berechtigungsprüfung geschieht an einer Stelle, zu Beginn des Abonnements.
• In Kombination mit einem Message Broker wird der Kanalname zum Schlüssel für die Verteilung zwischen Servern.

Schwer erratbare Kanalnamen sorgen allerdings allein nicht für Sicherheit. Führen Sie die Berechtigungsprüfung daher immer auf dem Server aus.

Wie testen Sie eine Echtzeitfunktion?

Ein Chat, der mit ein paar Tabs auf Ihrem Rechner funktioniert, verhält sich in der Produktion womöglich anders. Bringen Sie Ihre Tests daher näher an reale Bedingungen. Die bloße Frage, ob die Nachricht ankam, reicht also nicht.

Nehmen Sie diese Szenarien in Ihren Plan auf:

1. Trennen Sie die Verbindung absichtlich und prüfen Sie, ob der Client neu verbindet und verpasste Nachrichten erhält.
2. Dann verbinden Sie viele Clients gleichzeitig und beobachten Sie Speicher und Prozessor des Servers.
3. Simulieren Sie ein langsames Netz und bestätigen Sie, dass die Grenze der Warteschlange greift.
4. Danach starten Sie den Server neu und prüfen Sie, ob alle Clients nach und nach zurückkehren.
5. Versuchen Sie, einen nicht berechtigten Nutzer auf einen fremden Kanal zu abonnieren.

Führen Sie diese Versuche zunächst vor dem Livegang in einer eigenen Testumgebung aus. Ihrem Team zu erklären, was ist WebSocket, fällt leicht, doch das Verhalten sehen Sie erst in Tests. Notieren Sie außerdem die Ergebnisse, denn so haben Sie für spätere Entscheidungen zur Skalierung konkrete Daten.

Wann ist WebSocket überflüssig?

Nicht jeder Bedarf, der nach Echtzeit aussieht, verlangt allerdings WebSocket. Fragen Sie sich, bevor Sie Ihre Infrastruktur verkomplizieren, ob sich die Daten wirklich binnen Sekunden ändern müssen und ob Nutzer es merken würden.

Einfachere Lösungen genügen oft in diesen Fällen:

• Ändern sich Daten höchstens einmal pro Minute, reicht regelmäßiges Polling.
• Fließen Daten dagegen nur vom Server zum Client, kann SSE leichter sein.
• Aktualisieren Nutzer die Seite ohnehin oft, ist ein zusätzlicher Kanal sinnlos.
• Für Inhalte, die Sie zwischenspeichern können und die für alle gleich aussehen, ist klassisches HTTP günstiger.

Zur Logik des Zwischenspeicherns lesen Sie unseren Leitfaden zum Caching. Außerdem ist es auf serverlosen Plattformen schwer, langlebige Verbindungen zu halten, Details finden Sie in unserem Artikel zu Serverless.

Kurz gesagt ist einfach oft robuster. Ein WebSocket ohne klaren Grund bringt nur Wartungsaufwand.

Welche Fehler passieren bei WebSocket Projekten am häufigsten?

Die häufigsten Fehler von Teams sind Entwurfsfehler, keine technischen. Wenn Sie einige davon kennen, haben Sie somit einen guten Startpunkt.

• Alles über WebSocket schicken. Anmeldung und Datei Upload laufen über normales HTTP bequemer.
• Kein Schema und keine Version in den Nachrichten. Bewegen sich Client und Server unterschiedlich schnell, verlieren alte Nachrichten ihren Sinn.
• Die Zahl der Verbindungen nicht beobachten. Offene Verbindungen häufen sich still und stoßen eines Tages an eine Grenze.
• Jedes Ereignis an alle senden. Schicken Sie einem Nutzer nur die Nachrichten des passenden Kanals.
• Fehler und Schließgründe nicht festhalten. Kennen Sie die Ursache der Abbrüche nicht, können Sie nichts verbessern.
• Der Client Eingabe vertrauen. Prüfen Sie jede eingehende Nachricht auf dem Server.

Teams, die die Frage, was ist WebSocket, nur oberflächlich beantworten, halten es für einen magischen Geschwindigkeitsknopf. Das ist also die gemeinsame Wurzel dieser Fehler. In Wahrheit bleiben Verbindungsverwaltung, Sicherheit und Skalierung Ihre Verantwortung.

Was ist WebSocket Planung als Checkliste?

Die folgende Liste sammelt Fragen, die Sie bei der Planung einer Echtzeitfunktion stellen können. Sie müssen allerdings nicht alle mit Ja beantworten. Ziel ist es, den übersehenen Punkt zu finden.

• Fließen die Daten in beide Richtungen oder nur vom Server?
• Kommen Updates im Sekundenbereich?
• Setzen Sie in der Produktion wss ein?
• Prüft der Server eine Liste erlaubter Herkünfte?
• Sind Authentifizierung und Kanalberechtigung festgelegt?
• Gibt es Logik für Wiederverbindung und verpasste Nachrichten?
• Unterstützt der Load Balancer Umstellungsanfragen und lange Verbindungen?
• Haben Sie bei mehreren Servern einen Message Broker eingeplant?
• Messen Sie Verbindungszahl, Abbrüche und Latenz?
• Führen Sie für wichtige Daten einen dauerhaften Eintrag?

Füllen Sie diese Liste gemeinsam mit Ihrem Team in einem Termin aus. Dabei kommen dann oft versteckte Annahmen ans Licht.

Wie unterstützt Sie unser Team bei einer WebSocket Funktion?

Planen Sie eine Funktion wie Live Benachrichtigungen, Chat oder ein Dashboard, klären wir zunächst gemeinsam mit Ihnen, ob Sie WebSocket wirklich brauchen. Manchmal genügt zum Beispiel eine einfache Lösung. In anderen Fällen spart eine von Anfang an richtige Architektur später viel Zeit.

Wie wir bei individueller Software arbeiten, beschreiben wir auf unserer Seite zur individuellen Softwareentwicklung. Für Sicherheitsdetails ergänzt unser Leitfaden zu den OWASP Sicherheitslücken diesen Artikel gut.

Außerdem sind die Angaben in diesem Artikel allgemein. Prüfen Sie für Entscheidungen zu Ihrer eigenen Infrastruktur die aktuelle Dokumentation und führen Sie echte Lasttests durch.

Quellen: das IETF Dokument RFC 6455 für das Protokoll selbst, die MDN Seite zur WebSockets API für die Browser Schnittstelle, die MDN Anleitung zum Schreiben von WebSocket Servern und die MDN Seite zu Server Sent Events.