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

我还阅读了有关使用 TTL 做奇怪事情的搜索引擎提供商，但无论哪种方式，它都只是通过不同的路线。

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

• 视窗：128
• Linux：64
• 思科：255
• 索拉里斯：255

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

其他人提到了多路径场景来解释延迟时间的变化。使用 ECMP（等价多路径）链接，您可以根据您在 ping 到 Yahoo 中提供的输出创建一个场景，其中延迟在结果之间变化但合理一致。所以看起来你的流量在相同的两三个路径上散列，具有不同的长度（延迟）（尽管这只是猜测，我无法根据所提供的信息确定）。

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

有些网络确实过滤了 ICMP 流量，我觉得这很烦人！所以这可以解释“根本没有ping”的情况。对于您有一些回复或有限回复的情况，网络可能正在实施一项技术，例如Cisco 的控制计划策略（或其供应商等效项）。

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

当您的结果变化不太稳定时，可能会出现不等价的多路径路由，或者由于路径中某些位置的链接问题而导致流量工程师发生变化。再次，不能说提供的信息。

这些数据包上的 TTL 变化可以由路由器需要很长时间来处理数据包来解释。如果通过路由器的时间小于 1 秒，则 TTL 在每一跳后递减 1。如果通过路由器的时间大于一秒，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.