Black hole de MTU (perda repetida só dos pacotes grandes) PMTU black hole
ID da causa rt-mtu · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento)
Se algum trecho do caminho passa a aceitar só pacotes menores e o aviso de “grande demais” (ICMP) é bloqueado, os pacotes grandes continuam sumindo, por mais vezes que sejam reenviados.
Por quê O tamanho máximo diminui em um trecho de VPN ou túnel, e um firewall bloqueia os avisos de pacote grande demais → Efeito Sem saber o motivo, quem envia retransmite o mesmo pacote grande sem parar, e o RTO dobra a cada vez → Na tela Tudo normal até chegar um momento de dados grandes (inventário, lugar lotado, carregamento ao entrar); aí tudo para, até os pacotes pequenos que vêm depois, e no fim vem a desconexão ou o loading infinito
Ao fazer ações específicas, Logo após login ou manutenção
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)
O que fazer (Equipe de desenvolvimento)
Para reduzir direto no servidor, configurar o tamanho máximo de segmento do socket (TCP_MAXSEG); só dividir as mensagens em pedaços menores no código do jogo não evita o problema (o TCP junta de novo os dados a enviar em blocos do tamanho do MSS).
O que fazer (Equipe de infraestrutura)
Rede: fazer MSS clamping nos equipamentos de borda, liberar o ICMP de pacote grande demais (tipo 3, código 4, fragmentation needed) nos firewalls e nas ACLs de rede da nuvem. Servidores/SO: configurar o MTU do caminho, verificar se o ICMP de pacote grande demais não é bloqueado também nos firewalls dos servidores e nos grupos de segurança da nuvem, usar o tcp_mtu_probing=1 do Linux como última rede de segurança.
Números de referência
Normalmente 1.500 bytes, cerca de 1.400 ao passar por um túnel. Se o mesmo pacote é retransmitido 5–6 vezes, a conexão fica mais de 10 segundos parada.
No gráfico
Alto só em alguns · RTO e backoff por conexão, desconexões por região e operadora
Onde olhar
Ver as retransmissões da conexão com problema por captura de pacotes no servidor ou com bcc tcpretrans -s (mostra o número de sequência), e ver mss, pmtu e backoff dessa conexão com ss -ti. Do servidor, enviar ao endereço do jogador um ping pequeno e um ping de 1.500 bytes com DF (ping -M do -s 1472) e comparar
Confirma se
Pacotes cheios até o MSS são retransmitidos sem parar com o mesmo número de sequência, com o intervalo dobrando a cada vez, enquanto os pacotes menores passam. Não chega nenhum ICMP de pacote grande demais (filtro do Wireshark icmp.type == 3 and icmp.code == 4); o ping pequeno responde, e só o ping grande com DF some sem resposta
Descarta se
Pacotes pequenos também somem: perda sem relação com o tamanho (“Estouro de fila no gargalo”, “Mudança de rota ou caminho ECMP com defeito”). O ICMP de pacote grande demais chega e o pmtu do ss -ti diminui: a descoberta do MTU do caminho está funcionando
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Com tcp_mtu_probing=1, o kernel só conclui que há um black hole depois de alguns segundos de timeouts de retransmissão (o equivalente a tcp_retries1=3) e então reduz o MSS para 1.024 bytes. Durante esse tempo a conexão fica parada, então ele serve como última rede de segurança; a prioridade é o MSS clamping, que evita o problema antes.
Fontes
RFC 1191: Path MTU discoveryIETF Descoberta do MTU do caminho: um pacote grande demais é sinalizado com o ICMP “fragmentation needed and DF set” (tipo 3, código 4)
IP SysctlLinux kernel tcp_mtu_probing: 0 desligado, 1 só quando um black hole é detectado, 2 sempre (MSS inicial em tcp_base_mss). tcp_retries1 com padrão 3
net/ipv4/tcp_timer.cLinux kernel Quando as retransmissões por RTO se repetem tcp_retries1 vezes, o kernel considera detectado um black hole, liga a sondagem de MTU e reduz o MSS
iptables-extensions(8) — Linux manual pagenetfilter TCPMSS --clamp-mss-to-pmtu: contorna o problema dos pacotes grandes que param em trechos que bloqueiam ICMP, ajustando o MSS no SYN
tcp(7) — Linux manual pageLinux man-pages TCP_MAXSEG: tamanho máximo de segmento dos pacotes de saída; se definido antes da conexão, muda também o MSS anunciado ao outro lado
MTU considerations | Cloud VPNGoogle Cloud MTU do gateway do Cloud VPN de 1.460 bytes, MTU de payload do túnel IPv4 de 1.406 bytes (cerca de 1.400 ao passar pelo túnel)
ss(8) — Linux manual pageiproute2 mss, pmtu (MTU do caminho) e backoff (quantas vezes o RTO dobrou) no ss -i
ping(8) — Linux manual pageiputils -M do liga o DF e não envia pacotes maiores que o MTU do caminho conhecido pelo kernel; -s é o tamanho dos dados (sem contar os 8 bytes do cabeçalho ICMP)