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

Nas mtrpáginas do manual, ele lê:

O mtr combina a funcionalidade dos programas traceroute e ping em uma única ferramenta de diagnóstico de rede

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

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

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

O paralelismo é um dos principais motivos de variação na velocidade dessas ferramentas. Outro fator que contribui é o tempo que eles esperam por uma resposta antes que o salto seja considerado como não respondendo. Se o DNS reverso for executado, você deverá esperar por isso também. O comando plain traceroute fica muito mais rápido se você desabilitar o DNS reverso.

Outra diferença importante, que eu não vi mencionada, é como as duas ferramentas processam a saída. O 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 o mtr pode exibir a saída assim que estiver disponível, porque se as respostas posteriores fizerem com que a saída não seja precisa, o mtr poderá voltar e atualizá-la. Como o traceroute não pode voltar e atualizar a saída, ele precisa esperar até que finalmente decida o que será exibido.

Por exemplo, se o número do salto 2 não estiver respondendo (que é um sintoma que já vi em vários ISPs), o traceroute exibirá o número 1 do salto e espere um pouco antes de exibir os números 2 e 3. Mesmo que a resposta do número do salto 3 chegou, ele não está sendo exibido porque o traceroute ainda aguarda a resposta do número do salto 2. Mtr não possui essa restrição e pode exibir a resposta do número de salto 3 e ainda voltar a exibir a resposta do número de salto 2, se chega mais tarde.

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 perda de pacotes, pois você obtém o mesmo número de respostas com o envio de mais pacotes.

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

Outra diferença está em quantos saltos sem respostas serão exibidos antes que a ferramenta pare de exibir mais saltos. Vi o comando traceroute continuar por tantos saltos quanto solicitado (30 por padrão), enquanto o comando mtr parava assim que passava cinco saltos sem respostas.

O comando traceroute está enviando 3 testes por salto, se você o limitar a 1 teste, -q 1e os resultados se tornarão 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

Eu esperaria que as principais diferenças entre testes comparáveis ​​estivessem 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 esse nem sempre é o caso.

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

mtr descubra os saltos na rota primeiro e depois envie o pacote para cada nó em paralelo.

Parece-me também que há uma diferença na maneira como os mtrmanipuladores não respondem aos ping / probes; ele ignora mais rapidamente do tracerouteque parece enviar seus 3 pacotes o tempo todo, mesmo se as primeiras tentativas falharem em obter resposta.

O principal motivo é 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). Portanto, o tempo total do traceroute inclui o envio e o recebimento de pacotes para cada host, sequencialmente.

mtr, após determinar o caminho que os pacotes seguem, envia todos os pacotes ICMP ECHO em paralelo.