点击上方“方志朋”，选择“设为星标”

回复”666“获取新整理的面试资料

作者：Java技术剑

来源：https://urlify.cn/IF3YJv

在进行Java NIO学习时，发现，如果客户端连续不断的向服务端发送数据包时，服务端接收的数据会出现两个数据包粘在一起的情况，这就是TCP协议中经常会遇到的粘包以及拆包的问题。

一、什么是粘包和拆包？

现在假设客户端向服务端连续发送了两个数据包，用packet1和packet2来表示，那么服务端收到的数据可以分为三种，现列举如下：

1.接收端正常收到两个数据包，即没有发生拆包和粘包的现象，此种情况不在本文的讨论范围内。

2.接收端只收到一个数据包，由于TCP是不会出现丢包的，所以这一个数据包中包含了发送端发送的两个数据包的信息，这种现象即为粘包。这种情况由于接收端不知道这两个数据包的界限，所以对于接收端来说很难处理。

3.这种情况有两种表现形式，如下图。接收端收到了两个数据包，但是这两个数据包要么是不完整的，要么就是多出来一块，这种情况即发生了拆包和粘包。这两种情况如果不加特殊处理，对于接收端同样是不好处理的。

TCP是个“流”协议，没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分，所以在业务上认为，一个完整的包可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题。

二、粘包、拆包发生的原因

要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包。

待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。

要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包。

接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。

三、粘包、拆包解决办法

由于底层的TCP无法理解上层的业务数据，所以在底层是无法保证数据包不被拆分和重组的，这个问题只能通过上层的应用协议栈设计来解决，根据业界的主流协议的解决方案，归纳如下：

消息定长。发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。

设置消息边界。服务端从网络流中按消息边界分离出消息内容。在包尾增加回车换行符进行分割，例如FTP协议。

将消息分为消息头和消息体，消息头中包含表示消息总长度（或者消息体长度）的字段。

更复杂的应用层协议，比如Netty中实现的一些协议都对粘包、拆包做了很好的处理。

四、Netty的拆包解决方案

Netty这个框架，对于客户端和服务端之间的数据传输做了很好的处理，服务端在发送数据之前先对数据按一定的规则进行编码，客户端在接收到数据后按照相同的规则进行解码，这就是Netty解决粘包拆包问题的思路，下面我们详细来看一看。

拆包这个工作，Netty 已经为大家备好了很多不同的拆包器。本着不重复发明轮子的原则，我们直接使用Netty现成的拆包器。

Netty 中的拆包器大致如下：

1.固定长度的拆包器 FixedLengthFrameDecoder

每个应用层数据包的都拆分成都是固定长度的大小，比如 1024字节。

对于使用固定长度的粘包和拆包场景，可以使用FixedLengthFrameDecoder，该解码一器会每次读取固定长度的消息，如果当前读取到的消息不足指定长度，那么就会等待下一个消息到达后进行补足。其使用也比较简单，只需要在构造函数中指定每个消息的长度即可。这里需要注意的是，FixedLengthFrameDecoder只是一个解码一器，Netty也只提供了一个解码一器，这是因为对于解码是需要等待下一个包的进行补全的，代码相对复杂，而对于编码器，用户可以自行编写，因为编码时只需要将不足指定长度的部分进行补全即可。

数据在编码发送的时候，也会以固定长度作为一调完整的消息。

2.行拆包器 LineBasedFrameDecoder

每个应用层数据包，都以换行符作为分隔符，进行分割拆分。

数据在编码发送的时候，会以换行符作为一条完整的消息。

3.分隔符拆包器 DelimiterBasedFrameDecoder

每个应用层数据包，都通过自定义的分隔符，进行分割拆分。这个版本，是LineBasedFrameDecoder 的通用版本，本质上是一样的。

数据在编码发送的时候，会以一个自定义的分隔符作为一条完整的消息。

4.基于数据包长度的拆包器 LengthFieldBasedFrameDecoder

将应用层数据包的长度，作为接收端应用层数据包的拆分依据。按照应用层数据包的大小，拆包。这个拆包器，有一个要求，就是应用层协议中包含数据包的长度。

LengthFieldBasedFrameDecoder与LengthFieldPrepender需要配合起来使用，其实本质上来讲，这两者一个是解码，一个是编码的关系。它们处理粘拆包的主要思想是在生成的数据包中添加一个长度字段，用于记录当前数据包的长度。LengthFieldBasedFrameDecoder会按照参数指定的包长度偏移量数据对接收到的数据进行解码，从而得到目标消息体数据；而LengthFieldPrepender则会在响应的数据前面添加指定的字节数据，这个字节数据中保存了当前消息体的整体字节数据长度。

数据在编码发送的时候，会指定当前这条消息的长度。

五、实战：远扬通信中自定义协议的粘包、拆包解决方案

对于我们要做的项目，也可以自己定义消息传输的协议，在我做过的一个项目中，远洋货轮需要进行通信，大家都知道，在海上信号是很差的，每次收消息都很难保证收到的是一条完整的消息，但此时我们可以自定义协议，在消息的头部用两个字节把本次消息发送的长度加上，中间部分是消息正文，消息的尾部用四个字节保存本条消息md5值的低四位。这样，接收方在收到部分消息后，可根据消息的头部判断该条消息的具体长度，然后继续接收消息，当收到完整的消息后，在去计算接收到消息的md5四位，去跟接收的低四位做比较，如果一致，就认为是收到了完整的消息，接着根据约定的协议进行解码交流。

当然，消息的校验位还是比较复杂的，需要给每台设备都指定唯一标识来区别身份等，这里就不展开叙述了。

此种方案特别适合网络环境差的情况，能保证正常的通信。也经受住了实战的考验，基本可以做到消息的零丢失。

六、总结，一个面试题

我们都知道TCP属于传输层的协议，传输层除了有TCP协议外还有UDP协议。

那么UDP是否会发生粘包或拆包的现象呢？

答案是不会。UDP是基于报文发送的，从UDP的帧结构可以看出，在UDP首部采用了16bit来指示UDP数据报文的长度，因此在应用层能很好的将不同的数据报文区分开，从而避免粘包和拆包的问题。

而TCP是基于字节流的，虽然应用层和TCP传输层之间的数据交互是大小不等的数据块，但是TCP把这些数据块仅仅看成一连串无结构的字节流，没有边界；另外从TCP的帧结构也可以看出，在TCP的首部没有表示数据长度的字段，基于上面两点，在使用TCP传输数据时，才有粘包或者拆包现象发生的可能。

热门内容：分布式与集群的区别究竟是什么？碰到Maven依赖冲突，想砸电脑？这个IDEA插件必须了解一下...
2020年Java框架排行榜，谁居榜首？
如何优雅地根治null值引起的Bug！史上最全的数据库面试题，不看后悔篇！解锁新姿势：探讨复杂的 if-else 语句“优雅处理”的思路最近面试BAT，整理一份面试资料《Java面试BAT通关手册》，覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。
获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。
明天见(｡･ω･｡)ﾉ♡