%2C%20%D1%87%D0%B5%D0%BC%20%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D1%8B%20ICMP%20%D1%81%20%D0%BF%D1%80%D0%B5%D0%B2%D1%8B%D1%88%D0%B5%D0%BD%D0%B8%D0%B5%D0%BC%20%D0%B2%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%B8.png)
Когда япинг the последние три прыжкатрассировки маршрута до facebook.com из моего местоположения, все пакеты ICMP echo-reply, которые я получаю, имеютТТЛсоответственно58, 57 и 56. Речь идет о 6-м, 7-м и 8-м прыжках с моей машины.
С другой стороны,TTL сообщений ICMP о превышении временидля пакетов, срок действия которых истекает на этих трех участках, все имеют разумные значения: 246, 248, 249.
СейчасОбратный путьвполне может быть не таким же, какпрямой путьи оно может быть разным для сообщений ICMP разных типов.
Но откуда могла взяться такая разница? 200-прыжковыйциклпо пути? Или пакеты эхо-ответа ICMP генерируются с низким TTL (гораздо ниже 255: такое вообще бывает?)?
решение1
Как предложил пользователь kwaio, значение TTL по умолчанию (или общее) для использования при генерацииICMP эхо-запросиэхо-ответпакеты — это 64.
В моем случае первые маршрутизаторы на выбранном мной пути ответили сообщением эхо-ответа с TTL=255 (в источнике), а последние — с TTL=64.
Вместо этого кажется, чтоПревышено время ICMPВо всех случаях сообщения создавались с TTL 255.
После некоторых поисков я обнаружил, что разные поставщики и разные ОС используют разные начальные значения TTL для разных протоколов: binbert.com/blog/2009/12/default-time-to-live-ttl-values
Интересным следствием этого является то, что вы можете определить производителя данного маршрутизатора, дав пакету истечь на нем и отправив ему ping. Подробнее здесь: Дактилоскопия на основе TTL и MPLSи полная статья:«Сетевая идентификация: сигнатуры маршрутизаторов на основе TTL».