许多小型UDP数据报与较少，较大的数据报相比较

Question

我有一个系统，每隔一段时间（例如，每分钟10次）以突发的形式发送“很多”（数百个）UDP数据报。根据{{​​1}}，这个平均值约为222kBit / s。这些数据报的内容是JSON。我考虑过更改系统，以便等待一段时间（500ms？）并将许多JSON对象组合成一个数据报，然后再发送。但我不确定这是否值得努力（带宽，协议，发送频率。）新方法是否会提供比现有方法更多的真正好处？

Answer 1

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

长版本取决于您的使用案例。既然我们不知道你在建设什么，那么很难说什么更重要 - 延迟？吞吐量是多少？可靠性？别的什么？让我们分析一些优点和缺点。这就是我想出的：

发送更大数据包的优点：

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

发送更大的数据包：

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