Queda brusca da taxa de envio pelo controle de congestionamento Congestion control backoff

ID da causa sk-congestion · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)

Abrir o card interativo, com figuras e simulações →

O TCP trata a perda como sinal de congestionamento e reduz a taxa de envio em 30–50%. Ele reage do mesmo jeito à perda no Wi-Fi.

Por quê Com muito a enviar, ocorre um pouco de perda no Wi-Fi ou na conexão → Efeito O TCP reduz muito a taxa de envio e se recupera devagar (o CUBIC, padrão no Linux e no Windows, reduz 30%) → Na tela Em lugares lotados, as atualizações atrasam: avanço rápido e input lag

Sintomas: Avanço rápido, Input lag
Fatores: Latência, Paralisação
Quem é afetado: Só eu
Quando: Quando junta muita gente
Responsável: Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento): Reduzir o volume enviado (área de interesse, só as mudanças), dividir o envio para não mandar tudo de uma vez.
O que fazer (Equipe de infraestrutura): Trocar para um controle de congestionamento como o BBR (tcp_congestion_control).
No gráfico: Dente de serra · Janela de congestionamento (cwnd) e taxa de envio por conexão
Onde olhar: Capturar várias vezes, com ss -ti, a conexão do jogador com atualizações atrasadas e ver a variação de cwnd e ssthresh e o nome do controle de congestionamento (cubic ou bbr), observando também se o Send-Q acumula
Confirma se: Depois de uma perda, o cwnd cai muito e sobe devagar, repetidamente, e enquanto está baixo o Send-Q acumula, coincidindo com o horário dos reports de avanço rápido e input lag
Descarta se: cwnd com folga, mas os dados atrasam: janela de quem recebe (“Janela zero (paralisação que parece retransmissão)”) ou envio no servidor
Como verificar: Ferramentas de infra (sem precisar do código do jogo)

Fontes

RFC 9438: CUBIC for Fast and Long-Distance Networks IETF
Na perda, o CUBIC multiplica a janela por 0,7 (redução de 30%) e o Reno, por 0,5; o CUBIC é o padrão no Linux, no Windows e nos sistemas da Apple
TCP BBR congestion control comes to GCP – your Internet just got faster Google Cloud
O controle de congestionamento baseado em perda reduz muito a taxa de envio mesmo em perdas que não vêm de congestionamento; o BBR decide pela taxa de entrega e pelo RTT
IP Sysctl Linux kernel
tcp_congestion_control escolhe o algoritmo de controle de congestionamento das conexões novas
ss(8) — Linux manual page iproute2
cwnd, ssthresh e nome do algoritmo de controle de congestionamento no -i
net/ipv4/tcp_diag.c (Linux v6.12) Linux kernel
Valores Recv-Q e Send-Q do ss: no socket em escuta, as conexões esperando o accept e o limite do backlog; no socket conectado, os bytes que o app ainda não leu e os bytes enviados ainda sem ACK

Veja também

Mesma camada: L8 Sockets e protocolos

Mesmo sintoma (Avanço rápido) em outras camadas

Gargalo no processamento de pacotes na thread principal L1 Processo do jogo no cliente
Espiral de recuperação do timestep fixo L1 Processo do jogo no cliente
Processos em segundo plano ocupando a CPU L2 SO e dispositivo do cliente
Estouro do buffer de recepção L2 SO e dispositivo do cliente
Outros apps do mesmo dispositivo consumindo largura de banda L2 SO e dispositivo do cliente
Limitação de processamento com a janela minimizada ou inativa L2 SO e dispositivo do cliente
Bufferbloat (fila do roteador) L3 Rede doméstica
Manutenção do host na nuvem e live migration L6 Placa de rede do servidor

Ver o card interativo, com figuras e simulações