interpretazione dei risultati del ping

Sto eseguendo il ping di yahoo.com e sono perplesso dal risultato.

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

Comprendo vagamente il valore TTL come il numero di salti che il pacchetto attraversa per raggiungere la sua destinazione, ma non capisco come TTL possa avere una variazione così drammatica di +/- 1 in così poco tempo.

Inoltre, sembra che Yahoo abbia implementato una sorta di limitazione della velocità poiché un ping persistente inizierà il timeout dopo circa 20 pacchetti. È normale? bing.com non mi risponde nemmeno!

Quando esegui il ping di google.com i TTL sono coerenti.

Quando eseguo il ping di Twitter.com a volte ottengo TTL = 249, ma di solito TTL-58.

Cosa sta succedendo? Il mio ISP non va bene o c'è una spiegazione meno sinistra?

Molto probabilmente ciò è causato dal bilanciamento del carico su più reti. Ogni ping prenderà un percorso diverso e di conseguenza avrà un valore TTL di differenza.

Ho anche letto dei fornitori di motori di ricerca che fanno cose strane con TTL, ma sta solo seguendo una strada diversa in entrambi i modi.

I valori TTL sono diversi quando provengono da diversi sistemi operativi:

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

E sì, alcuni siti smetteranno di rispondere all'ICMP dopo un certo periodo di tempo o quando verrà raggiunto un limite di velocità. Credo che il DNS di Google su 8.8.8.8 alla fine si fermi dopo un po '.

Altri hanno menzionato lo scenario multipath per spiegare la variazione del tempo di ritardo. Con i collegamenti ECMP (Equal Cost Multi Path) è possibile avere uno scenario in base all'output fornito nel ping a Yahoo, in cui il ritardo cambia tra i risultati ma ragionevolmente in modo coerente. Quindi sembra che il tuo traffico sia sottoposto a hash sugli stessi due o tre percorsi, con lunghezze variabili (ritardi) (anche se questa è solo una speculazione, nessuno può dirlo con certezza con le informazioni fornite).

Inoltre, sembra che Yahoo abbia implementato una sorta di limitazione della velocità poiché un ping persistente inizierà il timeout dopo circa 20 pacchetti. È normale? bing.com non mi risponde nemmeno!

Alcune reti filtrano il traffico ICMP che trovo estremamente fastidioso! In modo che potrebbe spiegare lo scenario "nessun ping". Per gli scenari in cui hai alcune risposte o risposte limitate, la rete potrebbe implementare una tecnologia come Cisco Plan Control Policing (o il loro equivalente fornitore).

Quando eseguo il ping di Twitter.com a volte ottengo TTL = 249, ma di solito TTL-58.

Quando si riscontra una variazione dei risultati meno stabile, potrebbero essere presenti percorsi Multi Path a costo diverso o un cambiamento nell'ingegnere del traffico a causa di un problema di collegamento in qualche punto del percorso. Ancora una volta, non posso dire con le informazioni fornite.

La varianza del TTL su questi pacchetti potrebbe essere spiegata da un router che impiega molto tempo per elaborare i pacchetti. Il TTL viene decrementato di uno dopo ogni hop se il tempo attraverso il router è inferiore a un secondo. Se il tempo impiegato attraverso il router è maggiore, un secondo TTL verrà decrementato di due anziché di uno.

Vedi RFC791 pagina 29:

Tempo di vivere

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.