平时大家在网络编程过程中可能会遇到这样一种现象：客户端发送了一长串消息，服务端接受的消息揉在一起或者被拆分了，这样就会造成消息难以被正确理解。比如说有一天你特别想喝奶茶，看了一下外卖，「一点点」的奶茶看着不错，(一点点赶紧给我打钱 doge)，于是你在群里发了一条消息，想找几个人拼奶茶：
一点点奶茶有人喝吗?
结果群里同事回了一句：现在不是已经三点了吗?
你觉得莫名其妙，看了一眼同事的手机，他收到的消息是这样的两行：
一点
点奶茶有人喝吗?

哈哈，讲了一个冷笑话。用专业的术语来说这种现象就是「拆包」了，我们接着往下讲。

粘包拆包问题一般是处于应用层下的问题，在数据链路层、网络层以及传输层都有可能发生。我们日常的网络应用开发大多都在传输层进行，因此本文着重讲解传输层粘包拆包问题。

传输层有两个协议我们都很熟悉：UDP 和 TCP，UDP有消息保护边界，不会发生粘包拆包问题，因此粘包拆包问题只发生在TCP协议中。

下面用一个简单的例子来讲解什么是粘包和拆包。

假设客户端向服务端连续发送了两个数据包，用 packet1 和 packet2 来表示，那么服务端收到的数据可能有四种：

(1)第一种情况，服务端按顺序正常收到两个包，即未出现粘包和拆包的现象。

(2)第二种情况，服务端只收到一个数据包，由于 TCP 保证送达的特性，所以这一个数据包包含了客户端发送的两个数据包的信息，这种现象就是粘包。除非客户端发送的数据包有明确的规则，否则服务端不知道两个包的界限，难以处理数据。

(3)第三种情况，服务端收到了三个数据包，Package1数据包被拆分为两个数据包：Package1.1和Package1.2，这种现象就是拆包，至于拆包的原因下面会讲，服务端收到拆开的数据包也很难处理。

(4)第四种情况，一些大的数据包被拆分为小的数据包，小的数据包与其他数据包粘在一起，这种现象是将上面的粘包和拆包综合在一块。

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

例如，TCP缓冲区是1024个字节大小，如果应用一次请求发送的数据量比较小，没达到缓冲区大小，TCP则会将多个请求合并为同一个请求进行发送，站在业务上来看这就是「粘包」;

如果应用一次请求发送的数据量比较大，超过了缓冲区大小，TCP就会将其拆分为多次发送，这就是「拆包」，也就是将一个大的包拆分为多个小包进行发送。

TCP 是面向流的，会发生粘包和拆包，那作为应用程序，如何从这源源不断涌来的数据流中拆分出或者合并出有意义的信息呢?通常会有以下一些常用的方法：

(1)发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，通过读取包首部的长度字段，便知道每一个数据包的实际长度了。

如下图，在每个包前面加上包的实际长度。

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

下图每个包的固定长度为 4，接收端很容易进行区分。

(3)可以在数据包之间设置边界，如添加特殊符号，这样，接收端通过这个边界就可以将不同的数据包拆分开。

如下图，在每个包的后面加上特殊字符：/

Netty 作为一款高性能的 Java 网络编程框架，不仅是基于 Java NIO 进行了深度封装，还在客户端与服务端之间的数据传输上做了有效处理。

前面讲过 TCP 传输会出现粘包和拆包的现象，Netty 针对这一点内置了多款数据流编解码器，客户端服务端按照约定好的规则进行数据传输即可解决这个问题。

Netty 提供了多款开箱即用的编解码器：

1. (1)FixedLengthFrameDecoder 固定长度解码器

1. (2)DelimiterBasedFrameDecoder 指定分隔符解码器

1. (3)LengthFieldBasedFrameDecoder 基于数据包长度解码器

1. (4)等等……这里不再列举

TCP 是一个面向「流」的协议，所谓流就是没有界限的一长串二进制数据。在实际的传输过程中，TCP 会根据网络情况将数据包进行拆分或者拼装，如果业务没有定义一个明确的界限规则，在应用层的业务上就会出现粘包拆包的现象。