WebSocket: Hosting in Echtzeit ohne ermüdende Verbindungen

Ein in Node.js bereitgestellter Support-Chat funktioniert im Staging perfekt: zwanzig Tester, sofortige Latenz. In der Produktion auf demselben VPS sind 300 Agenten verbunden – der Server meldet „zu viele offene Dateien“, Nginx gibt 502 zurück und die Verbindungen werden alle 60 Sekunden unterbrochen, weil niemand den standardmäßigen „proxy_read_timeout“ bemerkt hat.

WebSocket ist kein bisschen länger als HTTP. Es handelt sich um ein anderes Ressourcenmodell: dauerhafte Verbindungen, Speicher pro Client, Heartbeats und häufig Broadcasting, das jede Nachricht verstärkt. Hosting in Echtzeit ohne Plan bedeutet, dass ein Produkterfolg in einen vorhersehbaren Infrastrukturvorfall umgewandelt wird.

WebSocket versus HTTP: Was eine Verbindung wirklich verbraucht

Faustregel: Schätzen Sie 50 KB bis 200 KB Speicher pro Verbindung, abhängig vom Stack (Knoten, GB, Elixir variieren). 5.000 Verbindungen × 100 KB ≈ 500 MB – vor Geschäftscode.

Die Zahl, die zuerst tötet, ist nicht die CPU, sondern ulimit -n und das Proxy-Timeout.

Reverse-Proxy: Nginx vor der Echtzeitanwendung

Minimale Nginx-Konfiguration:

„Nginx Standort /ws/ { Proxy_Pass http://127.0.0.1:3000; Proxy_http_version 1.1; Proxy_set_header Upgrade $http_upgrade; Proxy_set_header Verbindung „upgrade“; Proxy_set_header Host $host; Proxy_read_timeout 3600s; Proxy_send_timeout 3600s; }

Oft vergessene Punkte: das globale Limit **`worker_connections`** Nginx- versus WebSocket-Verbindungen; **TLS-Terminierung** am Proxy – einige Hosts schränken gleichzeitige SSL-Verbindungen ein; **HTTP/2** auf der öffentlichen Clientseite, **HTTP/1.1-Upgrade** im Upstream.



Siehe auch [WebSocket-Timeout-Proxy](/de/blog/websocket-timeout-proxy/) und [Nginx oder Apache](/de/blog/nginx-ou-apache/).



:::Hinweis

**Denken Sie daran.** Ein Proxy-Timeout von 60 Sekunden verwandelt Ihre „Echtzeit“ in dauerhafte Wiederverbindungen – unsichtbar in der Demo, katastrophal in der Produktion.

:::



## Horizontale Skalierung: Affinität versus Broker



**Option A – Sticky Sessions.** Der Load Balancer leitet den Client an denselben Knoten weiter. Einfach, zerbrechlich, wenn der Knoten fällt (massive Wiederverbindung).



**Option B – Redis Pub/Sub- oder Socket.IO-Adapter.** Nachrichten werden zwischen Knoten weitergeleitet; Verteilte Verbindungen. Erforderlich ab zwei oder mehr Instanzen.



**Option C – Managed Service** (Pusher, Ably, verwalteter Mercure-Hub). Komplexität auslagern; Kosten pro Nachricht.



Für einen ernsthaften MVP ist Option B auf zwei kleinen VPS besser als ein einzelner großer Server ohne Pub/Sub.



## Hosting: Fragen an den Anbieter



Erkundigen Sie sich vor der Auswahl, ob lange Verbindungen zulässig sind (gemeinsam genutzte Verbindungen werden häufig unterbrochen), wie hoch die Dateideskriptorbeschränkung ist, ob UDP oder QUIC für WebTransport gefiltert werden, ob der Layer 7-Lastausgleichsdienst das WebSocket-Upgrade unterstützt und ob Anti-DDoS langsame Verbindungen fälschlicherweise blockieren kann.



Cloud VPS (Hetzner, OVH, Scaleway) mit Nginx bleibt die vorhersehbarste Kombination für selbst gehostetes WebSocket.



## Herzschläge, Wiederverbindung und Beobachtbarkeit



Senden Sie alle 30 Sekunden einen Anwendungs-Ping/Pong, um unterbrochene Verbindungen zu erkennen. Wenden Sie auf der Clientseite einen exponentiellen Backoff an, um einen Ansturm des Servers beim Neustart zu vermeiden. Messen Sie aktive Verbindungen, Nachrichten pro Sekunde und die Zustellungslatenz im 99. Perzentil. Planen Sie einen eleganten Stopp ein: Stoppsignal, Stopp akzeptieren, 30 Sekunden ablassen.



## Der Gipfel: Echtzeit skaliert in Verbindungen, nicht in Seitenaufrufen



:::Höhepunkt

**Analytics zählt Seitenaufrufe; WebSocket zählt die um 3 Uhr morgens geöffneten Sockets.** Eine „bescheidene“ Spitze von 2.000 gleichzeitigen Benutzern kann Deskriptoren und Speicher erschöpfen, während HTTP-Verkehr vom selben Dienst auf einer gemeinsam genutzten Site unbemerkt bleiben würde.

:::



Der Verkauf von „Live-Chat“ ohne maximale Verbindungszahlen, Proxy-Timeout und Pub/Sub-Plan bedeutet, eine Funktion zu verkaufen, die **den ersten Erfolg nicht überlebt**.



## Entscheide dich und gehe ohne blinden Fleck voran



Berechnen Sie zunächst die maximale Anzahl an Verbindungen × Speicher und überprüfen Sie „ulimit“. Konfigurieren Sie Nginx-Timeouts vor dem Start. Testen Sie die Wiederverbindung nach der Bereitstellung – nicht nur die nominelle Reise. Planen Sie Redis Pub/Sub vor dem zweiten Server. Richten Sie ein Dashboard aktiver Verbindungen mit einer Warnung bei 80 % des Schwellenwerts ein.



Entdecken Sie VPS und Cloud im [Verzeichnis](/de/verzeichnis/) und im [Vergleich](/de/vergleich/).



## Häufig gestellte Fragen



### Wie viele WebSocket-Verbindungen kann ein Server aufnehmen?



Es hängt vom Speicher pro Verbindung, den Dateideskriptoren und Nginx ab. Tausende von Leerlaufverbindungen sind möglich; umso weniger, wenn jede Nachricht schwere Arbeit auslöst.



### Benötigen Sie eine Sticky Session hinter einem Load Balancer?



Ja, wenn der Zustand im Prozessspeicher liegt. Andernfalls verwenden Sie Redis Pub/Sub oder einen dedizierten Hub, um den Status zwischen Knoten zu teilen.



### Unterstützt Shared WebSocket?



Oft teilweise oder mit kurzen Auszeiten (30 bis 60 Sekunden). Überprüfen Sie die Dokumentation des Hosting-Anbieters – einige Panels unterbrechen lange Verbindungen.



### Nginx oder Apache vor Node.js WebSocket?



Nginx ist häufiger mit Upgrade-Headern und angepasstem „proxy_read_timeout“ (oft 3600 Sekunden oder mehr). Apache mod_proxy_wstunnel funktioniert, ist jedoch in der Echtzeitproduktion weniger verbreitet.



---



Die Echtzeit wird in offenen Verbindungen gemessen – nicht in einzelnen Besuchern des letzten Monats.