Retransmissão do pedido de conexão (SYN) SYN retransmission on connect
ID da causa rt-syn · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Infraestrutura de rede (Equipe de infraestrutura), Desenvolvimento do cliente (Equipe de desenvolvimento)
Se o pedido de conexão se perde por estouro da fila de conexões (backlog) ou bloqueio no firewall, o SO do cliente volta a enviá-lo a partir de 1 segundo depois, com intervalos crescentes.
Por quê O pico de conexões logo após a manutenção estoura a fila de conexões do servidor, ou o firewall ou a proteção contra DDoS descarta o SYN → Efeito O SO do cliente retransmite o SYN a partir de 1 segundo depois, em intervalos definidos (no Linux antigo, 1 s → 2 s → 4 s) → Na tela Depois de clicar em conectar, o atraso é de segundos exatos, como 1 s ou 3 s; se continuar falhando, não conecta ou fica em loading infinito
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Infraestrutura de rede (Equipe de infraestrutura), Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: aumentar o argumento backlog do listen (junto com o somaxconn), garantir que o servidor do jogo chame accept a tempo, sistema de fila de login. Cliente: aumentar o intervalo entre tentativas de conexão (espalhando-as aleatoriamente).
O que fazer (Equipe de infraestrutura)
Servidores/SO: confirmar o estouro da fila de conexões do servidor pelo TcpExtListenOverflows e TcpExtListenDrops do nstat e pelo aviso “Possible SYN flooding” no log, aumentar o somaxconn (junto com o argumento do listen), SYN cookies. Rede: afrouxar o limite de SYN do firewall e da proteção contra DDoS.
Números de referência
No Linux (inclusive no Android), a primeira retransmissão do SYN sai após 1 segundo. Kernels antigos dobram o intervalo a partir daí e reenviam aos 1, 3, 7, 15 segundos …; a partir do 6.5, o kernel reenvia cinco vezes, em 1, 2, 3, 4 e 5 segundos, e depois passa a dobrar (7, 11, 19 segundos …) (tcp_syn_linear_timeouts=4). Celulares Android muitas vezes continuam com o kernel de lançamento mesmo após atualizar o SO, então o comportamento pode variar de aparelho para aparelho, mesmo na mesma versão do Android. Em qualquer caso, se todas as tentativas falham, a conexão desiste depois de cerca de 2 minutos. No Windows, conforme a versão e a configuração, o intervalo começa em 1 ou 3 segundos e cresce, e são 2–4 reenvios, então a desistência vem em 20–30 segundos (o valor daquele PC aparece em Max SYN Retransmissions no netsh int tcp show global).
No gráfico
Pico logo após abrir ou manutenção · Tentativas de conexão, estouros da fila de conexões
Onde olhar
Ver TcpExtListenOverflows e TcpExtListenDrops no nstat do servidor e o aviso “Possible SYN flooding on port” no dmesg, e ver com ss -lnt se o Recv-Q do socket em escuta (conexões esperando accept) encosta no Send-Q (limite do backlog). Com captura no servidor, verificar se o SYN chega e se o SYN-ACK volta
Confirma se
No pico de conexões logo após a manutenção, TcpExtListenOverflows aumenta e o Recv-Q fica colado no Send-Q. Na captura, o SYN do mesmo cliente volta em intervalos de segundos e o servidor não responde
Descarta se
O SYN não chega ao servidor e os contadores do servidor estão parados: o firewall ou a proteção contra DDoS na frente descartou; ver o limite de SYN e o log de descartes desse equipamento. O servidor enviou o SYN-ACK e mesmo assim a conexão demora: perda no sentido de volta
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes
include/net/tcp.hLinux kernel Primeiro RTO TCP_TIMEOUT_INIT = 1 segundo (valor inicial da RFC 6298)
IP SysctlLinux kernel tcp_syn_retries com padrão 6, tcp_syn_linear_timeouts com padrão 4 (RTO do SYN 1, 1, 1, 1, 1, 2, 4 …), última retransmissão em 67 segundos e desistência em 131 segundos, somaxconn com padrão 4096, tcp_syncookies com padrão 1
tcp: make the first N SYN RTO backoffs linearLinux kernel Commit que torna constante o intervalo das primeiras retransmissões de SYN, a partir do Linux 6.5 (o padrão 4 segue o comportamento do macOS e do iOS)
Android common kernelsAndroid (Google) Os kernels comuns de 5.10 a 6.18 são suportados em paralelo, e kernels de plataformas anteriores (ex.: android14-6.1) podem ser usados no lançamento ou na atualização de novos aparelhos Android
TcpMaxConnectRetransmissionsMicrosoft Padrão antigo do Windows: 2 retransmissões de SYN, com a primeira espera de 3 segundos e depois dobrando; após a última, espera mais o dobro e desiste (3+6+12=21 segundos)
TCP/IP connectivity issues troubleshootingMicrosoft O número de retransmissões de SYN varia conforme o SO e aparece em Max SYN Retransmissions no netsh int tcp show global
listen(2) — Linux manual pageLinux man-pages O argumento backlog do listen é limitado pelo somaxconn (padrão 4096 a partir do Linux 5.4; antes, 128)
SNMP counterLinux kernel Quando a fila de accept enche, o SYN é descartado e TcpExtListenOverflows e TcpExtListenDrops aumentam juntos; TcpExtTCPSynRetrans
net/ipv4/tcp_input.cLinux kernel Mensagem de log “Possible SYN flooding on port …”
net/ipv4/tcp_diag.cLinux kernel Em um socket em escuta, o Recv-Q do ss é o número de conexões esperando accept, e o Send-Q é o limite do backlog