Como identificar gargalos de rede com traceroute

Um gargalo de rede é o ponto de um caminho onde o atraso ou a perda começam e nunca mais desaparecem. O traceroute e o mtr conseguem encontrá-lo, mas a maior parte do que mostram é ruído: routers que respondem devagar às sondas, que as descartam ou que ficam calados, enquanto encaminham o tráfego real na perfeição. Este guia usa rastreios reais dos nossos servidores, feitos a 7 de outubro de 2026, para mostrar a regra que separa uma coisa da outra e o que fazer quando encontrar um gargalo verdadeiro.

A regra: tem de durar até ao destino

Cada linha de um rastreio é uma ida e volta independente, respondida por um router diferente. Os routers encaminham o tráfego em hardware, mas respondem às sondas em software, com baixa prioridade, e a maioria limita o número de respostas que envia por segundo. Por isso, um salto que parece lento ou com perdas só conta se todos os saltos seguintes, até ao destino, tiverem o mesmo aspeto. O TraceMapper aplica a mesma regra quando escreve o seu veredicto sobre um rastreio: uma subida só conta se persistir até ao destino.

Rastreio real 1: 82% de «perda» que não é perda

Do nosso servidor em Falkenstein, na Alemanha, para um host de teste da Vultr em Singapura (mtr -rwz -c 60, 60 sondas por salto):

  5. AS1299   hbg-b2-link.ip.twelve99.net                      0.0%    60   11.9  11.7  11.3  12.1   0.2
  6. AS1299   hbg-bb3-link.ip.twelve99.net                    53.3%    60   25.0  25.0  24.7  25.3   0.2
  7. AS1299   ffm-bb1-link.ip.twelve99.net                     0.0%    60   30.2  30.1  29.8  30.5   0.2
  8. AS1299   prs-bb1-link.ip.twelve99.net                     0.0%    60   38.6  38.1  37.7  38.6   0.2
  9. AS1299   mei-b5-link.ip.twelve99.net                      0.0%    60   32.3  32.3  32.0  32.7   0.2
 10. AS1299   sng-b6-link.ip.twelve99.net                      0.0%    60  169.7 178.0 169.5 249.9  16.1
 11. AS1299   sng-b7-link.ip.twelve99.net                      0.0%    60  169.0 169.0 168.0 179.5   2.2
 12. AS1299   sng-b5-link.ip.twelve99.net                     81.7%    60  168.0 190.1 167.6 381.6  64.2
 13. AS1299   constantcompany-ic-379815.ip.twelve99-cust.net   0.0%    60  164.7 165.1 164.7 166.3   0.2
 14. AS???    ???                                             100.0    60    0.0   0.0   0.0   0.0   0.0
 15. AS???    ???                                             100.0    60    0.0   0.0   0.0   0.0   0.0
 16. AS20473  45.32.98.222.vultrusercontent.com                0.0%    60  172.5 172.3 172.0 172.5   0.1
 17. AS20473  45.32.100.168                                    0.0%    60  164.7 165.5 164.3 175.0   1.8

• O salto 6 perde 53% das sondas, o salto 7 nenhuma. Se os pacotes se perdessem mesmo no salto 6, todos os saltos seguintes mostrariam também essa perda. O router de Hamburgo limita-se a racionar as respostas.
• O salto 12 perde 82%, com um pior tempo de 381,6 ms e um desvio-padrão de 64,2 ms. O salto imediatamente a seguir responde às 60 sondas com uma dispersão de 0,2 ms, e o destino também responde a todas. Números alarmantes, nenhum problema.
• O salto 10 mostra jitter (pior tempo de 249,9 ms, desvio de 16,1 ms), o salto 11 quase nenhum. Mais uma vez, são as respostas do router, não o caminho.
• O salto 9 responde mais depressa do que o salto 8 (32,3 ms contra 38,1 ms). A latência nos saltos intermédios não tem de crescer: cada router leva o seu próprio tempo a responder.

Todos os alarmes deste rastreio são ruído. O destino, que é aquilo a que de facto se liga, respondeu a 100% das sondas, em 165,5 ms de média.

Rastreio real 2: uma subida brusca que é distância, não um gargalo

No mesmo rastreio, o tempo passa de 32 ms no salto 9 para cerca de 169 ms nos saltos 10 e 11 e mantém-se nesse nível até ao destino. Persiste, logo é real. Mas não é um gargalo: os nomes dos routers passam de cidades europeias (hbg Hamburgo, ffm Frankfurt, prs Paris) para sng, Singapura. Os 137 ms a mais são os cabos submarinos entre a Europa e a Ásia; Singapura fica a cerca de 10.000 km de Falkenstein, o que custa pelo menos 100 ms de ida e volta em fibra, antes de qualquer roteamento.

Uma subida que persiste só é um gargalo se for maior do que a distância justifica, ou se variar com a hora do dia. Compare-a com o mínimo: a cerca de 1 ms de ida e volta por cada 100 km de fibra, 137 ms num salto intercontinental é normal; 137 ms entre dois routers da mesma cidade não é.

Rastreio real 3: um salto em Londres que responde em 298 ms

Para Sydney, a partir do mesmo servidor, no mesmo minuto:

  6. AS24940  core7.lon.hetzner.com                         0.0%    60   22.2  22.1  21.7  22.4   0.1
  7. AS???    ???                                          100.0    60    0.0   0.0   0.0   0.0   0.0
  8. AS4637   i-1001.ulhc-core03.telstraglobal.net          6.7%    60  299.7 298.8 297.6 302.2   0.8
  9. AS4637   i-1045.paix-core02.telstraglobal.net          0.0%    60  297.6 298.7 297.6 299.6   0.6
 10. AS1221   bundle-ether6.stl-core30.sydney.telstra.net   0.0%    60  346.6 345.7 344.6 346.7   0.6
 ...
 16. AS20473  108.61.212.117.vultrusercontent.com           0.0%    60  341.4 341.2 340.9 341.5   0.1

O salto 6 é a Hetzner em Londres, a 22 ms. O salto 8 é onde a Telstra Global (AS4637) assume o tráfego, também em Londres segundo o RIPE IPmap, que geolocaliza routers, e no entanto responde em 298 ms. Um pacote não pode demorar 276 ms a atravessar Londres. O que acontece é que a resposta do router regressa por uma rota diferente, muito mais longa. Cada tempo de um traceroute é uma ida e volta, e o percurso de regresso é-lhe invisível. A subida que interessa aqui é a dos 341 ms do destino, face a um mínimo de 162 ms para os 16.220 km até Sydney: é a rota, não o cabo, que duplica a latência.

Os padrões num relance

O que vê	O que significa	O que fazer
Perda ou atraso num salto, que desaparece no seguinte	O router raciona ou atrasa as respostas	Nada
Perda ou atraso que começa no salto N e dura até ao destino	Um problema real no salto N ou na ligação imediatamente anterior	Reúna provas (ver abaixo) e comunique-o à rede a que pertence o salto N
Uma grande subida que persiste e corresponde à distância	Propagação: um oceano ou um continente	Nada, ou aproxime o servidor dos utilizadores
Uma grande subida, maior do que a distância justifica, ou uma cidade muito fora da linha direta	Um desvio de roteamento	Experimente outro fornecedor ou outro upstream, uma CDN, ou comunique o desvio
Atraso que só aparece nas horas de ponta, a partir de um salto	Congestionamento: uma fila nesse salto	Faça rastreios a horas diferentes e comunique o problema com data e hora
Asteriscos até ao fim, mas o ping responde	O destino ignora esse tipo de sonda	Repita o rastreio com -I (ICMP) ou -T -p 443 (TCP)
Asteriscos do salto N até ao fim, e sem ping	O caminho termina aí, ou uma firewall descarta tudo	Teste a porta do serviço e faça um rastreio a partir de outro local
O problema começa entre os saltos 1 e 3	A sua própria rede ou a sua linha de acesso	Teste por cabo, sem mais nada a correr, e depois ligue ao seu fornecedor de acesso

Localizar o salto

• Os nomes dos routers trazem geralmente um código de cidade ou de aeroporto: nbg Nuremberga, nyk Nova Iorque, hbg Hamburgo, ffm Frankfurt, prs Paris, lon Londres, sng Singapura, tky Tóquio. Execute sem -n para os ver.
• Os números de AS (mtr -z) dizem-lhe a que rede pertence cada salto. Nos rastreios acima: Hetzner AS24940, Arelion AS1299, Telstra Global AS4637, Telstra AS1221, Vultr AS20473. O congestionamento aparece muitas vezes na transição entre duas delas; veja como funcionam os ASN e o roteamento BGP.
• Um mapa torna os desvios evidentes. O TraceMapper coloca cada salto num mapa, com a sua rede e a sua latência.

Provas que levam um fornecedor a agir

• Um relatório mtr -rwzb -c 100 feito enquanto o problema está a acontecer e outro feito quando está tudo bem, para comparação.
• O mesmo teste a partir de outro local. O mesmo host de Nova Jérsia respondeu ao nosso servidor de Falkenstein em 86,4 ms e ao de Gravelines em 71,7 ms, por redes diferentes: comparar pontos de observação diz-lhe se o problema acompanha a sua ligação ou o destino.
• Os dois sentidos, se puder: peça ao outro lado um rastreio de volta até si.
• A data, a hora com o fuso horário, o seu endereço IP público e o destino.

Para ler cada coluna desses relatórios, veja como ler um relatório mtr; para os comandos de cada sistema, o comando traceroute no Windows, Mac e Linux.