Löscht ein Zwischengerät das Mapping einer Idle-Verbindung (den Eintrag, wohin diese Verbindung weitergeleitet wird), kommt das nächste gesendete Paket nicht mehr an. Entweder folgen Retransmissions, bis die Verbindung abbricht, oder das Gerät schickt eine Verbindungsablehnung (RST) zurück, und die Verbindung bricht sofort ab.
Warum Verbindung, über die eine Weile keine Pakete laufen (AFK, Lobby) → Folge NAT im Router, CGNAT des Providers, Firewall, Load-Balancer oder Cloud-Security-Group löscht das Idle-Mapping → Auf dem Bildschirm Bei der nächsten Bewegung folgen Retransmissions, dann Verbindungsabbruch, oder sofort Verbindungsabbruch
Client: Heartbeats in höchstens halb so langen Abständen wie das kürzeste Idle-Timeout senden (Mappings im Router des Spielers und im CGNAT des Providers werden nur durch ausgehende Pakete zuverlässig erneuert, und deren Timeouts können wir nicht ändern, daher sendet der Client), bei Abbruch automatischer Reconnect. Server: auf Heartbeats antworten und Verbindungen nach einer festen Zeit ohne Empfang selbst aufräumen (TCP-Keepalive-Intervall über Socket-Optionen wie TCP_KEEPIDLE verkürzen, mit TCP_USER_TIMEOUT schnell erkennen), Session per Session-Token fortsetzen.
Aufgaben Infrastrukturteam
Netzwerk: Idle-Timeouts der Firewalls und Load-Balancer auf der Strecke sammeln und mit dem Entwicklungsteam teilen, eigene Firewalls und Load-Balancer bei Bedarf hochsetzen. Server/OS: Tracking-Dauer der Cloud-Security-Groups prüfen und mit dem Entwicklungsteam teilen.
Größenordnungen
Wie lange ein TCP-Mapping erhalten bleibt, ist je nach Gerät sehr unterschiedlich, von einigen Minuten bis zu mehreren Stunden. Verfolgt eine Cloud-Security-Group Verbindungen, löschen AWS-Instanztypen mit Nitro v6 den Tracking-Eintrag standardmäßig nach 350 s (andere Typen nach 5 Tagen, siehe „Ablauf des Connection Trackings in Cloud-Security-Groups“). Der Standardwert von TCP-Keepalive unter Linux lautet „nach 2 Stunden Leerlauf prüfen“ und liegt damit über den Timeouts der meisten Geräte.
Im Graphen
Verbindungen brechen gleichzeitig ab · Verbindungsabbrüche, Idle-Zeit vor dem Abbruch
Wo nachsehen
Die letzten Minuten abgebrochener Verbindungen per Paketmitschnitt auf dem Server prüfen, bei bestehenden Verbindungen die Idle-Zeit über lastsnd und lastrcv in ss -ti ansehen (ms seit dem letzten Senden bzw. Empfangen). Dazu TcpExtTCPAbortOnTimeout in nstat (Verbindungen, die nach Ablauf des Timers aufgegeben wurden)
Spricht dafür
Bei jeder abgebrochenen Verbindung lag die vorangehende Idle-Zeit über einem ähnlichen Wert (dem Idle-Timeout eines Geräts auf der Strecke, z. B. 350 s bei Security Groups von AWS-Nitro-v6-Instanzen), ab dem ersten Paket nach dem Leerlauf folgen nur Retransmissions ohne ACK bis zur Aufgabe, oder es kommt sofort ein RST zurück
Spricht dagegen
Abbrüche auch mitten im Spiel, unabhängig von der Idle-Zeit: andere Ursache („Routenwechsel oder defekter ECMP-Pfad“, „Verworfene Pakete in Firewall und Connection Tracking“). Laufen auf der Verbindung Heartbeats in höchstens halb so langen Abständen wie das kürzeste Idle-Timeout, scheidet diese Ursache aus
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen
RFC 5382: NAT Behavioral Requirements for TCPIETF Empfehlung: Das Idle-Timeout von TCP-NATs soll mindestens 2 Stunden 4 Minuten betragen (in der Annahme, dass Geräte Idle-Sessions auch früher löschen können)
Amazon EC2 security group connection trackingAWS Standard-Timeout für das Tracking von Idle-TCP-Verbindungen: 350 s bei Nitro-v6-Instanztypen, 432.000 s (5 Tage) bei anderen Typen. Empfehlung für Keepalive in Abständen unter 5 Minuten
IP SysctlLinux kernel tcp_keepalive_time standardmäßig 2 Stunden
tcp(7) — Linux manual pageLinux man-pages TCP_KEEPIDLE (Idle-Zeit vor dem Start von Keepalive), TCP_USER_TIMEOUT (wie lange auf unbestätigte Daten gewartet wird, bevor die Verbindung geschlossen wird)
RFC 5482: TCP User Timeout OptionIETF TCP User Timeout: nach welcher Zeit ohne Bestätigung gesendeter Daten die Verbindung geschlossen wird
ss(8) — Linux manual pageiproute2 lastsnd und lastrcv bei ss -i: Zeit seit dem letzten Senden bzw. Empfangen (ms)
SNMP counterLinux kernel TcpExtTCPAbortOnTimeout: Zahl der Verbindungen, die nach Ablauf eines TCP-Timers ohne RST aufgegeben wurden
Verwandte Ursachen
Gleiche Schicht: Grundursachen von TCP-Retransmissions