Idle-Timeout des Load-Balancers Load balancer idle timeout

Ursachen-ID dc-lb-idle · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Client-Entwicklung (Entwicklungsteam), Server-Entwicklung (Entwicklungsteam)

In der interaktiven Fassung mit Grafiken und Experimenten öffnen →

Load-Balancer löschen Idle-Verbindungen nach einer bestimmten Zeit. Das Spiel hält die Verbindung weiter für bestehend, bis es zum Verbindungsabbruch kommt.

Warum Spieler sendet eine Weile kein einziges Paket (Chatfenster, AFK) → Folge Load-Balancer räumt die Idle-Verbindung ab (übliche Standardwerte 60–350 s) → Auf dem Bildschirm Verbindungsabbruch, sobald sich der Spieler wieder bewegt

Symptome: Verbindungsabbruch
Faktoren: Paketverlust
Wer ist betroffen: Nur ich, Ganzer Server
Wann: Nach Inaktivität
Zuständigkeit: Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Client-Entwicklung (Entwicklungsteam), Server-Entwicklung (Entwicklungsteam)
Aufgaben Entwicklungsteam: Client: Heartbeats in höchstens halb so langen Abständen wie das kürzeste Idle-Timeout senden (hinter einem ALB mit 60 s also höchstens alle 30 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: Idle-Timeouts der Load-Balancer auf der Route prüfen, dem Entwicklungsteam mitteilen und bei Bedarf erhöhen.
Größenordnungen: Standardwerte: AWS ALB 60 s, NLB 350 s für TCP und 120 s für UDP, Azure Load Balancer 4 Minuten für TCP. Die TCP-Werte von ALB und NLB lassen sich ändern, die 120 s für UDP beim NLB nicht. Der ALB schließt nach Ablauf auch die Verbindung zum Server. Der NLB löscht sie stillschweigend, sodass der Server oft nichts davon merkt.
Im Graphen: Verbindungen brechen gleichzeitig ab · Verbindungsabbrüche, Idle-Zeit vor dem Abbruch
Wo nachsehen: Idle-Timeout-Einstellung der Load-Balancer auf der Route prüfen und für jede abgebrochene Verbindung die Zeit vom letzten Paket bis zum Abbruch sammeln. Bei AWS NLB auch TCP_ELB_Reset_Count in CloudWatch ansehen (vom Load-Balancer gesendete RSTs)
Spricht dafür: Die Idle-Zeit abgebrochener Verbindungen häuft sich knapp über dem eingestellten Wert (ALB 60 s, NLB TCP 350 s usw.), und wer länger als diese Zeit untätig bleibt und sich dann bewegt, löst den Abbruch reproduzierbar aus. Beim NLB steigt zur selben Zeit TCP_ELB_Reset_Count
Spricht dagegen: Abbrüche ohne Zusammenhang mit der Idle-Zeit: nicht diese Ursache. Häufung um 350 s bei Servern ohne Load-Balancer: „Ablauf des Connection Trackings in Cloud-Security-Groups“. Liegt es am Router beim Spieler zu Hause: „Ablauf des NAT-Mappings“
Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode)

Quellen

Edit attributes for your Application Load Balancer AWS
Idle-Timeout des ALB standardmäßig 60 s (1–4.000 s), ist die Verbindung zu Client oder Ziel so lange still, schließt der Load-Balancer sie
Network Load Balancers AWS
TCP-Idle-Timeout des NLB standardmäßig 350 s (60–6.000 s), danach endet nur das Tracking, und auf später eintreffende Daten folgt ein RST, die 120 s für UDP-Flows sind nicht änderbar
Configure load balancer TCP reset and idle timeout Microsoft Azure
Idle-Timeout des Azure Load Balancer standardmäßig 4 Minuten (4–100 Minuten), danach keine Garantie, dass die Session erhalten bleibt, TCP-Reset optional
CloudWatch metrics for your Network Load Balancer AWS
TCP_ELB_Reset_Count: Zahl der vom Load-Balancer erzeugten und gesendeten RST-Pakete

Idle-Timeout des Load-Balancers Load balancer idle timeout

Quellen

Verwandte Ursachen

Gleiche Schicht: L5 Netzwerkgeräte im Rechenzentrum

Ursachen aus anderen Schichten mit demselben Symptom (Verbindungsabbruch)