RTO do TCP e backoff exponencial RTO and exponential backoff
ID da causa sk-rto · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Cada vez que uma retransmissão falha de novo, o tempo de espera dobra, e uma queda curta da conexão vira uma pausa longa.
Por quê A conexão cai por um instante e as retransmissões também falham em sequência → Efeito A espera até a próxima tentativa dobra a cada vez: 0,3 → 0,6 → 1,2 → 2,4 s (com ping de 100 ms) → Na tela A conexão caiu por 1 s, mas o jogo fica travado por mais de 2 s. Se a queda for mais longa, acaba em desconexão
Aleatoriamente, de vez em quando, Em movimento ou ao trocar de mapa
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: responder aos heartbeats e, se não receber nenhum por um certo tempo, encerrar a conexão por conta própria (reduzir o prazo de desistência com TCP_USER_TIMEOUT), retomar a sessão com um token de sessão, usar UDP confiável. Cliente: enviar heartbeats em intervalos curtos e, se as respostas pararem, reconectar logo, sem esperar a retransmissão do TCP.
Números de referência
No Linux, o RTO (tempo de espera para retransmitir) tem mínimo de “ping + 200 ms” e começa em 1 s no estabelecimento da conexão. Com a configuração padrão (tcp_retries2=15), mesmo com as retransmissões falhando sem parar, a conexão só é abandonada depois de cerca de 15 minutos.
No gráfico
Lacuna e depois tudo junto · RTO e backoff por conexão, expirações do RTO
Onde olhar
Ver na conexão parada, com ss -ti, o rto (espera para retransmitir, em ms) e o backoff (expirações seguidas); para o servidor inteiro, o aumento de TcpExtTCPTimeouts (expirações do timer de retransmissão) no nstat -az
Confirma se
A conexão parada tem backoff de 1 ou mais e rto na casa dos segundos, e TCPTimeouts sobe nesse momento
Descarta se
Retransmissões resolvidas por fast retransmit, sem expiração do RTO: a parada é curta. Nesse caso: “HOL blocking no TCP”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
net/ipv4/tcp_input.c (Linux v6.12)Linux kernel No Linux, RTO = RTT suavizado + variação do RTT, e a variação tem piso de tcp_rto_min (200 ms), então o RTO é pelo menos RTT + 200 ms
IP SysctlLinux kernel tcp_rto_min_us com padrão de 200 ms; RTO inicial de 1 s para pedidos de conexão; com tcp_retries2=15, pelo menos 924,6 s (cerca de 15 minutos) até desistir
ss(8) — Linux manual pageiproute2 rto (timer de retransmissão, em ms) e backoff (número de backoffs exponenciais) do -i
net/ipv4/tcp_timer.c (Linux v6.12)Linux kernel Cada vez que o timer de retransmissão expira, incrementa TCPTimeouts, soma 1 ao backoff e dobra o RTO (até o máximo)