perché mtr è molto più veloce di traceroute?

Nelle mtrpagine man si legge:

mtr combina le funzionalità dei programmi traceroute e ping in un unico strumento diagnostico di rete

Uso mtrmolto e trovo che sia molto più veloce di traceroute. Istintivamente, mtrmi dà la risposta emidiatamente, mentre tracerouteelenco ogni indirizzo IP ogni secondo. Sul mio computer, ho usato time mtr www.google.come time traceroute www.google.com, il risultato è 21.9s VS 6.1s.

La domanda è: perché? Da allora mtr = ping + traceroute, ciò non significa che sia più lento o almeno uguale a traceroute.

Qualcuno può darmi una risposta ragionevole e dettagliata?

Il parallelismo è una delle ragioni principali della variazione della velocità di questi strumenti. Un altro fattore che contribuisce è il tempo di attesa per una risposta prima che l'hop sia considerato non rispondere. Se viene eseguito DNS inverso, è necessario attendere anche quello. Il semplice comando traceroute diventa molto più veloce se si disabilita il DNS inverso.

Un'altra differenza importante, che non ho visto menzionato, è come i due strumenti rendono l'output. Traceroute produce l'output in ordine dall'alto verso il basso. Mtr esegue il rendering dell'output in un modo diverso, in cui mtr può tornare indietro e aggiornare l'output sulle righe precedenti.

Ciò significa che mtr può visualizzare l'output non appena è disponibile, poiché se le risposte successive rendono tale output non accurato, mtr può tornare indietro e aggiornarlo. Dal momento che traceroute non può tornare indietro e aggiornare l'output, deve attendere fino a quando non ha deciso che cosa verrà visualizzato.

Ad esempio se l'hop numero 2 non risponde (che è un sintomo che ho visto su più ISP), traceroute visualizzerà l'hop numero 1 e quindi attenderà qualche istante prima di visualizzare l'hop numero 2 e 3. Anche se la risposta dal numero hop 3 è arrivato, non viene visualizzato perché traceroute sta ancora aspettando la risposta dal numero di hop 2. Mtr non ha questa limitazione e può visualizzare la risposta dal numero di hop 3 e tornare indietro per visualizzare la risposta dal numero di hop 2, se arriva più tardi.

Troppo parallelismo può rendere inaccurato l'output. In alcuni scenari ci sono limiti al numero di pacchetti per i quali è possibile ottenere risposte. L'invio di più pacchetti in questi casi non accelererà il processo, ma causerà più pacchetti persi, poiché si ottiene lo stesso numero di risposte con più pacchetti inviati.

Un esempio di ciò è quando un hop sulla rotta non risponde alle richieste ARP. Di solito il primo pacchetto attiverà una richiesta ARP e, se arrivano più pacchetti prima del timeout della richiesta ARP, solo l'ultimo di tali pacchetti verrà bufferizzato e riceverà una risposta.

Un'altra differenza è in quanti hop senza risposte verranno visualizzati prima che lo strumento smetta di visualizzare più hop. Ho visto il comando traceroute continuare per tutti gli hop richiesti (30 per impostazione predefinita), mentre il comando mtr si fermerebbe non appena avesse superato cinque hop senza risposta.

Il comando traceroute invia 3 sonde per hop se lo si limita a 1 sonda, -q 1i risultati diventano comparabili

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

Mi aspetto che le principali differenze tra test comparabili siano correlate al tempo di query DNS e alle differenze di percorso. Noterai che il mio traceroute è più veloce di mtr, ma non è sempre così.

Suppongo che questo provenga dal modo in cui viene implementata la traccia del percorso. tracerouteinviato almeno 3 pacchetti per ciascun hop nel percorso verso la destinazione, in sequenza.

mtr scopri prima i luppoli nel percorso, quindi invia il pacchetto a ciascun nodo in parallelo.

Mi sembra anche che ci sia una differenza nel modo in cui mtrgestisce l'hop non risponde al ping / sonde; ignora quindi più rapidamente di quanto traceroutesembri inviare i suoi 3 pacchetti in continuazione, anche se i primi tentativi non sono riusciti a ottenere risposta.

Il motivo principale è il modo in cui funziona traceroute. Invia un pacchetto UDP (o ICMP su Windows) con un TTL di uno al primo host e quando riceve una risposta di timeout (o passa un timeout interno), quindi genera il pacchetto successivo per l'host successivo con un TTL di due e così via (aggiungendo uno al TTL per ciascun host). Quindi il tempo totale di traceroute include l'invio e la ricezione di pacchetti per ciascun host, in sequenza.

mtr, dopo aver determinato il percorso seguito dai pacchetti, invia tutti i pacchetti ECHO ICMP in parallelo.