title: Netty解决通信中的粘包和拆包问题 toc: true date: 2020-01-01 09:12:25 cover: https://img.paulzzh.com/touhou/random?17 categories: Netty tags: [Netty, 计算机网络]
在进行Java NIO学习时，如果客户端连续不断的向服务端发送数据包时，服务端接收的数据会出现两个数据包粘在一起的情况，这就是TCP协议中经常会遇到的粘包以及拆包的问题
<br/>
<!--more-->现在假设客户端向服务端连续发送了两个数据包，用packet1和packet2来表示，那么服务端收到的数据可以分为三种，现列举如下:
1.接收端正常收到两个数据包，即没有发生拆包和粘包的现象，此种情况不在本文的讨论范围内:
2.接收端只收到一个数据包，由于TCP是不会出现丢包的，所以这一个数据包中包含了发送端发送的两个数据包的信息，这种现象即为粘包。这种情况由于接收端不知道这两个数据包的界限，所以对于接收端来说很难处理
3.这种情况有两种表现形式，如下图。接收端收到了两个数据包，但是这两个数据包要么是不完整的，要么就是多出来一块，这种情况即发生了拆包和粘包。这两种情况如果不加特殊处理，对于接收端同样是不好处理的
TCP是个“流”协议，没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分，所以在业务上认为，一个完整的包可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题
<br/>
要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包
待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包
要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包
接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包
<br/>
由于底层的TCP无法理解上层的业务数据，所以在底层是无法保证数据包不被拆分和重组的，这个问题只能通过上层的应用协议栈设计来解决，根据业界的主流协议的解决方案，归纳如下：
<br/>
Netty这个框架，对于客户端和服务端之间的数据传输做了很好的处理，服务端在发送数据之前先对数据按一定的规则进行编码，客户端在接收到数据后按照相同的规则进行解码，这就是Netty解决粘包拆包问题的思路，下面我们详细来看一看
拆包这个工作，Netty 已经为大家备好了很多不同的拆包器。本着不重复发明轮子的原则，我们直接使用Netty现成的拆包器
Netty 中的拆包器大致如下：
每个应用层数据包的都拆分成都是固定长度的大小，比如 1024字节
对于使用固定长度的粘包和拆包场景，可以使用FixedLengthFrameDecoder，该解码一器会每次读取固定长度的消息，如果当前读取到的消息不足指定长度，那么就会等待下一个消息到达后进行补足。其使用也比较简单，只需要在构造函数中指定每个消息的长度即可。这里需要注意的是，FixedLengthFrameDecoder只是一个解码一器，Netty也只提供了一个解码一器，这是因为对于解码是需要等待下一个包的进行补全的，代码相对复杂，而对于编码器，用户可以自行编写，因为编码时只需要将不足指定长度的部分进行补全即可。
数据在编码发送的时候，也会以固定长度作为一调完整的消息
每个应用层数据包，都以换行符作为分隔符，进行分割拆分
数据在编码发送的时候，会以换行符作为一条完整的消息
每个应用层数据包，都通过自定义的分隔符，进行分割拆分。这个版本，是LineBasedFrameDecoder 的通用版本，本质上是一样的。
数据在编码发送的时候，会以一个自定义的分隔符作为一条完整的消息
将应用层数据包的长度，作为接收端应用层数据包的拆分依据。按照应用层数据包的大小，拆包。这个拆包器，有一个要求，就是应用层协议中包含数据包的长度。
LengthFieldBasedFrameDecoder与LengthFieldPrepender需要配合起来使用，其实本质上来讲，这两者一个是解码，一个是编码的关系。它们处理粘拆包的主要思想是在生成的数据包中添加一个长度字段，用于记录当前数据包的长度。LengthFieldBasedFrameDecoder会按照参数指定的包长度偏移量数据对接收到的数据进行解码，从而得到目标消息体数据；而LengthFieldPrepender则会在响应的数据前面添加指定的字节数据，这个字节数据中保存了当前消息体的整体字节数据长度。
数据在编码发送的时候，会指定当前这条消息的长度
<br/>
对于我们要做的项目，也可以自己定义消息传输的协议，在我做过的一个项目中，远洋货轮需要进行通信，大家都知道，在海上信号是很差的，每次收消息都很难保证收到的是一条完整的消息，但此时我们可以自定义协议，在消息的头部用两个字节把本次消息发送的长度加上，中间部分是消息正文，消息的尾部用四个字节保存本条消息md5值的低四位。这样，接收方在收到部分消息后，可根据消息的头部判断该条消息的具体长度，然后继续接收消息，当收到完整的消息后，在去计算接收到消息的md5四位，去跟接收的低四位做比较，如果一致，就认为是收到了完整的消息，接着根据约定的协议进行解码交流
当然，消息的校验位还是比较复杂的，需要给每台设备都指定唯一标识来区别身份等，这里就不展开叙述了
此种方案特别适合网络环境差的情况，能保证正常的通信。也经受住了实战的考验，基本可以做到消息的零丢失
<br/>
我们都知道TCP属于传输层的协议，传输层除了有TCP协议外还有UDP协议
那么UDP是否会发生粘包或拆包的现象呢？
答案是不会。UDP是基于报文发送的，从UDP的帧结构可以看出，在UDP首部采用了16bit来指示UDP数据报文的长度，因此在应用层能很好的将不同的数据报文区分开，从而避免粘包和拆包的问题。
而TCP是基于字节流的，虽然应用层和TCP传输层之间的数据交互是大小不等的数据块，但是TCP把这些数据块仅仅看成一连串无结构的字节流，没有边界；另外从TCP的帧结构也可以看出，在TCP的首部没有表示数据长度的字段，基于上面两点，在使用TCP传输数据时，才有粘包或者拆包现象发生的可能
<br/>