UDP协议不保证按顺序接收数据包，但您可以仅使用部分数据报作为序列号。
与TCP的保证相比，上述解决方案对于UDP是否等价?
基本上，我一直在到处阅读UDP不提供顺序接收，但这似乎是一个明显的修复，我想知道它是否真的是一个足够的修复。
唯一的缺点是丢失了几个字节的数据空间。
然而，它本身并不是一个解决方案。你必须在你的协议中添加ACK消息，这样发送者就知道你收到了什么，还没有收到什么;你必须在发送者处缓冲发送的数据报，直到它们被确认，以防你必须重新传输它们;你必须要么缓冲序列外的数据报，要么扔掉它们，这样你才能正确地重建序列。到目前为止，如果发送方注意到需要大量的重传，那么实现某种形式的流量控制或节奏也是明智的。
这是实现TCP的好方法。大多数人在这一点上放弃并使用TCP。
以这种方式使用UDP使应用程序需要处理数据包重构和排序。这在网络的应用程序层中造成了开销。TCP可能在传输层处理这些更有效。
同样，UDP不提供重发丢失数据包的机制。当您的应用程序注意到序列号跳过了1时，其含义就存在一些歧义。是否有丢失的数据包或延迟的数据包?您的应用程序需要能够检测到这一点，并且能够通过包编号引用请求再次发送数据包。
换句话说，当需要按顺序保证传递时，TCP开销是有原因的。
https://en.wikipedia.org/wiki/User_Datagram_Protocol听起来你想要一种介于TCP和UDP之间的部分可靠性。
一个选项是使用SCTP-over- udp (SCTP，便携式用户空间&内核源代码)。SCTP允许您按顺序设置不可靠的类似udp的流，以及部分可靠的流(有限的时间或重传次数)。.
当然你可以在UDP中实现TCP缺少的特性，但这会破坏UDP的目的。关键是网络堆栈中的TCP实现为您执行所有必要的操作。(包括包重组和包丢失)。
如果你需要TCP，你应该使用它。UDP是为数据包设计的，你不关心他们是否丢失(如VOIP, Gameserver等)。