Connection request (SYN) retransmission SYN retransmission on connect
Cause ID rt-syn · Primary owner Game team (Server development) · Also Infra team (Server infrastructure), Infra team (Network infrastructure), Game team (Client development)
If a connection request is lost because the connection queue (backlog) overflows or a firewall blocks it, the client OS resends it starting 1 second later, at growing intervals.
Why A connection surge right after maintenance overflows the server’s connection queue, or a firewall or DDoS protection drops the SYN → Effect The client OS retransmits the SYN starting 1 second later, at set intervals (older Linux: 1 s → 2 s → 4 s) → On screen After pressing Connect, delays come in whole seconds, such as 1 or 3 seconds; if it keeps failing: can’t connect / infinite loading
Primary owner Game team (Server development) · Also Infra team (Server infrastructure), Infra team (Network infrastructure), Game team (Client development)
Game team action items
Server: raise the backlog argument to listen (together with somaxconn), make sure the game server calls accept promptly, use a login queue. Client: lengthen connection retry intervals (randomized to spread retries out).
Infra team action items
Servers/OS: confirm server connection queue overflow with nstat TcpExtListenOverflows and TcpExtListenDrops and the “Possible SYN flooding” warning in the logs, raise somaxconn (together with the listen argument), use SYN cookies. Network: relax SYN limits on firewalls and DDoS protection.
Ballpark numbers
On Linux (Android included), the first SYN retransmission comes after 1 second. Older kernels then double the interval each time and resend at 1, 3, 7, 15 seconds …, while 6.5 and later (tcp_syn_linear_timeouts=4) resend five times at 1, 2, 3, 4, and 5 seconds, then double (7, 11, 19 seconds …). Android phones often keep their launch kernel even after OS updates, so behavior can differ between devices on the same Android version. Either way, if every attempt fails, the OS gives up after about 2 minutes. Windows starts at 1 or 3 seconds depending on version and settings and resends 2–4 times, so it gives up after 20–30 seconds (check that PC’s value with Max SYN Retransmissions in netsh int tcp show global).
On the graph
Surge after opening · Connection attempts, connection queue overflows
Where to look
In the server’s nstat, TcpExtListenOverflows and TcpExtListenDrops, plus the “Possible SYN flooding on port” warning in dmesg; in ss -lnt, whether a listening socket’s Recv-Q (connections waiting for accept) reaches its Send-Q (backlog limit). In a server-side capture, whether SYNs arrive and whether SYN-ACKs go back
Confirmed if
During the connection surge right after maintenance, TcpExtListenOverflows rises and Recv-Q sits at Send-Q. The capture shows the same client’s SYN coming back at whole-second intervals with no server response
Ruled out if
SYNs never reach the server and server counters stay flat: a firewall or DDoS protection in front dropped them, so check that device’s SYN limits and drop logs. Server sent SYN-ACKs but connecting is still slow: loss in the return direction
Check with
Infra tools (no game code needed)
Sources
include/net/tcp.hLinux kernel Initial RTO TCP_TIMEOUT_INIT = 1 second (the initial value from RFC 6298)
IP SysctlLinux kernel tcp_syn_retries defaults to 6, tcp_syn_linear_timeouts defaults to 4 (SYN RTO 1, 1, 1, 1, 1, 2, 4 …), last retransmission at 67 seconds and giving up at 131 seconds, somaxconn defaults to 4096, tcp_syncookies defaults to 1
tcp: make the first N SYN RTO backoffs linearLinux kernel Commit that made the first SYN retransmissions use a fixed interval, from Linux 6.5 (the default of 4 follows the macOS and iOS behavior)
Android common kernelsAndroid (Google) Common kernels 5.10 through 6.18 are supported side by side, and a kernel for an earlier platform (e.g., android14-6.1) can be used to launch or upgrade new Android devices
TcpMaxConnectRetransmissionsMicrosoft Older Windows defaults: 2 SYN retransmissions, starting with a 3-second wait and doubling, then waiting double again after the last one before giving up (3+6+12=21 seconds)
listen(2) — Linux manual pageLinux man-pages The backlog argument to listen is truncated to somaxconn (default 4096 since Linux 5.4, 128 before that)
SNMP counterLinux kernel When the accept queue is full, SYNs are dropped and TcpExtListenOverflows and TcpExtListenDrops rise together; TcpExtTCPSynRetrans