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

Я pinging 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 даже не отвечает мне!

При pinging google.com TTL совместимы.

Когда я пишу Twitter.com, иногда получаю TTL = 249, но обычно TTL-58.

Что происходит? Является ли мой интернет-провайдер нехорошим или есть менее зловещее объяснение?

11 голосов | спросил jon 5 J000000Friday13 2013, 17:35:27

3 ответа


13

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

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

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

  • Windows: 128
  • Linux: 64
  • Cisco: 255
  • Solaris: 255

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

ответил Artanix 5 J000000Friday13 2013, 17:50:28
5

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

  

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

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

  

Когда я пишу Twitter.com, иногда получаю TTL = 249, но обычно TTL-58.

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

ответил jwbensley 5 J000000Friday13 2013, 23:13:24
3

Отклонение 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.
ответил GerryEgan 5 J000000Friday13 2013, 19:37:40

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132