Remoção de opções TCP por equipamento intermediário Middlebox strips TCP options
ID da causa rt-sack-stripped · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
Quando alguns firewalls ou equipamentos de aceleração apagam ou alteram opções do TCP, a conexão fica lenta: ao perder vários pacotes, ela recupera só um por ida e volta, ou a janela (quanto dá para enviar de uma vez) fica pequena.
Por quê A “normalização TCP” do firewall ou um equipamento de aceleração antigo remove as opções SACK, timestamps e window scaling → Efeito Com vários pacotes perdidos, a recuperação é de um por ida e volta, e a janela fica limitada a 64 KB → Na tela Cada perda trava o jogo por muito mais tempo (sem SACK, nem o RACK-TLP funciona) e, quando destrava, vem o avanço rápido. Transferências grandes, como patches, também ficam lentas
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Rede: desligar a normalização TCP no equipamento em questão, verificar também a randomização de números de sequência do firewall, comparar as opções do SYN em capturas de pacotes nas duas pontas. Servidores/SO: verificar no ss -ti se as conexões sem sack e wscale se concentram em um caminho específico (PCs com Windows podem não usar ts, conforme a configuração, então faltar só o ts pode ser normal), verificar se o net.ipv4.tcp_sack do servidor está em 1.
No gráfico
Sempre alto desde o início · Recuperações iniciadas sem SACK (TcpExtTCPRenoRecovery)
Onde olhar
Ver no ss -ti se cada conexão mostra sack e wscale e, no nstat, a proporção entre TcpExtTCPRenoRecovery (recuperação iniciada sem SACK) e TcpExtTCPSackRecovery, além de TcpExtTCPSACKDiscard (blocos SACK descartados por incoerência). No caminho suspeito, capturar o SYN nas duas pontas e comparar as opções (tcp.options.sack_perm no Wireshark, entre outras)
Confirma se
Só as conexões que passam por um caminho ou equipamento específico estão sem sack e wscale, e a parcela de TcpExtTCPRenoRecovery é alta. A opção de SACK permitido que estava no SYN enviado não aparece no SYN recebido. Se a causa for a randomização de números de sequência, as opções continuam lá, mas TcpExtTCPSACKDiscard aumenta
Descarta se
Todas as conexões sem sack: verificar primeiro o valor de net.ipv4.tcp_sack do servidor. Opções intactas e TcpExtTCPSACKDiscard parado: a recuperação lenta tem outro motivo (“Recuperação lenta em thin streams”)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Mesmo com as opções presentes, o SACK pode quebrar. Se a randomização de números de sequência (sequence randomization) do firewall muda só o número de sequência do cabeçalho e deixa como estão os números dentro do SACK, quem envia descarta os SACKs incoerentes. O resultado é o mesmo quando, na falha de segurança do SACK em 2019, o SACK foi desligado no servidor com tcp_sack=0 e ficou esquecido assim.