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