Geht die Verbindungsanfrage durch einen Überlauf der Verbindungswarteschlange (Backlog) oder eine Firewall-Sperre verloren, sendet das Client-OS sie ab 1 s in wachsenden Abständen erneut.
Warum Login-Ansturm direkt nach der Wartung lässt die Verbindungswarteschlange des Servers überlaufen, oder Firewall bzw. DDoS-Schutz verwerfen SYNs → Folge Client-OS sendet SYN ab 1 s in festgelegten Abständen erneut (ältere Linux-Versionen: 1 s → 2 s → 4 s) → Auf dem Bildschirm Nach dem Klick auf Verbinden Verzögerung um glatte Sekunden wie 1 s oder 3 s, bei anhaltendem Scheitern: Kein Login / Endlos-Laden
Server: backlog-Argument von listen erhöhen (zusammen mit somaxconn), dafür sorgen, dass der Spielserver accept rechtzeitig aufruft, Login-Warteschlangensystem. Client: Abstände zwischen Verbindungsversuchen vergrößern (zufällig gestreut).
Aufgaben Infrastrukturteam
Server/OS: Überlauf der Verbindungswarteschlange über TcpExtListenOverflows und TcpExtListenDrops in nstat und die Warnung „Possible SYN flooding“ im Log erkennen, somaxconn erhöhen (zusammen mit dem listen-Argument), SYN-Cookies. Netzwerk: SYN-Limits von Firewall und DDoS-Schutz lockern.
Größenordnungen
Unter Linux (einschließlich Android) folgt die erste SYN-Retransmission nach 1 s. Ältere Kernel verdoppeln danach jeweils den Abstand und senden nach 1, 3, 7, 15 s … erneut, ab 6.5 wird nach 1, 2, 3, 4 und 5 s fünfmal erneut gesendet und danach verdoppelt (7, 11, 19 s …) (tcp_syn_linear_timeouts=4). Android-Smartphones behalten auch nach OS-Updates oft den Kernel aus der Markteinführung, daher kann es selbst bei gleicher Android-Version je nach Gerät Unterschiede geben. In beiden Fällen wird nach etwa 2 Minuten aufgegeben, wenn alles scheitert. Unter Windows beginnt es je nach Version und Einstellung bei 1 s oder 3 s, und bei 2–4 Wiederholungen wird nach 20–30 s aufgegeben (den Wert des PCs zeigt Max SYN Retransmissions in netsh int tcp show global).
Im Graphen
Ansturm direkt nach Login oder Wartung · Verbindungsversuche, Überläufe der Verbindungswarteschlange
Wo nachsehen
In nstat auf dem Server TcpExtListenOverflows und TcpExtListenDrops sowie die Warnung „Possible SYN flooding on port“ in dmesg prüfen, mit ss -lnt ansehen, ob Recv-Q (auf accept wartende Verbindungen) des lauschenden Sockets Send-Q (backlog-Limit) erreicht. Per Mitschnitt auf dem Server prüfen, ob SYNs ankommen und SYN-ACKs zurückgehen
Spricht dafür
Beim Login-Ansturm direkt nach der Wartung steigt TcpExtListenOverflows, und Recv-Q klebt an Send-Q. Im Mitschnitt kommen SYNs desselben Clients im Sekundenabstand erneut, der Server antwortet nicht
Spricht dagegen
SYNs erreichen den Server nicht, und die Serverzähler bleiben unverändert: Firewall oder DDoS-Schutz davor hat sie verworfen, also SYN-Limits und Drop-Logs dieses Geräts prüfen. Sendet der Server SYN-ACK und der Verbindungsaufbau dauert trotzdem lange: Verlust auf dem Rückweg
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen
include/net/tcp.hLinux kernel Erstes RTO TCP_TIMEOUT_INIT = 1 s (Anfangswert aus RFC 6298)
IP SysctlLinux kernel tcp_syn_retries standardmäßig 6, tcp_syn_linear_timeouts standardmäßig 4 (SYN-RTO 1, 1, 1, 1, 1, 2, 4 …), letzte Retransmission nach 67 s, Aufgabe nach 131 s, somaxconn standardmäßig 4096, tcp_syncookies standardmäßig 1
tcp: make the first N SYN RTO backoffs linearLinux kernel Commit, der die ersten SYN-Retransmissions auf feste Abstände umstellt, ab Linux 6.5 (der Standardwert 4 folgt dem Verhalten von macOS und iOS)
Android common kernelsAndroid (Google) Die Common Kernels 5.10 bis 6.18 werden parallel unterstützt, und Kernel für frühere Plattformen (z. B. android14-6.1) können für Markteinführung oder Upgrade neuer Android-Geräte verwendet werden
TcpMaxConnectRetransmissionsMicrosoft Früherer Windows-Standard: 2 SYN-Retransmissions, erste Wartezeit 3 s, jeweils verdoppelt, nach der letzten wird noch einmal doppelt so lange gewartet, dann aufgegeben (3+6+12=21 s)
TCP/IP connectivity issues troubleshootingMicrosoft Die Zahl der SYN-Retransmissions unterscheidet sich je nach OS, Prüfung über Max SYN Retransmissions in netsh int tcp show global
listen(2) — Linux manual pageLinux man-pages Das backlog-Argument von listen wird auf somaxconn gekappt (ab Linux 5.4 standardmäßig 4096, vorher 128)
SNMP counterLinux kernel Ist die accept-Warteschlange voll, werden SYNs verworfen, und TcpExtListenOverflows und TcpExtListenDrops steigen gemeinsam, TcpExtTCPSynRetrans