许多小的 UDP 数据报与更少、更大的数据报

Question

我有一个系统，每隔一段时间（例如，每分钟 10 次）以突发形式发送“许多”（数百个）UDP 数据报。据nload，这平均约为 222kBit/s。这些数据报的内容是 JSON。我考虑过更改系统，使其等待一段时间（500 毫秒？），并将许多 JSON 对象合并到一个数据报中，然后再发送。但我不确定是否值得付出努力（考虑带宽、协议、发送频率）。新方法是否会比当前方法提供任何真正的好处？

Answer 1

简短的回答是由您来决定。

长版本是它取决于您的用例。由于我们不知道您在构建什么，因此很难说哪个更重要 - 延迟？吞吐量？可靠性？还有什么？让我们分析一些利弊。这是我想出的：

发送较大数据包的优点：

• 更少的消息意味着更少的系统调用和更少的网络 I/O。这意味着更少的阻塞/等待线程和更少的中断时间。
• 更少、更大的数据包意味着每个单独数据包的开销更少（像每个数据包发送的 IP/UDP 标头之类的东西）。因此（理论上）可以实现更高的数据速率，但请记住，所有这些标头 (L2+IP+UDP) 通常每个数据包加起来不超过 60-70 个字节，因为 UDP 标头只有 8 个字节长。
• 由于 UDP 不保证排序，因此它们之间有更多时间的较大数据包将减少任何现有的重新排序。

发送更大的数据包的缺点：

• 重新编写现有代码，并使其（稍微）更复杂。
• UDP 是不可靠的，因此与丢失小数据包相比，丢失单个（大）数据包会更重要。
• 延迟 - 某些数据必须等待 500 毫秒才能发送。这意味着在发送方和接收方之间增加了延迟。
• 分段- 如果您创建的数据包之一跨越MTU边界（通常为 1450-1500 字节，包括 IP+UDP 标头，通常为 28 字节长），IP 层需要将数据包分成几个较小的数据包。出于多种原因，IP 碎片被认为是不好的。
• 处理较大的数据包可能需要更长的时间