dlaczego mtr jest znacznie szybszy niż traceroute?

Na mtrstronach podręcznika czytamy:

mtr łączy funkcjonalność programów traceroute i ping w jednym sieciowym narzędziu diagnostycznym

Używam mtrdużo i stwierdzam, że jest o wiele szybszy niż traceroute. Instynktownie mtrdaje mi natychmiastową odpowiedź, a traceroutelistę adresów IP co sekundę. Użyłem na własnym komputerze, time mtr www.google.coma time traceroute www.google.comwynik to 21,9s vs 6.1s.

Pytanie brzmi dlaczego? Ponieważ mtr = ping + traceroutenie oznacza to, że jest wolniejszy lub przynajmniej taki sam jak traceroute.

Czy ktoś może dać mi rozsądną i szczegółową odpowiedź?

Równoległość jest głównym powodem różnic w szybkości tych narzędzi. Kolejnym czynnikiem jest to, jak długo czekają na odpowiedź, zanim przeskok nie zostanie uznany za odpowiadający. Jeśli wykonywane jest odwrotne DNS, musisz również na to poczekać. Zwykłe polecenie traceroute staje się znacznie szybsze, jeśli wyłączysz odwrotny DNS.

Inną ważną różnicą, o której nie wspomniałem, jest sposób, w jaki oba narzędzia wyświetlają dane wyjściowe. Traceroute produkuje dane wyjściowe w kolejności od góry do dołu. Mtr renderuje dane wyjściowe w inny sposób, gdzie mtr może wrócić i zaktualizować dane wyjściowe w poprzednich liniach.

Oznacza to, że mtr może wyświetlić dane wyjściowe, gdy tylko będą dostępne, ponieważ jeśli późniejsze odpowiedzi spowodują, że dane wyjściowe nie będą dokładne, mtr może wrócić i je zaktualizować. Ponieważ traceroute nie może wrócić i zaktualizować danych wyjściowych, musi poczekać, aż ostatecznie zdecyduje, co wyświetli.

Na przykład, jeśli skok nr 2 nie odpowiada (co jest symptomem, który widziałem u wielu dostawców usług internetowych), traceroute wyświetli skok nr 1, a następnie zaczeka chwilę, zanim wyświetli skok nr 2 i 3. Mimo że odpowiedź z numeru skoku 3 przybył, nie jest wyświetlany, ponieważ traceroute nadal czeka na odpowiedź z przeskoku nr 2. Mtr nie ma tego ograniczenia i może wyświetlić odpowiedź z przeskoku nr 3 i nadal wracać, aby wyświetlić odpowiedź z przeskoku nr 2, jeśli przybywa później.

Zbyt duża równoległość może spowodować, że dane wyjściowe staną się niedokładne. W niektórych scenariuszach istnieją ograniczenia dotyczące liczby pakietów, dla których można uzyskać odpowiedzi. Wysłanie większej liczby pakietów w tych przypadkach nie przyspieszy procesu, spowoduje jednak więcej utraconych pakietów, ponieważ otrzymujesz taką samą liczbę odpowiedzi i wysyłanych jest więcej pakietów.

Jednym z przykładów jest to, że przeskok na trasie nie odpowiada na żądania ARP. Zwykle pierwszy pakiet wyzwala żądanie ARP, a jeśli więcej pakietów dotrze przed upływem terminu ARP, tylko ostatni z tych pakietów zostanie zbuforowany i otrzyma odpowiedź.

Kolejna różnica polega na tym, ile przeskoków bez odpowiedzi zostanie wyświetlonych, zanim narzędzie przestanie wyświetlać więcej przeskoków. Widziałem, że polecenie traceroute kontynuuje tyle przeskoków, ile zażądano (domyślnie 30), podczas gdy polecenie mtr zatrzyma się, gdy tylko przejdzie pięć przeskoków bez odpowiedzi.

Polecenie traceroute wysyła 3 sondy na przeskok, jeśli ograniczysz go do 1 sondy, -q 1wyniki staną się porównywalne

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

Spodziewałbym się, że główne różnice między porównywalnymi testami będą związane z czasem zapytania DNS i różnicami ścieżek. Zauważysz, że mój traceroute jest szybszy niż mtr, ale nie zawsze tak jest.

Przypuszczam, że wynika to ze sposobu, w jaki śledzenie trasy jest realizowane. traceroutewysłał co najmniej 3 pakiety dla każdego przeskoku na trasie do miejsca docelowego, kolejno.

mtr najpierw odkryj przeskok na trasie, a następnie wyślij pakiet równolegle do każdego węzła.

Wydaje mi się również, że istnieje różnica w sposobie, w jaki mtruchwyty hop nie reagują na ping / sondy; ignoruje wtedy szybsze, niż traceroutewydaje się, że cały czas wysyła 3 pakiety, nawet jeśli pierwsze próby nie dały odpowiedzi.

Głównym powodem jest sposób działania traceroute. Wysyła pakiet UDP (lub ICMP w systemie Windows) z TTL wynoszącym jeden do pierwszego hosta, a gdy otrzymuje odpowiedź o przekroczeniu limitu czasu (lub mija wewnętrzny limit czasu), następnie generuje następny pakiet dla następnego hosta z TTL z dwóch itd. (dodanie jednego do TTL dla każdego hosta). Tak więc całkowity czas traceroute obejmuje sekwencyjne wysyłanie i odbieranie pakietów dla każdego hosta.

mtr, po określeniu ścieżki, którą podążają pakiety, wysyła wszystkie pakiety ICMP ECHO równolegle.