转载

Netty 中粘包/拆包处理

TCP 是基于流传输的协议，请求数据在其传输的过程中是没有界限区分，所以我们在读取请求的时候，不一定能获取到一个完整的数据包。如果一个包较大时，可能会切分成多个包进行多次传输。同时，如果存在多个小包时，可能会将其整合成一个大包进行传输。这就是 TCP 协议的粘包/拆包概念。

本文基于 Netty5 进行分析

粘包/拆包描述

假设当前有 123 和 abc 两个数据包，那么他们传输情况示意图如下：

Netty 中粘包/拆包处理

I 为正常情况，两次传输两个独立完整的包。
II 为粘包情况， 123 和 abc 封装成了一个包。
III 为拆包情况，图中的描述是将 123 拆分成了 1 和 23 ，并且 1 和 abc 一起传输。 123 和 abc 也可能是 abc 进行拆包。甚至 123 和 abc 进行多次拆分也有可能。

Netty 粘包/拆包问题

为突出 Netty 的粘包/拆包问题，这里通过例子进行重现问题，以下为突出问题的主要代码：

服务端：

客户端：

以上代码中，我们第一反应理解的是，如果非异常情况下客户端所有数据发送成功，并且服务端全部接收到。那么从打印信息中可以看到客户端的发送次数 i 和服务端的接收消息计数 i 应该是相同的数。那么下面通过运行程序，查看打印结果。

Netty 中粘包/拆包处理

如上图所示， 【】 中的最后一个数字与 [] 中数字对上的是已独立完整的包接收到 （粘包/拆包示意图中的情况 I） 。但是 【】 中为 37 和 38 的出现了粘包情况 （粘包/拆包示意图中的情况 II） ，两条数据粘合在一起。

Netty 中粘包/拆包处理

上图中可以看到 【】 中 167 的数据被拆分为了两部分（图中画绿线数据），该情况为拆包 （粘包/拆包示意图中的情况 III） 。

上面程序没有考虑到 TCP 的粘包/拆包问题，所以如果是我们实际应用的程序的话，不能保证数据的正常情况，就会导致程序异常。

Netty 解决粘包/拆包问题

LineBasedFrameDecoder 换行符处理

Netty 的强大，方便，简单使用的优势，在粘包/拆包问题上也提供了多种编解码解决方案，并且很容易理解和掌握。这里使用 LineBasedFrameDecoder 和 StringDecoder（将接收到的对象转换成字符串）来解决粘包/拆包问题。只需在服务端和客户端分别添加 LineBasedFrameDecoder 和 StringDecoder解码器，因为是双向会话，所以两端都要添加，由于我一开始就添加 StringDecoder 编码器，所以只需添加 LineBasedFrameDecoder 就够了。服务端：

Netty 中粘包/拆包处理