udp传输到底会不会发生粘包问题

看了一些解答说udp都是整包发，整包收，不会发生粘包，但是周围的前辈们说还是有可能的，我们现在服务端收到的数据也就几十个字节的大小，收的频率是每秒10条左右吧，到底会不会发生粘包现象，就是两条数据粘一块，或者其中一条数据不完整另一个完整

从TCP与UDP的区别讲起
网络数据经过路由器,如果数据很小,没有超过路由器的封包大小,就会直接直接经过路由器到达下一个路由器,一层一层最终到达目的地
如果数据很大,这里指一个发送,超过了路由器的封包大小,那么路由器就会把这个数据包进行拆分,比如拆分成A B C三个包,这三个包都没有超过路由器的封包大小,到达下一个路由器的时候,TCP与UDP的区别就来了：
TCP收到A的时候,会resp通知源路由器,A到达,B C包依然如此,如果由于网络的各种原因，目的路由收到了A C,B没有收到，TCP会要求源路由把B包重新发一次，直到ABC包目的路由都接受到了，那么目的路由把ABC包重新组成起始包，继续往下一个路由发送，这就是TCP安全连接的由来，只要发送，我就能保证目的一定能收到（网络断开能检测到）
UDP则不是这样，如果ABC包拆分之后，目的路由只收到AC，经过检测，B没有被收到，那么此包就会被当作不完整，直接被丢弃。由于UDP没有resp的通知过程，所以，UDP的传输效率要高一些，当然安全性也低一些
由上面的这些可以得出结论：UDP是绝对不会被粘包，因为路由器收到的只会是完整数据才会继续下发，什么粘包处理完全没有必要。

一般网络编程时候，也会定义数据包头，包体
TCP接收数据的时候，可以先接收包头进行安全验证，通过继续接受包体，不通过直接断开连接
UDP接受则没有办法这样做，你再大的一个数据，一个RECV,也是直接接受，不能说我先接受多长，这样是不可能的（不过一般大文件数据，都不会用UDP这种不安全传输）。


UDP有明确的结束标志，不会有粘包的，UDP本身有对数据完整性的校验，不完整的包会被丢弃，所以也不会不完整。如果你是指一次会受到2-3个UDP包，那只要根据开头和结束标记分割就行了。TCP的话，只要所需数据块的大小是确定的，然后每次接受的数据根据长度，不足就继续收，超过就把剩余的存下来与下次的接受合并，就可以解决粘包问题。

粘包这个词应该是特指TCP的，是你一次发的数据太少，不值得发一次，系统就把他缓冲下来，和下次的一起发了。这是因为TCP传输本来就是流的概念，程序处理的是流，怎么分包程序都应该能正确处理。多数情况下TCP也不需要处理粘包。
UDP没有粘包，但是有丢包和乱序。不完整的包是不会有的，收到的都是完全正确的包。

UDP不是流协议，有消息边界，不存在粘包的问题。要丢就是整个包都丢了。



真正的原因如下:
TCP是面向流的, 流, 要说明就像河水一样, 只要有水, 就会一直流向低处, 不会间断. TCP为了提高传输效率, 发送数据的时候, 并不是直接发送数据到网路, 而是先暂存到系统缓冲, 超过时间或者缓冲满了, 才把缓冲区的内容发送出去, 这样, 就可以有效提高发送效率. 所以会造成所谓的粘包, 即前一份Send的数据跟后一份Send的数据可能会暂存到缓冲当中, 然后一起发送.

UDP就不同了, 面向报文形式, 系统是不会缓冲的, 也不会做优化的, Send的时候, 就会直接Send到网络上, 对方收不收到也不管, 所以这块数据总是能够能一包一包的形式接收到, 而不会出现前一个包跟后一个包都写到缓冲然后一起Send.

但其实别想得太复杂的, TCP所谓的粘包处理, UDP所谓的丢包处理, 其实都是很简单的.
TCP只要保证自己写入的流是按 长度 + 内容 + 长度 + 内容 这样就可以非常简单的解决粘包问题, 切忌不要采用所谓的 开始标识 + 数据 + 结束标识 来分包, 适用性极低, 错误率极高, 除非数据都是固定有格式, 否则是不能采用这种方式的.
UDP传送当中, 只存在丢包的可能, 收到包的时候, 肯定这个包的内容就是正确的, 很少会有错误的, 因为UDP本身也会用CRC32进行验证, 还有长度验证, 验证不通过, 系统自动就会丢弃, 所以, 只需要去想象一种情况, 把一个苹果切了很多块, 然后要捡起这些块到另外一个容器, 由另外一个人进行重组, 而这捡的过程当中, 有可能切的人捡漏了某些块, 然后重组苹果的人就要求切的人重新把缺失的块捡回来。