Auch die Firewall einer Cloud-Instanz (Security Group) verfolgt Verbindungen, und Tracking-Einträge von Idle-Verbindungen laufen nach einer festen Zeit ab. Deshalb können auch Spieler, die ohne Load-Balancer direkt mit dem Server verbunden sind, nach einer Ruhephase die Verbindung verlieren.
Warum Security Group ist so konfiguriert, dass sie Spielverbindungen verfolgt (nur bestimmte Adressen erlaubt, eingeschränkte Ausgangsregeln, Weg über NLB usw.) → Folge Tracking-Eintrag einer länger inaktiven Verbindung läuft ab, danach eintreffende Pakete verwirft die Security Group stillschweigend → Auf dem Bildschirm Nach AFK keine Reaktion beim Weiterspielen, dann Verbindungsabbruch. Das Serverprogramm merkt lange nichts
Client: Heartbeats in höchstens halb so langen Abständen wie das kürzeste Idle-Timeout senden (bei 350 s für TCP höchstens alle 175 s, bei 180 s für UDP-Streams höchstens alle 90 s), bei Abbruch automatischer Reconnect. Server: auf Heartbeats antworten, Verbindungen von sich aus aufräumen, wenn eine Zeit lang keiner kommt, Session per Session-Token fortsetzen.
Aufgaben Infrastrukturteam
Connection-Tracking-Timeout der Instanz (TcpEstablishedTimeout) prüfen und bei Bedarf erhöhen (für UDP sind 180 s das Maximum), eine Security-Group-Konfiguration ohne Tracking prüfen (Spielport für alle Adressen öffnen, alle ausgehenden Verbindungen erlauben, Verbindungen über einen NLB werden trotzdem verfolgt), beim Umzug auf eine neue Instanzgeneration Idle-Tests fahren.
Größenordnungen
Bei AWS löschen Instanztypen mit Nitro v6 Tracking-Einträge inaktiver TCP-Verbindungen standardmäßig nach 350 s (andere Typen nach 5 Tagen). Für UDP gelten standardmäßig 180 s bei Flows mit mehreren Anfrage-Antwort-Wechseln (Stream) und 30 s bei Flows, die nur in eine Richtung liefen oder nur aus einer Anfrage und einer Antwort bestanden.
Im Graphen
Verbindungen brechen gleichzeitig ab · Verbindungsabbrüche, Idle-Zeit vor dem Abbruch
Wo nachsehen
Connection-Tracking-Timeout der Instanz und die Regeln der Security Group prüfen (entsteht überhaupt Tracking?), Idle-Zeiten abgebrochener Verbindungen sammeln. Direkt nach einem Abbruch auf dem Server mit ss -tnoi prüfen, ob die Verbindung noch als ESTABLISHED besteht, der Retransmission-Timer (timer:(on,…)) läuft und backoff wächst
Spricht dafür
Die Idle-Zeit abgebrochener Verbindungen häuft sich knapp über 350 s (TCP), 180 s (UDP-Stream) oder 30 s (UDP in eine Richtung), und der Socket auf dem Server bleibt als ESTABLISHED stehen, ohne den Abbruch zu bemerken (hat der Server Daten zu senden, wiederholt er nur Retransmissions)
Spricht dagegen
Security Group ohne Tracking konfiguriert (Spielport für alle Adressen offen, alle ausgehenden Verbindungen erlaubt, kein NLB): nicht diese Ursache. Läuft die Verbindung über einen NLB: Werte mit „Idle-Timeout des Load-Balancers“ vergleichen
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen
Amazon EC2 security group connection trackingAWS TCP-Idle-Tracking standardmäßig 350 s (Nitro v6, sonst 432.000 s = 5 Tage), UDP in eine Richtung 30 s, Stream 180 s (Maximum 180), bei Regeln, die alle Adressen erlauben, kein Tracking, Verbindungen über einen NLB werden immer verfolgt
ss(8) — Linux manual pageiproute2 timer:(on,…) bei -o ist der Retransmission-Timer, backoff bei -i gibt an, wie oft die Wartezeit für Retransmissions verdoppelt wurde
Verwandte Ursachen
Gleiche Schicht: L5 Netzwerkgeräte im Rechenzentrum