ping結果の解釈

私はyahoo.comにpingを実行していますが、結果に戸惑っています。

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では永続的なpingが約20パケット後にタイムアウトを開始するため、何らかのレート制限が実装されているようです。これは正常ですか？bing.comは私にも返信しません！

google.comにpingするとき、TTLは一貫しています。

Twitter.comにpingを送信すると、TTL = 249になることがありますが、通常はTTL-58です。

どうしたの？私のISPは役に立たないのですか、それとも不吉な説明は少ないのですか？

ほとんどの場合、これは複数のネットワーク間での負荷分散が原因です。各pingは異なるパスを取るため、TTL値が異なります。

また、TTLを使用して奇妙なことを行う検索エンジンプロバイダーについても読みましたが、どちらかと言えば別のルートをたどっているだけです。

異なるオペレーティングシステムから供給された場合、TTL値は異なります。

• Windows：128
• Linux：64
• シスコ：255
• Solaris：255

また、一部のサイトは、一定の時間が経過した後、またはレート制限に達したときにICMPへの応答を停止します。Googleの8.8.8.8のDNSは、しばらくすると停止すると思います。

他の人は、遅延時間の変動を説明するためにマルチパスのシナリオに言及しました。ECMP（Equal Cost Multi Path）リンクを使用すると、Yahooへのpingで提供した出力に従って、結果間の遅延が合理的に一貫して変化するシナリオを作成できます。したがって、トラフィックは同じ2つまたは3つのパスでハッシュされ、長さ（遅延）が変化しているように見えます（これは推測にすぎませんが、与えられた情報で確実に言うことはできません）。

また、Yahooでは永続的なpingが約20パケット後にタイムアウトを開始するため、何らかのレート制限が実装されているようです。これは正常ですか？bing.comは私にも返信しません！

一部のネットワークは、ICMPトラフィックをフィルタリングしますが、これは非常に迷惑です。したがって、「まったくpingが実行されない」シナリオを説明できます。いくつかの返信がある、または返信が制限されているシナリオの場合、ネットワークはシスコのコントロールプランポリシング（またはそのベンダーの同等物）などのテクノロジーを実装している可能性があります。

Twitter.comにpingを送信すると、TTL = 249になることがありますが、通常はTTL-58です。

結果の変動が少ない場合は、不等コストのマルチパスルートが存在するか、パスのどこかにリンクの問題があるためにトラフィックエンジニアが変更されている可能性があります。繰り返しますが、与えられた情報では言えません。

これらのパケットのTTLの変動は、パケットの処理に長い時間がかかるルーターによって説明されます。ルータを通過する時間が1秒未満の場合、TTLはホップごとに1ずつ減らされます。ルータを通過する時間が1秒を超える場合、TTLは1ではなく2ずつ減少します。

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.