linux - 为什么跟踪路由时间有时会在跃点之间下降?

标签 linux networking traceroute

<分区>

我在 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 跳的时间从 39 毫秒变成了 19 毫秒?

最佳答案

它们不仅是不同的“跃点”,而且确实是完全不同的事件,发生在不同的时间,可能发生在不同的条件下。

traceroute 的工作方式是,它发送一个 TTL 为 1 的数据包,然后查看应答到达需要多长时间。该程序重复这三次以解释一些可能且正常的变化(请注意,即使“同一跳”中的三个数字有时也非常不同,因为它们也是完全不同的东西)。

然后,traceroute 发送一个 TTL 为 2(然后是 3、4 等)的数据包,并查看应答到达需要多长时间。与此同时,第一个路由器的负载可能降低了,所以你的数据包实际上转发得更快了。或者,你的数据包发出的物理电缆可能不忙,因为你的室友刚刚下载完他的色情片(而在此之前你的网卡必须等待电缆空闲)。这是经常发生的事情,你无法知道或控制它。
没有办法回到过去,所以你无法改变一秒钟前你的数据包需要更长的时间才能通过的事实。你在两个不同的时间进行探测,所以你所能得到的只是一个合理的估计。是的,一般来说,从一跳到另一跳的时间应该逐渐增加,但不需要。

并不意味着往返时间真的在第 3 跳和第 4 跳之间下降了。这只意味着它同时下降了,而你独立地尝试估计3 跳和 4 跳可能需要多长时间。

关于linux - 为什么跟踪路由时间有时会在跃点之间下降?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/26206811/

相关文章:

linux - 使用排序从列表中删除行,grep LINUX

php - 如何以静默模式执行脚本以摆脱浏览器挂起

python - 使用 ftplib Python 登录 Dropbox

java - Android 的线程和网络

delphi - 我如何使用delphi跟踪IP

java - 僵尸异常幸存被捕获

linux - 从收到的 TCP 数据包中打开带有 CEC 的 AMP

java - 通过 Java 获取默认网络接口(interface)

python - 如何在 python 中执行 ping 或 traceroute,访问生成的输出?

android - Android 上的跟踪路由