解释ping结果


11

我正在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不好吗?还是没有那么险恶的解释?


1
您的上游之一进行ibgp负载平衡是可能的原因,但是我们没有足够的信息要知道。您可以通过tracerouting找到答案...请为mtr google并探索更多内容
Mike Pennington

如果您可以提供源ip(curl my.ip.fi),我可以尝试几个有利位置来查看返回路径选项
ytti 2013年

Answers:


14

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

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

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

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

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


6

其他人则提到多路径方案来解释延迟时间的变化。借助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.

2
在ping时间低于300ms的情况下,这在这种情况下不太可能成为一个因素,尽管让人们理解这也是TTL的功能是有益的。
YLearn

我会非常担心某个跃点是否花费了超过1秒的时间来处理数据包。但是我没有意识到这一点,我认为该字段是通过处理器进行更改的一部分,很好的发现!
Artanix

3
TTL在现实生活中不会像RFC所建议的那样暂时递减,它严格是“跳数”,并在IPv6中这样命名。
ytti

@ytti,确实是这样,但是某些设备将遵循RFC的本部分。虽然大多数主流设备都不会,但我已经看到了“非品牌”装备的这种极端情况。
YLearn

我实际上也已经看过了……这就是我所知道的。
GerryEgan
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.