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

Я пингую 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.

Що відбувається? Чи є мій провайдер нічим не корисним чи є менш зловісне пояснення?

Швидше за все, це пов'язано з балансуванням навантаження в декількох мережах. Кожен ping піде іншим шляхом і відповідно матиме різничне значення TTL.

Я також читав про постачальників пошукових систем, які роблять дивні речі з TTL, але це просто проходить іншим маршрутом в будь-якому випадку.

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

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

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

Інші згадували багатосторонній сценарій для пояснення варіації часу затримки. За посиланнями ECMP (Multi-Path), що мають рівну вартість, у вас може бути сценарій відповідно до результатів, які ви надали в ping для Yahoo, де затримка змінюється між результатами, але досить послідовно. Таким чином, схоже, що ваш трафік хеширується за тими ж двома-трьома шляхами з різною тривалістю (затримкою) (хоча це лише спекуляція, я ніхто не може сказати напевно з наданою інформацією).

Крім того, здається, що Yahoo реалізує певний обмеження швидкості, оскільки стійкий пінг почне розраховуватися приблизно через 20 пакетів. Це нормально? bing.com навіть не відповідає мені!

Деякі мережі фільтрують трафік ICMP, який мені дуже дратує! Тож це могло б пояснити сценарій "взагалі без пінгів". У сценаріях, де у вас є деякі відповіді або обмежені відповіді, мережа може впроваджувати таку технологію, як Cisco Control Plan Policing (або їх еквівалент постачальника).

Під час пінгнгу 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.