O ping marca 25 ms no lobby e 90 ms assim que a partida começa. Dispara, o servidor discorda e sofre rubber-banding três metros para trás. Nem o contador do jogo nem um teste de velocidade lhe dizem para onde vão esses milissegundos. Entre a sua máquina e o servidor de jogo estão o router de casa, o seu operador, uma ou duas redes de trânsito e a rede do próprio anfitrião. O atraso, e o jitter por trás dos picos de lag, vem de um deles.
Um traceroute visual mostra cada um desses saltos num mapa, com a latência, o jitter e a perda de pacotes, e identifica a rede a que pertence. Assim fica a saber se o culpado é o Wi-Fi, o congestionamento do operador nas horas de ponta, um peering fraco entre o operador e o anfitrião, ou simplesmente uma região de servidor demasiado distante. Um traceroute não baixa o ping por si só; diz-lhe que solução vale a pena tentar e dá-lhe provas quando falar com o operador.
Encontrar o salto que acrescenta latência
Trace até ao endereço do servidor, retirado dos registos do jogo ou da lista da plataforma, com 30 a 40 saltos. Leia a latência do primeiro salto ao último e procure o primeiro aumento que se mantém. O salto 1 é o router de casa: acima de 5 ms em Ethernet, ou de 20 ms com jitter visível, o problema está dentro de casa, quase sempre no Wi-Fi. Os saltos 2 a 4 são do operador; um aumento aí às 21h que desaparece às 8h é congestionamento de hora de ponta. Um aumento exatamente onde a coluna ASN muda é a passagem entre o operador e o trânsito ou o anfitrião. 40 ms constantes desde a mudança de ASN até ao fim são distância: a resposta é outra região.
O jitter e a perda, não o ping médio, causam rubber-banding
Um ping de 60 ms com 2 ms de jitter parece fluido; 40 ms com 30 ms de jitter parecem avariados, porque o jogo prevê a sua posição entre pacotes e corrige-a quando chegam atrasados. Leia a coluna do jitter salto a salto: o primeiro salto onde ele sobe é o seu segmento instável. A perda funciona da mesma forma, com uma armadilha. Um salto intermédio com 20% de perda enquanto o destino mostra 0% é um router a despriorizar as respostas ao traceroute, não pacotes de jogo perdidos. A perda real começa num salto e persiste até ao último. Execute o traceroute em hora de ponta e fora dela e compare os dois lado a lado; a diferença diz-lhe se enfrenta congestionamento ou um problema permanente de caminho.
Cabo ou Wi-Fi, escolha de região e o que enviar ao operador
Trace em Wi-Fi e depois em Ethernet, mesmo alvo, e compare. Se o jitter do salto 1 cair de 15 ms para menos de 1 ms, tem a resposta: nenhuma definição do router vence um cabo. Depois trace para duas ou três regiões: a lista do jogo raramente reflete o caminho real, e uma região próxima pode passar por um ponto de troca distante. Se o atraso aparece nos saltos do operador ou na passagem, repita o traceroute de uma sonda Globalping noutra rede do seu país e exporte ambos. Mesmo alvo, outra rede, metade do ping: um argumento que o operador não pode ignorar. Uma VPN merece um teste quando o problema é peering, porque muda onde o tráfego é entregue; nada faz contra a distância ou o Wi-Fi.
Ler um traceroute: uma partida que tem lag todas as noites
Exemplo pedagógico, não uma medição real. Um jogador em Lyon traça até um servidor em Frankfurt. O salto 1, o router de casa, responde em 1 ms sem jitter. Os saltos 2 a 4, na rede do operador, ficam a 8 a 11 ms. No salto 5 o ASN muda para uma operadora de trânsito: 14 ms. O salto 6 marca 68 ms com 25 ms de jitter, e os saltos seguintes rondam os 70 ms. O aumento persiste até ao fim, logo é real, e começa após a passagem: o elo fraco está entre essa operadora e o anfitrião, não em casa. O mesmo traceroute às 7h dá 18 ms extremo a extremo: congestionamento de hora de ponta. Opções: uma região servida por outra operadora, um teste de VPN, ou um ticket ao operador com os dois traceroutes.
Ferramentas a usar antes e depois do traceroute
O Ping envia uma rajada de sondas e devolve mínimo, média, jitter e perda; use-o primeiro para confirmar que o pico está a acontecer agora, depois trace. O DNS Lookup diz para que endereço resolve o nome do servidor, pois alguns jogos usam endereços diferentes por região. O WHOIS e o IP Reputation identificam a quem pertence o endereço de um servidor, útil quando um servidor comunitário afinal está noutro continente. O Port Check confirma se a porta do jogo está acessível quando se suspeita de firewall ou de CGNAT.
Perguntas frequentes
- Um traceroute pode baixar o meu ping?
- Não. Mede o caminho; não o altera. O que lhe dá é o segmento que acrescenta o atraso, para que corrija a coisa certa: trocar o Wi-Fi por Ethernet se o salto 1 for instável, escolher uma região de servidor com um caminho mais limpo, testar uma VPN se o problema estiver numa passagem de peering, ou enviar provas ao operador quando o congestionamento está do lado dele.
- O jogo mostra 30 ms mas alguns saltos mostram 60 ms. Qual está certo?
- Podem estar os dois. O contador do jogo mede a ida e volta até ao servidor no protocolo do próprio jogo. O traceroute mede cada router intermédio, e os routers respondem muitas vezes devagar porque despriorizam esse tipo de tráfego. Só o último salto reflete o seu ping real, e só um atraso que persiste de um salto até ao destino é real. Experimente o modo TCP ou UDP se o ICMP parecer estranho.
- Estou atrás de CGNAT. Isso muda a forma de ler o traceroute?
- Com carrier-grade NAT, o operador partilha um endereço público entre vários clientes, por isso o salto 2 ou 3 mostra muitas vezes um endereço privado da gama 100.64.0.0/10 dentro da rede do operador. Acrescenta pouca latência por si só, mas impede alojar um servidor em casa e pode fazer o Port Check indicar a sua porta como fechada ou filtrada. O resto do caminho lê-se normalmente.