interpretacja wyników ping

Pinguję yahoo.com i jestem zaskoczony wynikiem.

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

Niejasno rozumiem wartość TTL jako liczbę przeskoków, którą pakiet przemierza, aby dotrzeć do miejsca docelowego, ale nie rozumiem, w jaki sposób TTL może mieć tak dramatyczną wariancję +/- 1 w tak krótkim czasie.

Wydaje się również, że Yahoo ma zaimplementowane ograniczenie prędkości, ponieważ trwały ping zacznie przekraczać limit czasu po około 20 pakietach. Czy to normalne? bing.com nawet mi nie odpowiada!

Podczas pingowania google.com TTL są spójne.

Podczas pingowania Twitter.com czasami otrzymuję TTL = 249, ale zwykle TTL-58.

Co się dzieje? Czy mój dostawca usług internetowych nie ma nic dobrego, czy też istnieje mniej złowrogie wytłumaczenie?

Najprawdopodobniej jest to spowodowane równoważeniem obciążenia w wielu sieciach. Każdy ping ma inną ścieżkę i odpowiednio będzie miał różną wartość TTL.

Czytałem również o tym, że dostawcy wyszukiwarek robią dziwne rzeczy z TTL, ale i tak idzie inną drogą.

Wartości TTL są różne, gdy pochodzą z różnych systemów operacyjnych:

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

I tak, niektóre strony przestaną odpowiadać na ICMP po pewnym czasie lub po przekroczeniu limitu prędkości. Uważam, że DNS Google w wersji 8.8.8.8 ostatecznie po pewnym czasie przestaje działać.

Inni wspominali o scenariuszu wielościeżkowym, aby wyjaśnić zmienność czasu opóźnienia. Za pomocą łączy ECMP (Equal Cost Multi Path) można uzyskać scenariusz zgodny z danymi wyjściowymi podanymi w poleceniu ping do Yahoo, w których opóźnienie zmienia się między wynikami, ale w miarę konsekwentnie. Wygląda więc na to, że twój ruch jest mieszany tymi samymi dwiema lub trzema ścieżkami, o różnych długościach (opóźnieniach) (chociaż to tylko spekulacje, nikt nie jest w stanie powiedzieć na pewno o podanych informacjach).

Wydaje się również, że Yahoo ma zaimplementowane ograniczenie prędkości, ponieważ trwały ping zacznie przekraczać limit czasu po około 20 pakietach. Czy to normalne? bing.com nawet mi nie odpowiada!

Niektóre sieci filtrują ruch ICMP, co wydaje mi się bardzo irytujące! To może wyjaśnić scenariusz „w ogóle nie pingować”. W przypadku scenariuszy, w których masz kilka odpowiedzi lub odpowiedzi ograniczone, sieć może wdrażać technologię, taką jak wycena planu kontroli firmy Cisco (lub odpowiednik ich dostawcy).

Podczas pingowania Twitter.com czasami otrzymuję TTL = 249, ale zwykle TTL-58.

Gdy masz mniej stabilną zmienność wyników, mogą występować trasy Multi Path o nierównym koszcie lub zmiana inżyniera ruchu z powodu problemu z łączem w dowolnym miejscu na ścieżce. Ponownie, nie mogę powiedzieć na podstawie podanych informacji.

Odmienność TTL w tych pakietach można wyjaśnić przez router (y), których przetwarzanie zajmuje dużo czasu. TTL jest zmniejszane o jeden po każdym przeskoku, jeśli czas przez router jest krótszy niż jedna sekunda. Jeśli czas przez router jest dłuższy niż jedna sekunda, czas TTL zostanie zmniejszony o dwa, a nie o jeden.

Patrz RFC791 strona 29:

Czas żyć

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.