почему mtr намного быстрее, чем traceroute?

На mtrстраницах руководства это гласит:

mtr объединяет функциональность программ traceroute и ping в одном инструменте диагностики сети

Я mtrмного использую и нахожу, что это намного быстрее, чем traceroute. Инстинктивно, mtrдает мне ответ немедленно, в то время как tracerouteперечислять каждый IP-адрес каждую секунду. На моем собственном компьютере я использовал, time mtr www.google.comи time traceroute www.google.comрезультат равен 21,9 с против 6,1 с.

Вопрос почему? Поскольку mtr = ping + tracerouteэто не значит, что он медленнее или, по крайней мере, такой же, как traceroute.

Может ли кто-нибудь дать мне разумный и подробный ответ?

Параллелизм является основной причиной изменения скорости этих инструментов. Еще одним фактором, способствующим этому, является то, как долго они ждут ответа, прежде чем считается, что прыжок не отвечает. Если выполняется обратный DNS, вы также должны ждать этого. Команда plain traceroute становится намного быстрее, если вы отключите обратный DNS.

Другое важное отличие, о котором я не упомянул, заключается в том, как два инструмента визуализируют вывод. Traceroute производит вывод в порядке сверху вниз. Mtr выводит вывод другим способом, где mtr может вернуться назад и обновить вывод в предыдущих строках.

Это означает, что mtr может отображать вывод, как только он становится доступным, потому что, если более поздние ответы приведут к тому, что вывод не будет точным, mtr может вернуться и обновить его. Так как traceroute не может вернуться назад и обновить вывод, ему приходится ждать, пока он окончательно не решит, что будет отображаться.

Например, если переход № 2 не отвечает (это симптом, который я видел на нескольких интернет-провайдерах), traceroute отобразит номер прыжка 1, а затем подождет некоторое время, прежде чем отобразит номер прыжка 2 и 3. Даже если ответ от номера прыжка 3 прибыл, он не отображается, потому что traceroute все еще ожидает ответа от прыжка номер 2. Mtr не имеет такого ограничения и может отобразить ответ от прыжка номер 3 и все еще вернуться к отображению ответа от прыжка номер 2, если это прибывает позже.

Слишком сильный параллелизм может привести к тому, что вывод станет неточным. В некоторых случаях существуют ограничения на количество пакетов, на которые вы можете получить ответы. Отправка большего количества пакетов в этих случаях не ускорит процесс, однако приведет к большему количеству потерянных пакетов, поскольку вы получаете такое же количество ответов с большим количеством отправляемых пакетов.

Одним из примеров этого является случай, когда переход на маршруте не отвечает на запросы ARP. Обычно первый пакет инициирует запрос ARP, и если большее количество пакетов поступит до истечения времени ожидания запроса ARP, только последний из этих пакетов будет буферизован и получит ответ.

Другое отличие состоит в том, сколько прыжков без ответов будет отображаться до того, как инструмент перестанет отображать больше прыжков. Я видел, как команда traceroute продолжалась столько раз, сколько было запрошено (30 по умолчанию), в то время как команда mtr остановилась, как только прошла пять прыжков без ответов.

Команда traceroute отправляет 3 зонда за переход, если вы ограничите его до 1 зонда, -q 1тогда результаты станут сопоставимыми

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

Я ожидаю, что основные различия между сопоставимыми тестами будут связаны с разницей во времени и пути DNS-запросов. Вы заметите, что мой traceroute быстрее, чем mtr, но это не всегда так.

Я предполагаю, что это происходит из-за того, что трассировка маршрута реализована. tracerouteотправил не менее 3 пакетов для каждого прыжка в маршруте к месту назначения последовательно.

mtr сначала найдите прыжки на маршруте, а затем отправьте пакет на каждый узел параллельно.

Мне также кажется, что есть разница в способах mtrобработки прыжка, не отвечающего на пинг / пробники; затем он игнорирует быстрее, чем tracerouteкажется, что отправляет свои 3 пакета все время, даже если первые попытки не дали ответа.

Основной причиной является способ трассировки. Он отправляет пакет UDP (или ICMP в Windows) с TTL, равным единице, первому хосту, и когда он получает ответ об истечении времени ожидания (или проходит внутренний тайм-аут), он затем генерирует следующий пакет для следующего хоста с TTL. из двух, и так далее (добавление одного к TTL для каждого хоста). Таким образом, общее время traceroute включает отправку и получение пакетов для каждого хоста последовательно.

После определения пути, по которому проходят пакеты, mtr отправляет все пакеты ICMP ECHO параллельно.