sockets - 作用于 UDP 套接字时，什么会导致 sendto() 发送的字节数少于请求的字节数？

Question

作用于 UDP 套接字时，什么会导致 sendto() 发送的字节数少于请求的字节数？
提出这个问题的动机是找出我需要采取的预防措施，以确保我 始终 在一次调用 sendto() 时收到完整的消息，并了解我需要采取哪些进一步的步骤才能将消息放入单个IP 数据包。我是否只需要确保我的消息小于某个大小，如果是，该大小有多大？除了特定于操作系统的 UDP 数据报大小限制和 MTU 之外，是否还有其他因素在起作用(例如 i/o 缓冲区容量、反复无常的操作系统)？
在问了上面的原则问题之后，在这篇文章的标题中，我将继续一些相关的后续问题，然后在最后将事情放到上下文中。
更多问题
更详细地说，再次假设我们正在对 UDP 套接字进行操作:

对 sendto() 的每次成功调用是否会导致恰好 1 个 UDP 数据报被发送？ (我很欣赏这可能会分成多个 IP 数据包)

每次成功调用 recvfrom() 是否会准确检索 1 个 UDP 数据报？

如果一条消息需要 N 次调用 sendto() 来发送，即使接收机器是不同的平台，它是否也需要恰好 N 调用 recvfrom() 才能接收？ (我很欣赏数据报的顺序将是不可预测的)

假设我尝试发送一条消息，其大小等于或小于本地和远程系统支持的最大 UDP 数据报大小中的较小者，(并且出现一些会导致返回值 -1 的错误)是 sendto()保证一口气发送我的全部信息？或者它可能会报告它发送的字节数少于我要求它发送的字节数？如果是这样，为什么？回到问题 1。

除了问题 4 中的假设之外，假设我的消息不大于(MTU - UDP header - IP header )大小，是保证适合 1 个 IP 数据包的 UDP 数据报(至少在我的本地网络上)?

上下文
我刚刚开始编写我的第一个基于 UDP 的通信协议(protocol)(跨平台:例如 linux、mac、windows、ios、android 等)。我是一个套接字新手，但我知道使用像 UDP 这样简单的协议(protocol)所带来的“成本”，并研究了以下算法/策略:

Reliability and flow control

将大消息拆分为多个小消息

Fountain codes 帮助补偿一些数据包丢失(通过减少重新发送请求)。

加密(见 http://srp.stanford.edu/)

我试图将我的所有通信分解为原子消息(即单个、自包含的 UDP 数据报)，这些消息可能(但不一定)需要装入单个 IP 数据包(例如 1500 字节)。吞吐量和数据包丢失的实时评估将确定我是否必须缩小数据报以适应单个 IP 数据包(这会导致额外 header 的大小损失)。其中一些将通过 wifi/ radio 链接，所以我希望自适应地确定“最佳”数据报大小。我知道我所有接口(interface)的 MTU，并且意识到在我的本地网络之外，数据包可能会被进一步拆分，但这超出了我的控制范围，所以我可以忍受它。
但是一切都取决于能够构建一个原子消息，并且有 100% 的信心我可以通过一次调用 sendto() 成功发送它，并通过一次调用 recvfrom() 接收它。我所有的应用程序级可靠性、拆分、编码和加密信息都存在于我自己的协议(protocol) header 中，并且在对 sendto() 的调用返回短消息后，我无法重新拆分消息。例如。想想消息校验和:如果整个消息没有一次性通过，则 header 中的校验和对于已发送的消息部分不再有效。

Answer 1

everything hinges on being able to construct an atomic message and have 100% confidence that I can send it successfully with a single call to sendto(), and receive if with a single call to recvfrom()

UDP 保证了这一点。数据报完好无损地到达，或者根本不到达。您所需要的只是确保您的套接字发送和接收缓冲区足够大，并且如果您正在遍历路由器，则每个数据报发送的字节数不要超过 534 个字节:这是普遍接受的限制。