UDP 小数据包（在 MTU 内）传输期间的松弛字节？答案

【问题标题】：UDP small-packet (inside MTU) slack bytes during transmission?UDP 小数据包（在 MTU 内）传输期间的松弛字节？
【发布时间】：2016-03-02 21:41:27
【问题描述】：

背景：为模拟器（Windows、.net）编写多人游戏，使用点对点 UDP 传输。这个 Q 不是关于 UDP 与 TCP 的优势，也不是关于数据包头。这个Q的相关讨论是here。

考虑：我发送一个负载大小为 X 的 UDP 数据包，其中 X 可以是 1 到 500 个字节之间的任何值。

问：在传输过程中的任何时候，是否会/是否可以在数据包中临时添加松弛字节，即。字节除了到所需的标头/有效负载？例如，传输中的任何参与者（Windows 操作系统 - NAT - 互联网 - NAT - Windows 操作系统）是否会添加字节来满足特定的块大小，以便这些添加的字节成为传输的一部分（即使被切断稍后），并实际传输，从而消耗处理器（交换机，服务器 CPU）周期？

（询问的原因是在组合/分解数据包上花费了多少精力，当然:-)。将其压缩到最后一位（小，更多本地 CPU 周期）与允许数据包部分自描述（更大，更少本地 CPU）。请注意，数据包大小始终小于（我知道的离我最近的）MTU，通常接近 1500 字节）

谢谢！

【问题讨论】：

标签： network-programming udp multiplayer packets

【解决方案1】：

简短的回答是：是。

以以太网为例。出于冲突检测的目的，以太网帧的最小有效负载大小为 42 字节。如果有效负载（包括应用程序数据、UDP 和 IP 标头，在这种情况下）小于该值，则会在以太网帧中添加一个填充。

另外，据我所知，网卡将完成这项工作，而不是驱动程序或操作系统。

如果您想决定是发送小数据包更好还是等待再发送更大的数据包更好，请查看 Nagle 算法。

在这里您可以看到实际的以太网填充： What are the 0 bytes at the end of an Ethernet frame in Wireshark?

【讨论】：

根据上面的答案，是否可以公平地假设，对于数据包在两个对等计算机“外部”的传输部分，它确实无论有效载荷是 1 字节还是 42 字节或介于两者之间，当关注传输速度时？这大致是，因为我意识到还有许多其他因素会影响，比如触发时间和本地管理周期。尽管如此，这是相关的，因为例如可以为
是的，对于这么小的数据包没关系，数据包在网络中至少有 72 个字节长，有或没有足够的数据。为了做出更好的决定，请记住以下两点： 1 - 处理时间远小于“网络时间”，因此尽量发送尽可能少的数据包以获得更好的性能。 2 - 所有这些开销都会使您的数据膨胀，因此与发送一些较大的数据包相比，发送大量小数据包实际上意味着发送大量字节。如果我清除了您的疑虑，请不要忘记在答案中投票。
这很好地回答了我的问题，谢谢。很少有更好的。不科学地，我的印象是，如果患者处于休息状态，打嗝（反应能力）会更好地发挥作用:-)。恐怕我的票不算数；我自然而然地这样做了，但在我获得 15 的声誉之前它不会公开可见（这是我的第一个 stackoverflow 问题）。这（就我而言）相当愚蠢，因为我是软件领域的老狗，拥有 30 年的经验。哦，好吧，我会留下来看看:-)。
附言。添加了另一个问题：link。也许你有时间看看？