1

我正在使用iperf. 在我的应用程序中，我需要能够以大约 5KHz 的频率发送 2 字节的 UDP 帧。

进行正常的 UDP 速度测试，我可以轻松获得 10Mb/s：

 $iperf -uVc some_ip -b 10M
 Interval     Transfer    Bandwidth    Dropped/Sent
 0.0-10.0 sec 11.9 MBytes 10.0Mbit/sec 0 / 8504 (0%)

然后，当我尝试通过以 5Hz 发送 2B（与 80Kb/s 相关）数据报来镜像我的应用程序时：

 $iperf -l 2 -uVc some_ip -b 80K

服务器端说没有数据包通过，我猜是因为计数器或任何iperf用于跟踪数据包的东西无法容纳在 2B 有效负载中。这有意义吗？

作为一般经验法则，发送许多小数据包与发送少量大数据包相比有多糟糕？谁能指出文献说明了等待“打包”一个大数据报和一收到数据就立即发送 2B 数据之间的权衡？

为了进一步澄清，我对发送许多小数据包（包括开销，数据包只有大约 60B）与发送更少但大数据包的代价感兴趣。到目前为止，在我的测试中，丢包显然与带宽使用无关，而是与数据包数量相关，我觉得这违反直觉！

编辑：

我在最简单的客户端 - 服务器设置上执行此操作，在连接在本地网络上的两台 Linux PC 之间，它们是网络上唯一的接口，它们之间有以太网交换机。

4

2 回答 2

1

您必须意识到您的 2 个字节是有效负载，并且网络层将在您的有效负载前面添加标头。单独的 IP 头是 20 字节，但是 UDP 或 TCP 也会有它们的头，当然还有一个以太网头。

最有可能但不保证网络是以太网网络，这意味着 mtu 约为 1500。如果包含标头的数据包不是那么大，则说明您没有充分利用网络。

如果您的数据包不适合 mtu，IP 将进行分段。所以假设 mtu 是 1500 并且不同的层没有添加任何东西，那么发送 2000 字节将分成 1500 和 500。或者如果你有 1501，它将被分成 1500 和 1。同样不是最佳的。IP 能够分段高达 64K。如果你发送这样大小的东西，那么它当然会被 IP 分割，除了最后一个之外，你将拥有很多最佳数据包。

数据包的最佳大小 = mtu - 使用的不同层的标头。层是

  • TCP 或 UDP
  • 知识产权
  • 以太网

请注意，mtu 不保证 1492。它可能低于它取决于整个网络。

TCP 将为您完成所有这些工作。因为尝试优化使用 mtu 是 TCP 的天性。Nagle 被实现为一个连续的 50ms 计时器，并且仅在该计时器到期时发送一个段，或者如果对等方期待他自己发送的某些内容的 ack。

于 2015-04-09T18:53:55.647 回答
0

您的一般“有多糟糕”问题的答案在很大程度上取决于进行通信的网络拓扑和设备类型。

  1. 如果您通过 Internet 发送数据报，大量的小数据包不是最佳选择。TCP 实施Nagle 算法以避免发送具有 1 或 2 字节有效负载的小数据包，RFC 896 中指出这可能导致拥塞崩溃。
  2. 如果您通过具有大量跃点的网络发送数据报，则丢弃数据包的可能性会增加，因为每个跃点可能无法处理其队列中相同数量的数据包。
  3. 如果您的源和目标位于同一个本地网段中，则无关紧要。由于每个数据包的开销，您将失去一些带宽。

根据发送和接收的系统类型，大量的小数据包会增加网络堆栈、驱动程序和应用程序的流失。在嵌入式系统中，设备可能会花费更多的 CPU 周期来编组通过网络堆栈的所有数据包，而不是处理数据

于 2015-04-09T18:42:53.650 回答