使用小数据包时，您不必担心数据包会被分成多个数据包。这通常只在数据包超过以太网网络时才是问题。
您问：“服务器是否会收到两个数据包，一个1000字节，另一个400字节，或者有可能接收到1000字节的200字节，然后1000字节的400字节，最后再接收其余的字节，就像TCP一样？”
如果数据包大小小于1492字节，则不会出现部分数据包。
更新：
显然，我需要澄清为什么我说UDP数据包长度小于1492字节不会影响传输的鲁棒性。
根据RFC 768隐含规定，UDP数据包的最大长度为65535字节，包括8字节的头部。最大有效载荷帧长度为65527字节。
虽然这个数字不应该有争议，但UDP数据长度经常报告错误。这在以前的帖子中得到了证明：
互联网上最大的安全UDP数据包大小是多少？
数据包不受底层网络的MTU或通信协议帧长度（例如IP和以太网）的限制。MTU和协议长度之间的差异通过分段和重组来解决。
在传输层，每种网络服务类型（ToS）都有特定的最大传输单元（MTU）。UDP被封装在IP数据包中，而IP数据包则由传输网络的ToS进行封装。IP数据包经常通过各种ToS的网络进行传输，包括以太网、PPP、HDLC和ADCCP。
当接收网络的MTU小于发送ToS时，接收网络必须对接收到的数据包进行分段。当网络向具有更高MTU的网络发送数据包时，接收网络必须重新组装任何分段的数据包。
以太网是事实上的主流协议，其MTU最低。非主流Arcnet的MTU为507字节。实际最低MTU是以太网的1500字节，减去开销后最大有效载荷长度为1492字节。
如果UDP数据包超过1492字节，数据包很可能会被分段和重组。分段和重组增加了已经复杂的UDP和IP耦合过程的复杂性，因此应该避免使用。
由于UDP是一种非保证的数据报传递协议，它提高了传输性能。健壮性留给源和终止应用程序。RFC 1166为通信协议链路层、IP层和传输层设置了标准，UDP应用程序负责数据包化、重组和流量控制。
通信主机的应用层也可以降低最大UDP数据包大小。数据包长度在性能和健壮性之间取得平衡。
通信主机的应用层可以设置最大UDP数据包大小。应用层的典型UDP最大数据长度将使用IP协议或主机数据链路层允许的最大长度，通常是以太网。
是应用程序员选择使用主机应用层还是主机数据链路层。主机应用层将检测UDP数据包错误并在必要时丢弃数据包。当应用程序直接与主机数据链路通信时，应用程序则有责任检测数据包错误。
使用以太网最大有效载荷长度1492字节的最大UDP数据包长度将消除多帧分段和传递顺序问题。
这就是我说1000和400字节的数据包长度不是分段问题的原因。
###
我不知道你所说的“guaranteed encapsulation”是什么意思，对我来说毫无意义。
使用IP时，无论是UDP还是TCP，都不能保证数据包的顺序和传递。
只要你控制对话的双方，就可以在数据包中制定自己的协议以处理排序和后续数据包。将数据包的前x个字节保留为顺序编号和数据包总数。（例如：1 of 3，2 of 2，3 of 3）。如果客户端缺少一个数据包，则必须发送重新传输请求。您需要确定要为数据完整性提供到哪个级别。例如，重新传输数据包也可能会丢失。
这可能就是你所说的“guaranteed encapsulation”，在数据报文中有其他信息以确保一定的完整性。如果将其分成多个数据报文，则应为发送的所有数据添加自己的CRC。校验和不够强大，仅适用于一个数据包。
UDP比TCP快得多，但TCP具有流量控制和保证传递的功能。
UDP适用于流媒体内容（如语音），其中丢失一个数据包并不重要。
自从这些问题成为主要关注点以来，网络可靠性已经有了很大的提高。
