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甚至都没有回复我！
ping google.com时，TTL保持一致。
ping Twitter.com时，有时我得到TTL = 249，但是通常是TTL-58。
发生了什么事？我的ISP不好吗？还是没有那么险恶的解释？
#1 楼
这很可能是由多个网络之间的负载平衡引起的。每个ping都会采用不同的路径，因此会有不同的TTL值。我还读到了有关搜索引擎提供商使用TTL做奇怪事情的信息，但它们只是通过两种方式走了一条不同的路。 />
当来自不同操作系统的TTL值不同：
Windows：128
Linux：64
Cisco：255
Solaris：255
是的，某些站点在一定时间后或达到速率限制后将停止响应ICMP。我相信Google在8.8.8.8上的DNS最终会在一段时间后停止。
#2 楼
其他人则提到多路径方案来解释延迟时间的变化。借助ECMP（等价多路径）链接，您可以根据在ping到Yahoo时提供的输出获得一个方案，其中延迟在结果之间变化，但保持一致。因此，看来您的流量被散布在相同的两三个路径上，且具有不同的长度（延迟）（尽管只是推测，我无法确定所提供的信息）。而且，雅虎似乎实现了某种速率限制，因为
持久性ping将在大约20个数据包后开始超时。这是
正常吗？ bing.com甚至都没有回复我！
某些网络确实过滤了ICMP流量，我觉得这非常烦人！这样就可以解释“根本不执行ping”的情况。对于您有一些答复或答复有限的情况，网络可能正在实施一项技术，例如思科的控制计划管理（或与之等效的供应商）。
ping Twitter.com有时我得到TTL = 249，但通常为TTL-58。
当您的结果变化不稳定时，可能会出现不等成本的多路径路由，或者由于流量工程师而发生变化链接到路径中的某些位置。同样，不能说出所提供的信息。
#3 楼
这些数据包上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.
评论
当ping时间低于300ms时，在这种情况下这不太可能成为一个因素，尽管让人们了解这也是TTL的功能是有益的。
– YLearn♦
2013年7月5日15:44
我会非常担心跃点是否花费了超过1秒的时间来处理数据包。但是我没有意识到这一点，我认为该字段是通过处理器进行更改的一部分，很好的发现！
– Artanix
13年7月5日在16:57
TTL在现实生活中不会像RFC所建议的那样暂时减少，它严格是“跳数”，并在IPv6中这样命名。
–ytti
13年7月5日在17:13
@ytti，确实是这样，但是某些设备符合RFC的这一部分。虽然大多数主流设备都不会，但我已经看到了“非品牌”装备的这种极端情况。
– YLearn♦
13年7月5日在20:03
我实际上也已经看过了……这就是我所知道的。
– GerryEgan
13年5月5日在22:12
评论
您的上游之一进行ibgp负载平衡是可能的原因，但是我们没有足够的信息要知道。您可以通过tracerouting找出答案...请谷歌为mtr并进行更多探索如果您可以提供源IP（curl my.ip.fi），我可以尝试几个有利位置来查看返回路径选项