На самом деле traceroute в современном Linux имеет опции, которые соответствуют поведению mtr (и наоборот). Мы видим, что это вопрос только по умолчанию.
traceroute был оригиналом. Детали оригинального метода могут быть выведены из документации, но это не было сочтено необходимым разъяснить его. Так как в трассировке Linux добавлено несколько опций, различия описаны.
дефолт
Традиционный, древний метод трассировки. Используется по умолчанию.
Пробные пакеты - это дейтаграммы udp с так называемыми "маловероятными" портами назначения. "Невероятный" порт первого зонда - 33434, затем для каждого следующего зонда он увеличивается на единицу.
ICMP
Самый обычный метод, который использует эхо-пакеты icmp для зондов.
Если вы можете пропинговать (8) хост назначения, трассировка icmp также применима.
По умолчанию mtr выглядит как icmp, "самый обычный метод на данный момент".
Заключение
многолучевая маршрутизация, как ожидается, сохранит пакеты от одного и того же соединения на одном и том же пути. Это позволяет избежать доставки не по назначению, что может быть весьма нежелательным. Это делается путем просмотра адреса и порта источника и назначения. (Вместе с протоколом. Эти значения описаны как «5-кортеж»).
По умолчанию traceroute меняет порт UDP для каждого зонда, поэтому они меняют пути.
По умолчанию mtr использует эхо ICMP, у которого нет номера порта, и поэтому все его зонды будут следовать по одному и тому же пути.
Если вы запрашиваете трассировку UDP или TCP в mtr то отображаются разные пути. Могут быть другие различия по сравнению с traceroute , но в этом отношении он ведет себя аналогично.
Sidetrack: почему не использовался icmp?
Таким образом, traceroute Linux намеренно остается верным оригиналу, включая выбор режима по умолчанию. Но причина первоначального выбора не совсем понятна.
Я вспомнил, как читал man tracepath:
коммерческие маршрутизаторы [IPv4] не возвращают достаточно информации в сообщениях об ошибках icmp. Возможно, это изменится, когда они будут обновлены. На данный момент [tracepath] использует трюк Ван Якобсона, охватывающий диапазон портов UDP для поддержания истории трассировки.
однако суть в том, что tracepath использует более новые средства, чтобы избежать требования привилегий root. Упомянутая проблема заключается в том, что ответы об ошибках ICMP не будут включать в себя какую-либо полезную нагрузку пакета UDP . Полезная нагрузка эхо-пакета ICMP будет включена (но для генерации таких проб требуется root).
Traceroute изменяет (увеличивает) номер порта назначения UDP для каждого отправленного зонда, чтобы надежно сопоставлять сообщения ICMP TTL Exceeded с отдельными зондами. Поскольку порты UDP появляются сразу после заголовка IP, на них можно положиться, чтобы включить их в часть "исходного пакета" сообщений ICMP TTL Exceeded, хотя стандарты ICMP только предписывают, чтобы первые восемь октетов следовали за заголовком IP исходный пакет должен быть включен в сообщения ICMP (хотя разрешено отправлять больше).
Когда используются запросы ICMP ECHO, можно устранить неоднозначность зондов, используя поле порядкового номера, которое также находится непосредственно перед этой 8-октетной границей.
PERT продолжает предлагать
Считается, что это происходит потому, что в то время некоторые шлюзы (как тогда назывались маршрутизаторы) отказывались отправлять сообщения ICMP (превышено TTL) в ответ на сообщения ICMP, как указано во введении RFC 792, "Протокол управляющих сообщений Интернета" , Поэтому вариант UDP был более надежным.
Комментарии исходного кода также объясняют использование порта UDP, но не использование UDP поверх ICMP-эхо. Строгое чтение предполагает еще одну возможность
поскольку ICMP не отправляются для ICMP
В контексте дело в том, что ошибки icmp никогда не отправляются в ответ на ответ icmp, чтобы избежать бесконечного цикла ответов. Конечно, вполне вероятно, что реализации будут применять это ко всем пакетам icmp, а не только к ответам. В комментариях также упоминаются различные ошибки реализации, которые пользователи должны были учитывать, чтобы интерпретировать результат traceroute.
Однако также возможно, что Ван Якобсон сам с этим не согласен. Можно просто предположить, что ошибки icmp не будут возвращены ни для одного пакета icmp, упуская из виду, что это не обязательно относится к эхо-запросам icmp.
Не используйте это как пример кодирования. Я пытался найти проблему с маршрутизацией, и этот код выскочил через 48 часов без сна. Я был поражен тем, что он когда-либо компилировался, а тем более бегал.
