什么是 TCP 粘包半包？
假设客户端分别发送了两个数据包 D1 和 D2 给服务端，由于服务端一次读取到的字节数是不确定的，故可能存在以下 4 种情况。 （1）服务端分两次读取到了两个独立的数据包，分别是 D1 和 D2，没有粘包和拆包；
（2）服务端一次接收到了两个数据包，D1 和 D2 粘合在一起，被称为 TCP 粘包；
（3）服务端分两次读取到了两个数据包，第一次读取到了完整的 D1 包和 D2 包的部分 内容，第二次读取到了 D2 包的剩余内容，这被称为 TCP 拆包；
（4）服务端分两次读取到了两个数据包，第一次读取到了 D1 包的部分内容 D1_1，第 二次读取到了 D1 包的剩余内容 D1_2 和 D2 包的整包。 如果此时服务端 TCP 接收滑窗非常小，而数据包 D1 和 D2 比较大，很有可能会发生第 五种可能，即服务端分多次才能将 D1 和 D2 包接收完全，期间发生多次拆包。
TCP 粘包/半包发生的原因
由于 TCP 协议本身的机制（面向连接的可靠地协议-三次握手机制）客户端与服务器会 维持一个连接（Channel），数据在连接不断开的情况下，可以持续不断地将多个数据包发 往服务器，但是如果发送的网络数据包太小，那么他本身会启用 Nagle 算法(可配置是否启用)对较小的数据包进行合并(基于此，TCP的网络延迟要UDP的高些)然后再发送(超时或者包大小足够)。那么这样的话，服务器在接收到消息（数据流）的时候就无法区分哪 些数据包是客户端自己分开发送的，这样产生了粘包；服务器在接收到数据库后，放到缓冲 区中，如果消息没有被及时从缓存区取走，下次在取数据的时候可能就会出现一次取出多个 数据包的情况，造成粘包现象
UDP：本身作为无连接的不可靠的传输协议（适合频繁发送较小的数据包），他不会对数据包进行合并发送（也就没有 Nagle 算法之说了），他直接是一端发送什么数据，直接就 发出去了，既然他不会对数据合并，每一个数据包都是完整的（数据+UDP 头+IP 头等等发一 次数据封装一次）也就没有粘包一说了。
分包产生的原因就简单的多：可能是 IP 分片传输导致的，也可能是传输过程中丢失部 分包导致出现的半包，还有可能就是一个包可能被分成了两次传输，在取数据的时候，先取 到了一部分（还可能与接收的缓冲区大小有关系），总之就是一个数据包被分成了多次接收。
更具体的原因有三个，分别如下。
- 应用程序写入数据的字节大小大于套接字发送缓冲区的大小
- 进行 MSS 大小的 TCP 分段。MSS 是最大报文段长度的缩写。MSS 是 TCP 报文段中的 数据字段的最大长度。数据字段加上 TCP 首部才等于整个的 TCP 报文段。所以 MSS 并不是 TCP 报文段的最大长度，而是：MSS=TCP 报文段长度-TCP 首部长度
- 以太网的 payload 大于 MTU 进行 IP 分片。
MTU 指：一种通信协议的某一层上面所能通过的最大数据包大小。如果 IP 层有一个数据包要传，而且数据的长度比链路层的 MTU 大， 那么 IP 层就会进行分片，把数据包分成托干片，让每一片都不超过 MTU。注意，IP 分片可以发生在原始发送端主机上，也可以发生在中间路由器上。
解决粘包半包问题
由于底层的 TCP 无法理解上层的业务数据，所以在底层是无法保证数据包不被拆分和重 组的，这个问题只能通过上层的应用协议栈设计来解决，根据业界的主流协议的解决方案， 可以归纳如下。
- 在包尾增加分割符，比如回车换行符进行分割，例如 FTP 协议；
- 消息定长，例如每个报文的大小为固定长度 200 字节，如果不够，空位补空格；
- 将消息分为消息头和消息体，消息头中包含表示消息总长度（或者消息体长度） 的字段，通常设计思路为消息头的第一个字段使用 int32 来表示消息的总长度，使用 LengthFieldBasedFrameDecoder，
若有收获，就点个赞吧
0 人点赞
