¿Por qué mtr es mucho más rápido que traceroute?

En las mtrpáginas del manual, se lee:

mtr combina la funcionalidad de los programas traceroute y ping en una única herramienta de diagnóstico de red

Uso mtrmucho, y descubro que es mucho más rápido que traceroute. Instintivamente, mtrme da la respuesta de forma inmediata, mientras tracerouteenumero cada dirección IP cada segundo. En mi propia computadora, utilicé time mtr www.google.comy time traceroute www.google.com, el resultado es 21.9s VS 6.1s.

La pregunta es por qué. Dado que mtr = ping + traceroute, eso no significa que sea más lento o al menos igual que traceroute.

¿Alguien me puede dar una respuesta razonable y detallada?

El paralelismo es una razón importante para la variación en la velocidad de estas herramientas. Otro factor que contribuye es cuánto tiempo esperan una respuesta antes de que se considere que el salto no responde. Si se realiza DNS inverso, también debe esperar eso. El comando simple traceroute se vuelve mucho más rápido si deshabilita el DNS inverso.

Otra diferencia importante, que no vi mencionada, es cómo las dos herramientas representan la salida. Traceroute produce la salida en orden de arriba hacia abajo. Mtr representa la salida de una manera diferente, donde mtr puede retroceder y actualizar la salida en líneas anteriores.

Esto significa que mtr puede mostrar la salida tan pronto como esté disponible, porque si las respuestas posteriores hacen que la salida no sea precisa, mtr puede regresar y actualizarla. Como traceroute no puede retroceder y actualizar la salida, tiene que esperar hasta que finalmente haya decidido lo que mostrará.

Por ejemplo, si el número de salto 2 no responde (que es un síntoma que he visto en varios ISP), traceroute mostrará el número de salto 1 y luego esperará un momento antes de mostrar los números de salto 2 y 3. A pesar de que la respuesta del número de salto 3 ha llegado, no se muestra porque traceroute todavía está esperando la respuesta del número de salto 2. Mtr no tiene esa restricción y puede mostrar la respuesta del número de salto 3 y aún volver para mostrar la respuesta del número de salto 2, si llega más tarde

Demasiado paralelismo puede hacer que la salida se vuelva inexacta. En algunos escenarios, hay límites para la cantidad de paquetes para los que puede obtener respuestas. Enviar más paquetes en esos casos no acelerará el proceso, sin embargo, causará más paquetes perdidos, ya que obtendrá el mismo número de respuestas con más paquetes enviados.

Un ejemplo de esto es cuando un salto en la ruta no responde a las solicitudes ARP. Por lo general, el primer paquete activará una solicitud ARP, y si llegan más paquetes antes de que se agote el tiempo de la solicitud ARP, solo el último de esos paquetes se almacenará en el búfer y obtendrá una respuesta.

Otra diferencia está en cuántos saltos sin respuestas se mostrarán antes de que la herramienta deje de mostrar más saltos. He visto que el comando traceroute continúa durante tantos saltos como se solicitó (30 por defecto), mientras que el comando mtr se detendría tan pronto como hubiera pasado cinco saltos sin respuestas.

El comando traceroute envía 3 sondas por salto si lo limita a 1 sonda -q 1y los resultados se vuelven comparables

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

Esperaría que las principales diferencias entre pruebas comparables estén relacionadas con el tiempo de consulta DNS y las diferencias de ruta. Notarás que mi traceroute es más rápido que el mtr, pero este no es siempre el caso.

Supongo que esto proviene de la forma en que se implementa el rastreo de ruta. tracerouteenvió al menos 3 paquetes por cada salto en la ruta al destino, secuencialmente.

mtr descubra primero los saltos en la ruta y luego envíe el paquete a cada nodo en paralelo.

También me parece que hay una diferencia en la forma en que los mtrcontroladores de salto no responden a ping / sondas; ignora entonces más rápido de lo tracerouteque parece enviar sus 3 paquetes todo el tiempo, incluso si los primeros intentos no obtuvieron respuesta.

La razón principal es la forma en que se ejecuta traceroute. Envía un paquete UDP (o ICMP en Windows) con un TTL de uno al primer host, y cuando recibe una respuesta de tiempo de espera (o pasa un tiempo de espera interno), genera el siguiente paquete para el siguiente host con un TTL de dos, y así sucesivamente (agregando uno al TTL para cada host). Por lo tanto, el tiempo total de traceroute incluye el envío y la recepción de paquetes para cada host, secuencialmente.

mtr, después de determinar la ruta que toman los paquetes, envía todos los paquetes ICMP ECHO en paralelo.