你好，我是yes。

Netty 系列继续更新，这篇文章我们来聊聊网络传输中的粘包/半包问题。

话不多说，发车。

通俗的例子

这里先举个可能不太恰当，但是很容易理解的例子。

比如，平时我们要寄快递，如果东西太大的话，那么就需要拆成几个包裹来邮寄。

收件人仅收到个别包裹的时候，东西是不完整的，对应到网络传输中，这种情况就叫半包。

只有等接收到全部包裹时，这个东西（传输的信息）才完整，所以半包情况下无法解析出完整的数据，需要等，等接收到全部包裹。

那么问题来了，如何知晓已经收到全部包裹了呢？下文我们再作分析。

再比如，快过年了，我打算给家里的亲戚送点礼物，给每位长辈送个手表，我们都知道手表的体积不大，并且我家里人都住在一个村，所以把给各长辈的礼物打包在一个包裹里邮寄，这样能节省运费。

这种把本应该分多个包传输的数据合成一个包发送的情况，对应到网络传输中，就叫粘包。

看完这个例子之后，应该对粘包与半包有点感觉了，接下来我们看下网络中实际的情况。

实际情况

粘包与半包只有在 TCP 传输的时候才会有，像 UDP 是不会有这种情况的，原因是因为 TCP 是面向流的，数据之间没有界限的，而 UDP 是有的界限的。

如果熟悉 TCP 和 UDP 报文格式的同学肯定知道，TCP 的包没有报文长度，而 UDP 的包有报文长度，这也说明了 TCP 为什么是流式。

所以我为什么说上面的例子不太恰当，因为现实生活中快递的包裹之间其实是有界限的，TCP 则像流水，没有明确的界限。

然后 TCP 有发送缓冲区的概念，UDP 实际上是没这个概念。

假设 TCP 一次传输的数据大小超过发送缓冲区大小，那么一个完整的报文就需要被拆分成两个或更多的小报文，这可能会产生半包的情况，当接收端收到不完整的数据，是无法解析成功的。

如果 TCP 一次传输的数据大小小于发送缓冲区，那么可能会跟别的报文合并起来一块发送，这就是粘包。

此时接收端也无法正常解析报文，需要将其拆成多个正确的报文，才能正常解析。

关于粘包与半包，我还看到有拿 MTU （最大传输单元）说事的，如果发送的数据大于 MTU 那就会出现拆包，导致半包的情况。

我个人觉得这里有点不对，简单理解下，UDP 也是要遵循 MTU 的呀，对吧？那它咋不会发生半包呢？

我们接着来看如何解决粘包与半包。

那如何解决粘包与半包问题呢？

• 粘包：这个思路其实很清晰，就是把它拆开呗，具体就是看怎么拆了，比如我们可以固定长度，我们规定每个包都是10个字节，那么就10个字节切一刀，这样拆开解析就 ok 了。

• 半包：半包其实就是信息还不完整，我们需要等接收到全部的信息之后再作处理，当我们识别这是一个不完整的包时候，我们先 hold 住，不作处理，等待数据完整再处理。这里关键点在于，我们如何才能知道此时完整了？上面说的固定长度其实也是一点，当然还有更多更好的解决方案，我们接着往下看。

实际常见解决粘包与半包问题有三个方案：

• 固定长度
• 分隔符
• 固定长度字段+内容

为了说明方便，以下没有按二进制的位等单位来描述。

固定长度

这个其实很简单，比如现在要传输 ABC、EF 这两个包，如果不做处理接收端很可能收到的是 AB、CEF 或者 ABCE、F 等等。

这时候我们固定长度，我们规定每个报文长度都是 3，如果一个报文实际数据不足 3，那么就用空字符填充一下 。

所以我们发送的报文是 ：

接收到的情况可能是：

但我们是按照 3 位来处理的，所以一次只会按照 3 位来解析，所以第一次虽然收到的数据是 ABCE，但我们就解析 3 位，即解析出 ABC，留着了个 E，等我们要继续解析 3 位的时候，发现长度不足 3，所以我们暂时先不管，先等等。

后面等到了 F“”，我们发现当下数据又满足 3 位了，所以我们接着解析 EF“” 。

这样就解决了粘包与半包问题。

对应到 Netty 中的实现就是 FixedLengthFrameDecoder，这个类来实现固定长度的解码。

核心逻辑就是我上面说的，我们来看下源码，很简单：

固定长度的优点：简单。

缺点：固定长度很僵硬，不易于扩展，且如果设置过大来满足业务场景的话，会导致空间浪费，因为不足长度的需要填充。

分隔符

这个应该很好理解， 还是拿  ABC、EF 这两个包举例，我在写完 ABC后，插入一个分号，组成ABC;，EF 同理：

这样以分隔符为界限来切分无界限的 TCP 流，来解决粘包与半包问题，这个应该很好理解，既然你 TCP 没界限，我业务上给你搞个界限。

对应到 Netty 中的实现就是 DelimiterBasedFrameDecoder，具体源码就不贴了，有点长，不过道理还是简单的。

一直解析，等识别到分隔符之后，说明前面的数据完整了，于是解析前面的数据，然后继续往后扫描解析。

分隔符的优点：简单，也不会浪费空间。

缺点：需要对内容本身进行处理，防止内容内出现分隔符，这样就会导致错乱，所以需要扫描一遍传输的数据将其转义，或者可以用 base64 编码数据，用 64 个之外的字符作为分隔符即可。

分隔符的处理方式在业界也是常用的，比如 Redis 就用换行符来分隔。

固定长度字段+内容

这个也很好理解，比如协议规定固定 4 位存放内容的长度，这样内容就可以伸缩：

还是拿 ABC、EF 这两个包举例：

解析流程是：先获取 4 位，如果当前收到的数据不够 4 位，那就再等等，够 4 位之后解析得到长度是 3，所以我再往后取 3 位，同样数据如果不够 3 位就再等等，够了的话就解析，这样就获取一个完整的包了。

然后接着往后获取 4 位，解析得到 2，同理根据 2 往后再取 2 位，解析得到 EF。

这种方式就是先解析固定长度的字段，获得后面内容的长度，根据内容长度来获取内容，从而得到一个完整的报文。

对应到 Netty 中的实现就是 LengthFieldBasedFrameDecoder，具体源码就不贴了，有点长，

固定长度字段+内容的优点：可以根据固定字段精准定位，也不用扫描转义字符。

缺点：固定长度字段的设计比较困难，大了浪费空间，毕竟每个报文都带这个长度，小了可能不够用。

总结

好了，我们总结一下。

因为 TCP 是面向流的协议，且利用缓冲区来提高发送的效率，所以会导致粘包/半包情况的发生。

对于这种情况，我们可以在报文上动手脚，可以约定固定长度的报文，或埋入分隔符，或利用固定长度字段+内容等常见的三种方式来解决粘包、半包的问题。

以上三种在 Netty 中都有现成实现类，可直接使用：

• FixedLengthFrameDecoder，固定长度
• DelimiterBasedFrameDecoder，分隔符
• LengthFieldBasedFrameDecoder，定长度字段+内容

建议实验一下，会有更清晰的认识。

最后

好了，关于粘包与半包的内容就写到这了，关于源码就不分析了，思路比较重要。

如果你有疑问可以留言区提问。

Netty 的系列还没写完，后面会写写无锁队列和 netty 的内存管理机制，等我输出哈。

如果你没看过我之前的 Netty 系列，可以点击这里查看，一共写了 12 篇。

我是yes，从一点点到亿点点，我们下篇见~

ps：封面是minnie