☰

tracert.exe：为什么 RTT 不会随着每一跳而增加？

tag-icon • tag-icon windows networking
tracert.exe：为什么 RTT 不会随着每一跳而增加？

今天网络很慢。所以我tracert.exe在附近的一台服务器上运行了程序（Windows XP 的德语版本）：

>tracert inka.de

Routenverfolgung zu inka.de [193.197.184.1]  über maximal 30 Abschnitte:

  1     2 ms     2 ms     9 ms  speedport.ip [192.168.0.17]
  2  2685 ms  2508 ms  2375 ms  217.0.117.14
  3  1435 ms  1680 ms  2103 ms  217.0.81.130
  4  1302 ms  1729 ms  1856 ms  f-ed5-i.F.DE.NET.DTAG.DE [217.5.95.22]
  5  1759 ms  1688 ms  2153 ms  ffm-b12-link.telia.net [62.115.12.45]
  6  1542 ms  1072 ms  1172 ms  ffm-bb1-link.telia.net [213.155.136.196]
  7   978 ms   999 ms   967 ms  ffm-b2-link.telia.net [213.155.132.205]
  8   895 ms   836 ms  1072 ms  belwue-ic-130164-ffm-b2.c.telia.net [213.248.88.26]
  9  1136 ms  1191 ms  1366 ms  Karlsruhe-RZ-1-10GE-0-3-0-2.belwue.net [129.143.57.177]
 10  1448 ms  1842 ms  1577 ms  fe0-553.cix.ka-ip.net [129.143.166.162]
 11  1609 ms  1901 ms  1830 ms  tapac.inka.de [193.197.184.1]

Ablaufverfolgung beendet.

第二行告诉我，我和 之间的 ICMP 数据包的 RTT217.0.117.14平均超过两秒。然而，第七行告诉我，我和 之间的 RTTffm-b2-link.telia.net不到一秒，尽管有五个以上的跳数。

我假设 RTT 会随着每次跳跃而增加，至少平均而言是这样。

这是一个错误的假设吗？如果不是，那么如何解释某些跳数的 RTT 大幅下降？

答案1

路径上的转发设备很可能使用某种路由缓存。当特定目的地的 PDU 首次到达节点时，设备必须发现从哪个接口转发 PDU。当下一个 traceroute PDU 到达时（具有更高的 TTL），节点无需重新发现将 PDU 转发到哪个接口，并且可以更快地转发 PDU。

地址解析协议 (ARP) 也可能发生类似的事情 - 节点第一次需要转发帧时，它必须通过 ARP 请求下一跳，该请求会被缓存，以便下次收到同一下一跳的帧时，可以更快地转发。

相关内容