为什么在 tracert 跳数中进行这种递归?

为什么在 tracert 跳数中进行这种递归?

在经历了互联网速度极慢、“连接被拒绝”、“无法协商链接”等网站(其中包括 fb、stackoverflow、yahoo、google)的提示后,我擅自随机进行了 tracert。

跟踪输出如下

C:\Documents and Settings\G0D>tracert in.yahoo.com

Tracing route to any-fp-in.wa1.b.yahoo.com [98.139.183.24]
over a maximum of 30 hops:

  1    12 ms     *       11 ms  1.64.95.59.in-addr.arpa [59.95.64.1]
  2    35 ms    34 ms    34 ms  218.248.255.58
  3   142 ms   140 ms   140 ms  115.114.57.249.static-Mumbai.vsnl.net.in [115.114.57.249]
  4   481 ms   478 ms   475 ms  ix-0-100.tcore1.MLV-Mumbai.as6453.net [180.87.38.5]
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8   551 ms   555 ms   543 ms  if-8-2.tcore2.SV8-Highbridge.as6453.net [80.231.91.26]
  9     *        *      514 ms  if-2-2.tcore1.SV8-Highbridge.as6453.net [80.231.139.2]
 10   547 ms   552 ms   554 ms  if-6-2.tcore1.NJY-Newark.as6453.net [80.231.138.18]
 11     *      549 ms   721 ms  if-2-2.tcore2.NJY-Newark.as6453.net [66.198.70.2]
 12   528 ms   543 ms   547 ms  if-3-2.tcore2.AEQ-Ashburn.as6453.net [216.6.87.9]
 13   341 ms   341 ms   342 ms  54.27.58.209.in-addr.arpa [209.58.27.54]
 14   356 ms   351 ms   351 ms  ae-6.pat2.dcp.yahoo.com [216.115.102.178]
 15   354 ms   381 ms     *     ae-7.pat2.che.yahoo.com [216.115.100.137]
 16   362 ms   362 ms   362 ms  ae-2.pat2.bfz.yahoo.com [216.115.100.74]
 17   384 ms   365 ms   385 ms  ge-1-0-0.pat1.bfz.yahoo.com [216.115.97.211]
 18   426 ms     *      366 ms  ae-4.msr2.bf1.yahoo.com [216.115.100.73]
 19   364 ms   370 ms   383 ms  xe-7-0-0.clr2-a-gdc.bf1.yahoo.com [98.139.128.19]
 20   368 ms   388 ms   394 ms  et-17-1.fab3-1-gdc.bf1.yahoo.com [98.139.128.41]
 21   477 ms   450 ms     *     ir2.fp.vip.bf1.yahoo.com [98.139.183.24]
 22   435 ms   416 ms   480 ms  ir2.fp.vip.bf1.yahoo.com [98.139.183.24]

Trace complete.

从第 3 跳开始似乎存在瓶颈。

令我特别惊讶的是在第 13 跳发生了明显的递归。

这种递归的原因可能是什么?

答案1

Traceroute 工作原理的简要概述:
Traceroute 会向目的地发送大量数据包。每个数据包(或可能是数据包组)的 TTL 都为 1(数据包死亡前需要经过多少跳)。当路由器收到带有 TTL 的数据包时,它会停止转发该数据包,然后可能发送互联网控制消息协议 (ICMP) 超时消息。

对于下一个数据包(或数据包组),TTL 为 2。第一个路由器转发数据包并将 TTL 减为 1。因此,下一个路由器将可能发送超出时间的消息。

使用此机制需要注意的重要事项是,路由器可以决定永远不发送超时消息,或者限制它们的速率,以便您只能获得部分命中。同样重要的是要知道数据包的返回路径不会显示在跟踪路由中,并且可能会有所不同。最后,路由可能会发生变化,因此跟踪路由可能会随时发生变化。

另一个简要概述,互联网如何路由:
互联网路由器使用一种称为 BGP 的协议来构建其路由表。BGP 对互联网有宏观的看法,基本上是整个网络的连接。因此,在这个例子中,您会看到从“as6453.net”转到“[209.58.27.54]”,然后转到 yahoo。就 BGP 而言,它采用这种宏观视角,并不担心这些网络内的跳数。

还有更多内容,但这是基本思想。

递归:
不太清楚你的意思,但如果你指的是 IP 号码在 中的反转方式54.27.58.209.in-addr.arpa [209.58.27.54],那么当没有像 这样的名称时,这只是反向 DNS 条目的“默认” ae-6.pat2.dcp.yahoo.com。在这种情况下,你可以使用whois它来查找所有者:

kbrandt@alpine:~$ whois 209.58.27.54
...
NetRange:       209.58.0.0 - 209.58.127.255
CIDR:           209.58.0.0/17
OriginAS:       AS6453
...
OrgName:        Tata Communications
OrgId:          TATAC
Address:        1555 Carrie-Derick
City:           Montreal
StateProv:      QC
...

答案2

跳 13 与跳 12 位于不同的网络上。因此,从跳 13 返回的数据包很可能采用了不同的(可能更好的)路径返回给您,从而缩短了该跳和后续跳的时间。

我还应该指出,第 5、6 和 7 跳上的 * 可能没有任何意义。它们可能只是无法将本地来源的数据包返回给您的设备。后面几行中的 * 可能意味着什么,也可能什么都不是。它可能只是意味着路由器太忙而无法将数据包返回给您,但更有可能的是,这些反映了真正的数据包丢失。

相关内容