解释ping结果

我正在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变化。

同样，雅虎似乎实施了某种速率限制，因为持久性ping将在大约20个数据包后开始超时。这正常吗？bing.com甚至都没有回复我！

对google.com进行ping操作时，TTL是一致的。

ping Twitter.com时，有时会得到TTL = 249，但通常是TTL-58。

这是怎么回事？我的ISP不好吗？还是没有那么险恶的解释？

这很可能是由多个网络之间的负载平衡引起的。每次ping将采用不同的路径，因此会有不同的TTL值。

我还读到了有关搜索引擎提供商使用TTL做奇怪事情的信息，但它只是通过另一种途径走了一条路。

来自不同操作系统的TTL值不同：

• Windows：128
• 的Linux：64
• 思科：255
• Solaris：255

是的，某些站点将在一定时间后或达到速率限制时停止对ICMP的响应。我相信Google在8.8.8.8上的DNS最终会在一段时间后停止。

其他人则提到多路径方案来解释延迟时间的变化。借助ECMP（等价多路径）链接，您可以根据在ping到Yahoo时提供的输出获得一个方案，其中延迟在结果之间变化，但保持一致。因此，看起来您的流量正在通过相同的两条或三个路径散列，且长度（延迟）有所不同（尽管这只是推测，对于给出的信息，我无法确定）。

同样，雅虎似乎实施了某种速率限制，因为持久性ping将在大约20个数据包后开始超时。这正常吗？bing.com甚至都没有回复我！

一些网络确实过滤了ICMP流量，我觉得这非常烦人！这样就可以解释“根本不执行ping”的情况。对于您有一些答复或答复有限的情况，网络可能正在实施一项技术，例如思科的控制计划策略（或其供应商等效产品）。

ping Twitter.com时，有时会得到TTL = 249，但通常是TTL-58。

如果结果变化的稳定性较差，则可能会出现不平等成本的多路径路由，或者由于链路问题，路径中的某些位置会导致流量工程师发生变化。再次，不能说给定的信息。

这些数据包上TTL的差异可以由处理时间较长的路由器来解释。如果通过路由器的时间少于一秒，则每跳一跳后TTL就会减一。如果通过路由器的时间更长，则一秒钟的TTL将减少2，而不是1。

请参阅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.