O que é Traceroute e MTR?

Entenda o que é o Traceroute e MTR, como funcionam e quando usar cada um para diagnosticar rotas, latência e perda de pacotes na internet brasileira.

Equipa Dig TraceEquipa Dig Trace· Equipa de Engenharia de Redes7 min de leitura
O que é Traceroute e MTR?

Traceroute e MTR são ferramentas de diagnóstico de rede que mapeiam o caminho percorrido pelos pacotes de dados entre sua máquina e um destino na internet. Enquanto o traceroute oferece uma fotografia instantânea da rota, o MTR combina essa descoberta com monitoramento contínuo, semelhante ao ping, para revelar instabilidades que uma única execução não conseguiria detectar.

O que é Traceroute?

Traceroute (ou tracert no Windows) é um utilitário presente na maioria dos sistemas operacionais. Ele envia pacotes de teste para um endereço de destino e registra cada roteador intermediário, chamado de hop ou salto, junto com o tempo de ida e volta de cada etapa. O resultado é uma lista sequencial de IPs e tempos de resposta.

A ferramenta é útil para visualizar por onde o tráfego está saindo. Ao rastrear uma conexão de São Paulo até um servidor em Miami, por exemplo, é possível identificar o exato ponto onde os pacotes deixam a infraestrutura brasileira e entram no link internacional. Essa visão estática, porém, tem limitações. Como o traceroute executa apenas uma rodada de sondas por salto, ele pode deixar passar problemas intermitentes que acontecem entre uma execução e outra.

O que é MTR?

MTR, sigla para My Traceroute, é uma ferramenta que funde o mapeamento de rotas do traceroute com estatísticas contínuas de desempenho. Depois de descobrir os hops, o MTR continua enviando sondas para cada um deles simultaneamente, atualizando em tempo real métricas como perda de pacotes, latência média, melhor e pior tempo, e desvio padrão.

Esse comportamento faz do MTR um painel vivo da conexão. Em vez de três amostras por salto, ele pode coletar centenas ao longo de minutos. Isso é essencial para diagnosticar congestionamentos esporádicos em provedores de internet ou em pontos de troca de tráfego no Brasil, onde a instabilidade pode aparecer apenas em horários de pico.

Como funcionam essas ferramentas?

O mecanismo central é o campo TTL (Time to Live), presente no cabeçalho de todo pacote IP. O TTL funciona como um contador regressivo. Cada roteador que encaminha o pacote diminui esse valor em uma unidade. Quando o TTL chega a zero, o roteador descarta o pacote e devolve uma mensagem ICMP do tipo 11 (Time Exceeded) para a origem. Essa resposta revela o endereço IP do roteador.

O traceroute começa enviando pacotes com TTL igual a 1. O primeiro roteador na rede local decrementa para zero e responde. Na rodada seguinte, o TTL vai para 2, expondo o segundo salto. O processo se repete, incrementando de um em um, até que os pacotes alcancem o destino final ou atinjam o limite máximo de saltos, geralmente 30.

O MTR utiliza o mesmo princípio para descobrir a rota inicialmente. Contudo, assim que o caminho está mapeado, ele passa a enviar sondas paralelas para todos os hops de uma só vez. A maioria das implementações usa ICMP por padrão, mas tanto o traceroute quanto o MTR permitem alternar para UDP ou TCP. Essa flexibilidade ajuda a contornar firewalls que bloqueiam ICMP mas permitem tráfego TCP em portas comuns.

Traceroute ou MTR: qual usar?

A escolha depende do tipo de problema que você está investigando. O traceroute é mais leve e rápido. Ele responde bem à pergunta "qual é a rota até o destino?" e já mostra se existe algum salto com latência anormalmente alta. Para um teste pontual, ele é suficiente.

O MTR entra em cena quando há suspeita de perda de pacotes ou variação de latência. Por coletar dados continuamente, ele consegue identificar falhas intermitentes que um traceroute isolado simplesmente não veria. No entanto, é preciso interpretar os resultados com cuidado. Em redes de grandes provedores brasileiros, roteadores intermediários frequentemente aplicam rate-limiting em mensagens ICMP para proteger o plano de controle. Isso pode fazer o MTR exibir perda de pacotes em hops do meio do caminho, mesmo quando a conexão com o destino final está perfeita.

Atenção: perda de pacotes visível apenas em hops intermediários, com o destino respondendo normalmente, geralmente indica limitação de taxa ICMP e não um defeito real na conexão. Sempre confirme com testes de ping fim a fim.

Ferramentas online como a ferramenta de traceroute do Digtrace e o teste de MTR online permitem executar esses diagnósticos diretamente pelo navegador, sem necessidade de terminal. Isso é prático para usuários finais ou equipes de suporte que precisam coletar evidências rapidamente.

Como executar e ler os resultados

No Linux ou macOS, um traceroute básico para um domínio brasileiro fica assim:

# Executa traceroute sem resolver nomes para maior velocidade
traceroute -n globo.com

A saída típica mostra cada salto numerado, o IP do roteador e três tempos de resposta em milissegundos:

traceroute to globo.com (186.192.90.5), 30 hops max, 60 byte packets
 1  192.168.1.1   1.2 ms   1.1 ms   1.3 ms
 2  10.20.0.1     5.4 ms   5.2 ms   5.5 ms
 3  * * *
 4  186.192.90.5  15.1 ms  14.9 ms  15.2 ms

O asterisco no terceiro salto indica que aquele roteador não respondeu dentro do tempo limite. Pode ser uma falha, mas também pode ser apenas um filtro de ICMP. Não é motivo para conclusões precipitadas.

Para obter uma visão estatística com o MTR, o modo de relatório é ideal para enviar dados a um provedor ou equipe de infraestrutura:

# Gera relatório com 100 ciclos de sondas
mtr --report -n --cycles 100 globo.com

A tabela resultante exibe colunas como Loss% (percentual de perda), Last (último tempo), Avg (média), Best (melhor), Wrst (pior) e StDev (desvio padrão). Um alto desvio padrão em um hop específico costuma sinalizar jitter, ou seja, variação irregular na latência.

Diagnóstico na prática no Brasil

No contexto da internet brasileira, traceroute e MTR são ferramentas indispensáveis tanto para profissionais de TI quanto para usuários avançados. Quando um site hospedado fora do país fica lento, o traceroute ajuda a identificar se o gargalo está no link internacional, no peering entre operadoras ou na rede de acesso do usuário.

Empresas que utilizam serviços de hospedagem nacional frequentemente precisam abrir chamados técnicos. Enviar a saída de um MTR em modo relatório fornece ao suporte dados objetivos de latência e perda por salto, acelerando a resolução do problema.

Outra aplicação comum é no universo dos jogos online e streaming. Jogadores que enfrentam lag em servidores estrangeiros podem usar o MTR para verificar se a instabilidade ocorre em um ponto específico da rota. Se a perda de pacotes se concentra em um hop intermediário, o usuário tem evidências concretas para reportar à operadora.

Para um diagnóstico robusto, recomenda-se executar os testes a partir de múltiplos pontos de vista: da máquina do cliente, do servidor de destino e, se possível, de um ponto neutro na rede. Isso ajuda a isolar se o problema está no caminho de ida, no de volta, ou em ambos.

Por fim, é válido lembrar que nenhuma ferramenta de rede opera isoladamente. Traceroute e MTR mapeiam a camada 3 do modelo OSI, mas não revelam problemas de DNS, aplicação ou camada física. Para uma visão completa, combine esses testes com consultas DNS e testes de ping fim a fim. O guia da Cloudflare sobre MTR e o artigo da APNIC sobre interpretação de resultados são referências complementares sólidas para quem quer aprofundar a análise.