интерпретация результатов пинга

Я пингую yahoo.com и озадачен результатом.

C:\Users\jon>ping -t yahoo.com

Pinging yahoo.com [98.138.253.109] with 32 bytes of data:
Reply from 98.138.253.109: bytes=32 time=195ms TTL=46
Reply from 98.138.253.109: bytes=32 time=230ms TTL=44
Reply from 98.138.253.109: bytes=32 time=175ms TTL=45
Reply from 98.138.253.109: bytes=32 time=208ms TTL=44
Reply from 98.138.253.109: bytes=32 time=180ms TTL=46
Reply from 98.138.253.109: bytes=32 time=206ms TTL=44
Reply from 98.138.253.109: bytes=32 time=209ms TTL=44
Reply from 98.138.253.109: bytes=32 time=173ms TTL=46
Reply from 98.138.253.109: bytes=32 time=170ms TTL=46
Reply from 98.138.253.109: bytes=32 time=224ms TTL=45
Reply from 98.138.253.109: bytes=32 time=200ms TTL=45
Reply from 98.138.253.109: bytes=32 time=172ms TTL=46
Reply from 98.138.253.109: bytes=32 time=258ms TTL=44

Я смутно понимаю значение TTL как число прыжков, которое пакет проходит, чтобы достичь своего места назначения, но я не понимаю, как у TTL может быть такая резкая разница +/- 1 за такой короткий промежуток времени.

Кроме того, похоже, что в Yahoo реализовано какое-то ограничение скорости, так как постоянный пинг начнет отсчитываться примерно через 20 пакетов. Это нормально? bing.com даже не отвечает мне!

При пинге google.com TTL соответствуют друг другу.

При пинге на Twitter.com иногда получается TTL = 249, но обычно TTL-58.

Что происходит? У моего провайдера ничего хорошего или менее зловещее объяснение?

Скорее всего, это связано с балансировкой нагрузки в нескольких сетях. Каждый пинг будет проходить по разному пути и соответственно будет иметь разное значение TTL.

Я также читал о том, что провайдеры поисковых систем делают странные вещи с TTL, но в любом случае это просто другой путь.

Значения TTL различаются при использовании из разных операционных систем:

• Windows: 128
• Linux: 64
• Cisco: 255
• Солярис: 255

И да, некоторые сайты перестают отвечать на ICMP через определенное время или при достижении ограничения скорости. Я полагаю, что DNS Google на 8.8.8.8 в конечном счете останавливается через некоторое время.

Другие упоминали сценарий многолучевого распространения, чтобы объяснить изменение времени задержки. Со ссылками ECMP (Equal Cost Multi Path) у вас может быть сценарий в соответствии с выводом, который вы предоставили в ping для Yahoo, где задержка изменяется между результатами, но достаточно последовательно. Таким образом, похоже, что ваш трафик хэшируется по одним и тем же двум или трем путям с различной длиной (задержками) (хотя это всего лишь предположение, я точно не могу сказать с предоставленной информацией).

Кроме того, похоже, что в Yahoo реализовано какое-то ограничение скорости, так как постоянный пинг начнет отсчитываться примерно через 20 пакетов. Это нормально? bing.com даже не отвечает мне!

Некоторые сети фильтруют трафик ICMP, что меня очень раздражает! Так что это может объяснить сценарий «вообще не пингует». Для сценариев, в которых у вас есть некоторые ответы или ограниченные ответы, сеть может реализовывать такую ​​технологию, как применение политик Cisco Control Plan (или эквивалент их поставщика).

При пинге на Twitter.com иногда получается TTL = 249, но обычно TTL-58.

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

Дисперсия TTL в этих пакетах может быть объяснена маршрутизатором (-ами), которые занимают много времени для обработки пакетов. TTL уменьшается на единицу после каждого прыжка, если время прохождения через маршрутизатор меньше одной секунды. Если время, пройденное через маршрутизатор, больше, чем одна секунда, TTL будет уменьшен на два, а не на один.

См. RFC791, стр. 29:

Время жить

The time to live is set by the sender to the maximum time the
datagram is allowed to be in the internet system.  If the datagram
is in the internet system longer than the time to live, then the
datagram must be destroyed.

This field must be decreased at each point that the internet header
is processed to reflect the time spent processing the datagram.
Even if no local information is available on the time actually
spent, the field must be decremented by 1.  The time is measured in
units of seconds (i.e. the value 1 means one second).  Thus, the
maximum time to live is 255 seconds or 4.25 minutes.  Since every
module that processes a datagram must decrease the TTL by at least
one even if it process the datagram in less than a second, the TTL
must be thought of only as an upper bound on the time a datagram may
exist.  The intention is to cause undeliverable datagrams to be
discarded, and to bound the maximum datagram lifetime.

Some higher level reliable connection protocols are based on
assumptions that old duplicate datagrams will not arrive after a
certain time elapses.  The TTL is a way for such protocols to have
an assurance that their assumption is met.