为什么跟踪路由时间有时会在跳数之间下降？

我在traceroute联机帮助页上看到类似的输出，但我一直很好奇为什么Ping时间在跳数之间下降？也就是说，我总是期待值从跳递增跳跃，如：为什么跟踪路由时间有时会在跳数之间下降？

[yak 71]% traceroute nis.nsf.net. 
traceroute to nis.nsf.net (35.1.1.48), 64 hops max, 38 byte packet 
1 helios.ee.lbl.gov (128.3.112.1) 19 ms 19 ms 0 ms 
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms 
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms 
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 39 ms 
5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 39 ms 39 ms 39 ms 
6 128.32.197.4 (128.32.197.4) 40 ms 59 ms 59 ms 
7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 59 ms 
8 129.140.70.13 (129.140.70.13) 99 ms 99 ms 80 ms 
9 129.140.71.6 (129.140.71.6) 139 ms 239 ms 319 ms 
10 129.140.81.7 (129.140.81.7) 220 ms 199 ms 199 ms 
11 nic.merit.edu (35.1.1.48) 239 ms 239 ms 239 ms

但是，什么是推理：

[yak 72]% traceroute allspice.lcs.mit.edu. 
traceroute to allspice.lcs.mit.edu (18.26.0.115), 64 hops max 
1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms 
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 19 ms 19 ms 
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 19 ms 
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 19 ms 39 ms 39 ms 
5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 20 ms 39 ms 39 ms 
6 128.32.197.4 (128.32.197.4) 59 ms 119 ms 39 ms 
7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 39 ms 
8 129.140.70.13 (129.140.70.13) 80 ms 79 ms 99 ms 
9 129.140.71.6 (129.140.71.6) 139 ms 139 ms 159 ms 
10 129.140.81.7 (129.140.81.7) 199 ms 180 ms 300 ms 
11 129.140.72.17 (129.140.72.17) 300 ms 239 ms 239 ms 
12 * * * 
13 128.121.54.72 (128.121.54.72) 259 ms 499 ms 279 ms 
14 * * * 
15 * * * 
16 * * * 
17 * * * 
18 ALLSPICE.LCS.MIT.EDU (18.26.0.115) 339 ms 279 ms 279 ms

为什么从啤酒花3时至4去从39MS到19ms？

来源

2014-10-05 Colby Blair

它们不仅仅是不同的“啤酒花”，而是完全不同的事件，在不同的时间，可能在不同的条件下。

traceroute的工作方式是，它发送TTL为1的数据包，看看答案到达需要多长时间。该程序重复三次以解释可能的和正常的变化（注意即使是“同一跃点”中的三个数字有时也是非常不同的，因为它们也是完全独立的东西）。

然后，traceroute发送一个TTL为2（然后3和4等）的数据包，并看到一个答案到达需要多长时间。同时，第一台路由器的负载可能会降低，因此您的数据包实际上会更快地转发。或者，您的数据包出去的物理电缆可能并不繁忙，因为您的室友刚刚完成了下载他的色情内容（而在您的网卡需要等待电缆闲置之前）。这是一直发生的事情，你无法知道或控制。
有没有办法回到过去，所以你不能改变一个事实，就是第二个事实，你的数据包需要花费更长的时间才能完成。你在两个不同的时间探索，所以你能得到的是一个合理的猜测。是的，一般来说，从一跳到一跳的时间应逐渐增加，但不一定。

这并不意味着往返时间是真的要跳3和4之间上下它只意味着在此期间去了，而你，你单独试图让多久3周跳的估计和4跳可能需要。

来源

2014-10-06 15:33:03 Damon

真棒详细的解释，这就是我一直在寻找的！我通常怀疑是这样的，但细节很好。谢谢！我希望traceroute能够将数据包发送到第一个测试/列的每一跳，然后将数据包发送到第二列第二测试的每一跳等，这样跳数之间的时间减少会更加明显。这并不是说这个常用工具会改变。 – 2014-10-08 21:09:09

线之间最有可能的随机延迟。请注意，在第二个和第三个数据包发送的跳数3-4从19ms到39ms。无论如何他们都在同一个网络中，所以大部分延迟都是由于处理/拥塞。

虽然偶尔会看到另一种情况，即某些服务器为ICMP消息提供更高的QoS，但表面上看起来性能更好。

来源

2014-10-06 15:18:27 fruglemonkey

奇怪 - 在我的（广泛的）体验中，大多数服务器/路由器给IMCP消息带来的优先级更高。 – Alnitak 2014-10-06 15:23:42

我听说过一个狡猾的ISP /服务器主机给予ICMP消息更高的优先级以使他们的服务更好看的情况 – fruglemonkey 2014-10-07 01:16:59

在分组交换网络上，分组延迟不是确定性的，特别是在网络拥塞的情况下。 traceroute测试的每一跳都是一个单独的测试，因此变化的网络条件很容易导致后面的测试比较近的跳跃具有更好的延迟。

也就是说，traceroute不只是发出三个数据包，然后以某种方式找出每跳的时间。它发送数据包特意设计为n跃点后超时，并测量时间为n增加。

来源

2014-10-06 15:27:09 Alnitak

为什么跟踪路由时间有时会在跳数之间下降？

回答

相关问题