Почему 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,
Может ли кто-нибудь дать мне разумный и подробный ответ?
4 ответа
Параллелизм является основной причиной изменения скорости этих инструментов. Еще одним фактором, способствующим этому, является то, как долго они ждут ответа, прежде чем считается, что прыжок не отвечает. Если выполняется обратный 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 параллельно.