Erschöpfte ephemere Ports bei Verbindungen zwischen Servern Ephemeral port exhaustion (TIME_WAIT)

Ursachen-ID so-ports · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)

In der interaktiven Fassung mit Grafiken und Experimenten öffnen →

Baut der Spielserver Verbindungen zur DB oder zu anderen Servern häufig nur kurz auf und wieder ab, belegen beendete Verbindungen ihren Port noch eine Weile, und neue Verbindungen lassen sich nicht mehr öffnen.

Warum Für jede Anfrage wird eine neue Verbindung geöffnet und geschlossen → Folge Die zuerst schließende Seite hält den Port etwa 60 s lang (Linux) im Zustand TIME_WAIT, freie Ports gehen aus → Auf dem Bildschirm Interne Anfragen scheitern: Speichern schlägt fehl, Funktionen melden Fehler

Symptome: Verschluckte Aktion / Rollback, Kein Login / Endlos-Laden
Faktoren: Paketverlust
Wer ist betroffen: Ganzer Server, Nur eine bestimmte Funktion
Wann: Bei großem Andrang
Zuständigkeit: Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Aufgaben Entwicklungsteam: Verbindungen wiederverwenden (Connection-Pool), nicht für jede Anfrage eine neue Verbindung öffnen und schließen.
Aufgaben Infrastrukturteam: Portbereich erweitern (ip_local_port_range), Wiederverwendung von TIME_WAIT bei ausgehenden Verbindungen prüfen (tcp_tw_reuse unter Linux), Zahl der TIME_WAIT-Sockets überwachen.
Größenordnungen: Der Standard-Portbereich von Linux (32768–60999) umfasst etwa 28.000 Ports. Bei mehr als 470 neuen Verbindungen pro Sekunde zur selben Zieladresse ist er erschöpft. Windows hat standardmäßig etwa 16.000 Ports (49152–65535) und ein längeres TIME_WAIT, dort gehen die Ports also noch schneller aus.
Im Graphen: Plateau am Limit · TIME_WAIT-Sockets, gescheiterte interne Verbindungen
Wo nachsehen: Mit ss -tan state time-wait die TIME_WAIT-Sockets pro Zieladresse zählen, im Spielserver-Log nach connect-Fehlern (EADDRNOTAVAIL) suchen
Spricht dafür: TIME_WAIT zum selben Ziel (DB o. Ä.) bildet nahe der Größe des ephemeren Portbereichs (standardmäßig ca. 28.000) ein Plateau, und connect scheitert mit EADDRNOTAVAIL
Spricht dagegen: Wenig TIME_WAIT, aber nur Verbindungen nach außen scheitern: „Verbindungs- und Portlimits des Cloud-NAT-Gateways“
Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu: Die 60 s für TIME_WAIT sind unter Linux fest im Kernel verankert. Wer das ähnlich benannte tcp_fin_timeout senkt, verkürzt TIME_WAIT damit nicht.

Quellen

IP Sysctl Linux kernel
ip_local_port_range standardmäßig 32768–60999, tcp_tw_reuse, tcp_fin_timeout ist die Verweildauer im Zustand FIN_WAIT_2
include/net/tcp.h (Linux v6.12) Linux kernel
TCP_TIMEWAIT_LEN (60*HZ): Die ca. 60 s TIME_WAIT sind eine Kernel-Konstante
TCP/IP port exhaustion troubleshooting Microsoft
Dynamische Ports unter Windows standardmäßig 49152–65535, geschlossene Verbindungen halten ihren Port standardmäßig 4 Minuten im Zustand TIME_WAIT
ss(8) — Linux manual page iproute2
Mit dem Statusfilter state time-wait nur TIME_WAIT-Sockets anzeigen
connect(2) — Linux manual page Linux man-pages
EADDRNOTAVAIL: Alle Ports des ephemeren Portbereichs sind belegt, deshalb lässt sich keine Verbindung öffnen

Erschöpfte ephemere Ports bei Verbindungen zwischen Servern Ephemeral port exhaustion (TIME_WAIT)

Quellen

Verwandte Ursachen

Gleiche Schicht: L7 Server-OS (Kernel)

Ursachen aus anderen Schichten mit demselben Symptom (Verschluckte Aktion / Rollback)