Configuração de RTO inadequada para o ambiente RTO min too low or too high
ID da causa rt-rto-setting · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Com o RTO mínimo baixo demais, qualquer pequeno atraso gera retransmissões espúrias; já o padrão (200 ms) é longo demais para um jogo, e cada perda deixa a conexão parada por muito tempo.
Por quê RTO mínimo muito reduzido pensando no data center, ou o padrão mantido no trecho da internet → Efeito Baixo demais: avalanche de retransmissões até com picos momentâneos de latência. Alto demais: longa espera a cada perda → Na tela Com o padrão, cada perda causa um travamento de centenas de ms e depois avanço rápido; baixando demais, os travamentos diminuem, mas as retransmissões espúrias disparam e desperdiçam o link
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
No Linux 6.15 ou superior, avaliar baixar o teto do RTO das conexões do jogo com TCP_RTO_MAX_MS (o tempo até desistir também encurta, então definir junto, com TCP_USER_TIMEOUT, o tempo para considerar a conexão caída), baixar o RTO mínimo só nas conexões internas entre servidores com a opção de socket TCP_RTO_MIN_US (6.15 ou superior), avaliar a opção de socket TCP_THIN_LINEAR_TIMEOUTS para que, só nas conexões do jogo, RTOs seguidos não dobrem.
O que fazer (Equipe de infraestrutura)
Baixar o rto_min por rota só nas conexões internas entre servidores; no trecho da internet, manter o padrão e compensar com RACK-TLP e a configuração de thin stream (tcp_thin_linear_timeouts).
Números de referência
RTO no Linux = tempo de ida e volta + max(200 ms, desvio do RTT × 4). Dobra a cada falha, até 120 segundos. A partir do Linux 6.15, dá para baixar esse teto para até 1 segundo com TCP_RTO_MAX_MS.
No gráfico
Sempre alto desde o início · RTO por conexão, RTOs espúrios
Onde olhar
Ver a configuração de RTO mínimo do servidor (rto_min no ip route show; no Linux 6.11 ou superior, sysctl net.ipv4.tcp_rto_min_us), rto e rtt no ss -ti e o incremento de TcpExtTCPSpuriousRTOs no nstat
Confirma se
No servidor com mínimo reduzido, o rto das conexões pela internet fica colado no rtt, e TcpExtTCPSpuriousRTOs cresce muito. Com o padrão, o rto das conexões do jogo fica pelo menos 200 ms acima do rtt, e cada perda deixa a conexão parada por esse tempo
Descarta se
rto conforme o cálculo padrão (rtt + cerca de 200 ms) e poucos RTOs espúrios, mas paradas longas demais: perdas seguidas ou forma de recuperação (“Recuperação lenta em thin streams”, “Remoção de opções TCP por equipamento intermediário”)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes
RFC 6298: Computing TCP's Retransmission TimerIETF RTO = SRTT + max(G, 4·RTTVAR), recomendação de mínimo de 1 segundo, dobra a cada falha, e um eventual máximo deve ser de pelo menos 60 segundos
include/net/tcp.hLinux kernel No Linux, TCP_RTO_MIN de 200 ms e TCP_RTO_MAX de 120 segundos
net/ipv4/tcp_input.cLinux kernel No Linux, o RTO é SRTT + rttvar, e o rttvar não fica abaixo do RTO mínimo (padrão de 200 ms)
IP SysctlLinux kernel tcp_rto_min_us com padrão 200000 (a opção de rota rto_min e a opção de socket TCP_RTO_MIN_US têm prioridade), tcp_rto_max_ms de 1.000 a 120.000 (padrão 120.000), tcp_thin_linear_timeouts