&gt; UDP reassembling fragments looks a whole lot like TCP<p>There is only a tiny bit of similarity in that they are both dealing with reassembling a higher layer protocol payload from fragments split up over IP.<p>Let&#x27;s count the ways they are different:<p>1. UDP does provide ordering guarantees <i>within</i> a UDP packet. It provides no ordering guarantees between UDP packets. Consequently, the protocol never has to worry about ordering more than 2^16 bytes of IP data (that makes the sorting algo really simple and efficient).<p>2. UDP doesn&#x27;t have to deal with complex stalls or partial delivery of data. Either it has all the IP packets for a given UDP packet (in which case, it immediately delivers the UDP packet), or it doesn&#x27;t (in which case it doesn&#x27;t deliver it). If there is a UDP packet is missing a fragment, but a subsequent UDP packet is fully assembled, that one gets delivered.<p>3. There is no retransmission. UDP doesn&#x27;t retransmit. It doesn&#x27;t even guarantee deduplication. It is entirely possible that fragmented packets going different routes can end up creating an echo of multiple copies of a UDP packet being transmitted to the recipient.<p>The above makes UDP far simpler, and the contract application layers operate under very, very different. If you look at your typical TCP stack&#x27;s logic for reassembling fragments, you&#x27;ll find it far, far more complex than for UDP.