한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Guia do Lag em Jogos › Causas-raiz da retransmissão TCP

Descarte pelo firewall ou pelo rastreamento de conexões Stateful firewall / conntrack drops

ID da causa rt-stateful-fw · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento), Desenvolvimento do cliente (Equipe de desenvolvimento)

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

O firewall ou o rastreamento de conexões do Linux (conntrack, recurso que registra numa tabela as conexões que passam) descarta pacotes quando a tabela enche ou quando conclui que o estado da conexão não confere.

Por quê Tabela de rastreamento de conexões cheia (table full), ou ida e volta por caminhos diferentes, com só um sentido passando pelo firewall (rota assimétrica) → Efeito O firewall trata os pacotes como de “conexão desconhecida” ou com “número de sequência fora da janela” e descarta → Na tela Com a tabela cheia, novas conexões são bloqueadas; com o caminho desencontrado, só quem passa por esse caminho sofre desconexão depois de retransmissões repetidas

Sintomas
Travamento, Desconexão, Não conecta / loading infinito
Fatores
Perda de pacotes
Quem é afetado
Servidor inteiro, Região ou operadora específica
Quando
Quando junta muita gente, Logo após login ou manutenção, Aleatoriamente, de vez em quando
Responsável
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento), Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: para o caso de a tabela encher, controlar picos de conexão com um sistema de fila de login, reutilizar conexões para não abrir conexões curtas repetidamente (inclusive nas chamadas entre servidores), encerrar por conta própria as conexões cujo heartbeat parou. Cliente: se a conexão falhar ou cair, aumentar o intervalo entre tentativas e espalhá-las aleatoriamente (para não voltarem todos de uma vez quando a tabela estiver cheia).
O que fazer (Equipe de infraestrutura)
Rede: aumentar a tabela de rastreamento de conexões do firewall, tirar as portas do jogo do rastreamento de conexões, ajustar o roteamento para que ida e volta passem pelo mesmo firewall, verificar a configuração de validação da janela TCP no firewall. Servidores/SO: aumentar a tabela no Linux (nf_conntrack_max), tirar as portas do jogo do rastreamento de conexões (NOTRACK), verificar a configuração de validação da janela TCP (nf_conntrack_tcp_be_liberal), na AWS verificar também conntrack_allowance_exceeded.
Números de referência
O limite padrão do conntrack no Linux (nf_conntrack_max) vai de dezenas de milhares a centenas de milhares de entradas, conforme a memória. Quando o número atual (nf_conntrack_count) chega ao limite, aparece no log “nf_conntrack: table full, dropping packet”.
No gráfico
Achata ao bater no limite · Entradas do conntrack (nf_conntrack_count), falhas de novas conexões
Onde olhar
Em servidor Linux, ver nf_conntrack_count e nf_conntrack_max, “nf_conntrack: table full, dropping packet” no dmesg e drop e invalid em /proc/net/stat/nf_conntrack (uma linha por núcleo, em hexadecimal). No firewall, ver o uso da tabela de sessões e o log de descartes; na AWS, conntrack_allowance_exceeded no ethtool -S
Confirma se
O número de entradas encosta no limite e achata, e no mesmo momento aumentam o log de table full e o drop, ou o conntrack_allowance_exceeded. Com rota assimétrica, a tabela tem folga, mas invalid e o log de descartes do firewall aumentam nas conexões de um caminho específico
Descarta se
Entradas longe do limite e invalid e log de descartes parados: outra causa. Tabela com folga, mas CPU ou pacotes por segundo do firewall no máximo: “Sobrecarga de equipamento intermediário”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)

Fontes

  1. Netfilter Conntrack Sysfs variables Linux kernel
    O padrão de nf_conntrack_max é o número de buckets do hash (memória ÷ 16384, de 1.024 a 262.144); o número atual fica em nf_conntrack_count; com nf_conntrack_tcp_be_liberal, só RSTs fora da janela são tratados como INVALID
  2. net/netfilter/nf_conntrack_core.c Linux kernel
    Quando a tabela enche, registra “nf_conntrack: table full, dropping packet” no log e descarta (a estatística drop aumenta); pacotes que não batem com o estado da conexão aumentam a estatística invalid
  3. iptables-extensions(8) — Linux manual page netfilter
    CT --notrack na tabela raw exclui do rastreamento de conexões
  4. Amazon EC2 security group connection tracking AWS
    Ao passar do limite de conexões rastreadas por instância, os pacotes são descartados (visível em conntrack_allowance_exceeded), e a recomendação é evitar rotas assimétricas
  5. net/netfilter/nf_conntrack_standalone.c Linux kernel
    /proc/net/stat/nf_conntrack tem uma linha por núcleo, em hexadecimal, com colunas como entries, invalid, insert_failed, drop e early_drop

Veja também

Mesma camada: Causas-raiz da retransmissão TCP

Mesmo sintoma (Travamento) em outras camadas

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