网络工程 - ping 时间是如何计算的 - 吾爱随笔录

我一直在绘制 ping (IPV4) 响应时间/与数据包大小的关系图。我期望在 MTU 边界附近的响应时间中看到大约 2*MTU/BandWidth 的不连续性（实际上，大约 1464 字节，在这个特定段上 MTU 是 1492）。我期望的基本原理是，2*MTU/BW 是具有 1 MTU 大小的数据包的往返时间，数据包碎片将以两倍的步长增加往返时间。

唉，这不是我看到的。使用

   # ping -f -c 30 -s $sz my.host

我看到数据包大小和往返之间的线性相关性如下（大小，最小平均最大，毫秒），但没有排序的不连续性：

1159  40.575 41.778 47.200
1220  41.392 42.145 45.420
1281  41.921 43.461 46.974
1342  42.498 43.840 52.638
1403  42.813 44.037 49.272
1464  43.741 45.455 49.795
1525  45.382 50.406 59.891
1586  45.579 55.605 66.309
1647  47.498 53.464 64.518
1708  49.373 73.681 84.820
1769  49.726 80.030 101.057

所以我不知道我是否被发送/报告数据包的方式绊倒了，或者我的推理是否在某种程度上是错误的（在这种情况下，错误在哪里）。

它和 ADSL 连接到互联网，通过 100MB 有线以太网，在它的出路时穿过 FGT60 和 zyxel，并且 tracepath（也 ping -M do）报告 1492 为 MTU。我正在 FC22 linux 机器上进行测试。我不知道，但在我看来，网络的外部细节应该无关紧要（很多）即。我缺少的定性结果，因为碎片应该发生（至少）在离开本地接口超过 1500 MTU 标记（即以太网连接 MTU）之前

编辑：并且（隐藏的）错误推理在于将最小传输单元（对于以太网上的 tcpV4 大约为 64 字节）相等，让我们将其称为 mTU，即 MTU - 即，假设所有数据包都将填充到 MTU。事实并非如此，由于碎片造成的不连续性应该在 mTU/Bw 左右，比 MTU/Bw 小 20 倍左右，并且可能会因网络条件变化而被抖动吞没