por que o mtr é muito mais rápido que o traceroute?

Question

Nas páginas mtr man, lê-se:

mtr combines the functionality of the traceroute and ping programs in a single network diagnostic tool

Eu uso muito mtr , e acho que é muito mais rápido que traceroute . Instintivamente, mtr me dá a resposta imediatamente, enquanto traceroute lista cada endereço IP a cada segundo. No meu próprio computador, usei time mtr www.google.com e time traceroute www.google.com , o resultado é 21.9s VS 6.1s.

A questão é por quê? Como mtr = ping + traceroute , isso não significa que seja mais lento ou pelo menos igual a traceroute .

Alguém pode me dar uma resposta razoável e detalhada?

    

Answer 1

O paralelismo é uma das principais razões para a variação na velocidade dessas ferramentas. Outro fator que contribui é quanto tempo eles esperam por uma resposta antes que o salto seja considerado como não respondendo. Se o DNS reverso for executado, você terá que esperar por isso também. O comando traceroute simples fica muito mais rápido, se você desabilitar o DNS reverso.

Outra diferença importante, que não vi mencionada, é como as duas ferramentas processam a saída. Traceroute produz a saída em ordem de cima para baixo. O Mtr renderiza a saída de uma maneira diferente, onde o mtr pode voltar e atualizar a saída nas linhas anteriores.

Isso significa que mtr pode exibir a saída assim que estiver disponível, porque se respostas posteriores fizerem com que a saída não seja precisa, o mtr pode voltar e atualizá-la. Como o traceroute não pode voltar e atualizar a saída, ele tem que esperar até que finalmente tenha decidido o que será exibido.

Por exemplo, se o salto número 2 não estiver respondendo (o que é um sintoma que já vi em vários ISPs), o traceroute exibirá o salto número 1 e aguardará algum tempo antes de exibir o salto número 2 e 3. Mesmo que a resposta do hop número 3 chegou, ele não está sendo exibido porque o traceroute ainda está aguardando a resposta do hop número 2. Mtr não tem essa restrição e pode exibir a resposta do hop número 3 e ainda voltar para exibir a resposta do número do hop 2, se chegar depois.

Muito paralelismo pode fazer com que a saída se torne imprecisa. Em alguns cenários, há limites para quantos pacotes você pode obter respostas. Enviar mais pacotes nesses casos não acelerará o processo, mas causará mais pacotes perdidos, já que você recebe o mesmo número de respostas com mais pacotes sendo enviados.

Um exemplo disso é quando um salto na rota não responde a solicitações ARP. Normalmente, o primeiro pacote acionará uma solicitação ARP e, se mais pacotes chegarem antes do tempo limite da solicitação ARP, apenas o último desses pacotes será armazenado em buffer e receberá uma resposta.

Outra diferença está em quantos saltos sem respostas serão exibidos antes que a ferramenta pare de exibir mais saltos. Eu vi o comando traceroute continuar por quantos saltos forem solicitados (30 por padrão), enquanto o comando mtr pararia assim que tivesse passado cinco saltos sem resposta.

    

Answer 2

O comando traceroute está enviando 3 testes por salto se você o limitar a 1 teste -q 1 , então os resultados se tornam comparáveis

time mtr -r -c 1 google.com
.
.
.
real    0m2.640s
user    0m0.003s
sys     0m0.018s


time traceroute6 -q 1 google.com
.
.
.
real    0m0.445s
user    0m0.006s
sys     0m0.007s

Espero que as principais diferenças entre os testes comparáveis estejam relacionadas ao tempo de consulta do DNS e às diferenças de caminho. Você notará que meu traceroute é mais rápido que o mtr, mas nem sempre é o caso.

    

Answer 3

Suponho que isso venha da maneira como o rastreamento de rota é implementado. traceroute enviou pelo menos 3 pacotes para cada salto na rota para o destino, sequencialmente.

mtr descobre primeiro os saltos na rota e depois envia pacotes para cada nó em paralelo.

Parece-me também que há uma diferença na maneira como mtr lida com o salto que não responde ao ping / probes; ele ignora então mais rápido que traceroute , que parece enviar seus 3 pacotes o tempo todo, mesmo que as primeiras tentativas não tenham obtido resposta.

    

Answer 4

A principal razão é a maneira como o traceroute é executado. Ele envia um pacote UDP (ou ICMP no Windows) com um TTL de um para o primeiro host e, quando recebe uma resposta de tempo limite (ou passa um tempo limite interno), gera o próximo pacote para o próximo host com um TTL. de dois, e assim por diante (adicionando um ao TTL para cada host). Assim, o tempo total do traceroute inclui o envio e recebimento de pacotes para cada host, sequencialmente,.

mtr, depois de determinar o caminho dos pacotes, envia todos os pacotes ICMP ECHO em paralelo.