interpretando resultados de ping

Estou pingando yahoo.com e estou intrigado com o resultado.

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

Eu entendo vagamente o valor TTL como o número de saltos que o pacote percorre para chegar ao seu destino, mas não entendo como o TTL pode ter uma variação tão dramática de +/- 1 em um período tão curto de tempo.

Além disso, parece que o Yahoo tem algum tipo de limitação de taxa implementado, pois um ping persistente começará a atingir o tempo limite após cerca de 20 pacotes. Isso é normal? O bing.com nem me responde!

Ao executar ping no google.com, os TTLs são consistentes.

Às vezes, quando faço ping no Twitter.com, recebo TTL = 249, mas geralmente TTL-58.

O que está acontecendo? Meu ISP não serve para nada ou existe uma explicação menos sinistra?

Provavelmente, isso é causado pelo balanceamento de carga em várias redes. Cada ping seguirá um caminho diferente e, consequentemente, terá um valor TTL diferente.

Também li sobre provedores de mecanismos de pesquisa que fazem coisas estranhas com o TTL, mas está apenas passando por uma rota diferente de qualquer maneira.

Os valores TTL são diferentes quando provenientes de diferentes sistemas operacionais:

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

E sim, alguns sites param de responder ao ICMP após um certo período de tempo ou quando um limite de taxa é atingido. Acredito que o DNS do Google no 8.8.8.8 acabe parando depois de um tempo.

Outros mencionaram o cenário de caminhos múltiplos para explicar a variação no tempo de atraso. Com os links ECMP (Equal Cost Multi Path), você pode ter um cenário conforme a saída que você forneceu no ping para o Yahoo, onde o atraso muda entre os resultados, mas de maneira razoavelmente consistente. Parece que seu tráfego está sendo dividido em hash pelos mesmos dois ou três caminhos, com comprimentos variados (atrasos) (embora isso seja apenas especulação, ninguém pode dizer ao certo com as informações fornecidas).

Além disso, parece que o Yahoo tem algum tipo de limitação de taxa implementado, pois um ping persistente começará a atingir o tempo limite após cerca de 20 pacotes. Isso é normal? O bing.com nem me responde!

Algumas redes filtram o tráfego ICMP, o que eu acho extremamente irritante! Então, isso poderia explicar o cenário "nada de pings". Para cenários em que você tem algumas respostas ou respostas limitadas, a rede pode estar implementando uma tecnologia como o Policiamento do Plano de Controle da Cisco (ou o equivalente de seu fornecedor).

Às vezes, quando faço ping no Twitter.com, recebo TTL = 249, mas geralmente TTL-58.

Quando você está tendo uma variação de resultados menos estável, rotas com vários caminhos diferentes de custo igual podem estar presentes ou uma alteração no engenheiro de tráfego devido a um problema de link em algum lugar do caminho. Novamente, não posso dizer com as informações fornecidas.

A variação do TTL nesses pacotes pode ser explicada por um roteador que está demorando muito tempo para processar os pacotes. O TTL é decrementado em um após cada salto, se o tempo no roteador for menor que um segundo. Se o tempo gasto no roteador for maior, o TTL de um segundo será diminuído em dois em vez de um.

Consulte a página 29 da RFC791 :

Tempo de Viver

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.