TCP 粘包半包 netty 编解码 三者关系

何为粘包 / 半包？

对方一次性接收了多条消息这种现象，我们就称之为 粘包现象。
对方多次接收了不完整消息这种现象，我们就称之为 半包现象。

粘包的原因：
发送方发送的消息 < 缓冲区大小
接收方读取消息不及时

半包的原因
类比粘包，如果发送的消息太大，已经 超过了缓冲区的大小，这时候就 必须拆分发送，也就 形成了半包现象。
半包的原因：
发送方发送的消息 > 缓冲区的大小
发送方发送的消息 > 协议的 MTU

表面原因：
1 发送消息的时候如果消息太小，先放到缓冲区里面放着，等数据够多了再一起发送；如果消息太大，则拆成多个消息分批发送。
2 那么，本质原因是缓冲区吗？当然不是，缓冲区的存在是为了提高发送消息的效率。

本质原因是： TCP 是流式协议，消息无边界
TCP 协议本身像水流一样，源源不断，完全不知道消息的边界在哪里。

UDP 协议不会出现粘包 / 半包现象，它的消息是有明确边界的，不会像 TCP 一样出现粘包 / 半包现象。

怎么解决粘包 / 半包？
根本方法：解决消息的边界
业界就衍生出了三种常用的解决粘包 / 半包问题的方法：

1. 定长法、
2. 分割符法、
3. 长度 + 内容法

Netty 为什么解码类后面都是 *FrameDecoder 呢？

那是因为被解码之后的消息又叫作一帧一帧的消息，所以称为 “ 帧解码器 。

为什么需要一次编解码和二次编解码呢？
一次解码主要用于解决粘包 / 半包的问题，将缓冲区中的字节数组按照协议本身的格式进行分割，其实，分割后的数据还是字节数组。
二次解码，可以将字节数组转换成 Java 对象。

既然一次解码的时候都已经解出了对应的字节数组，何不顺势将其序列化成 Java 对象呢？
所以，一次编解码和二次编解码可以合并吗？
可以，但是不建议，这里主要运用了分层的思想。

举个简单的例子，
比如一次编解码我们采用的是 “ 长度 + 内容法 ” ，二次编解码一开始使用的是 XML ，后面换成了 JSON ，其实一次编解码我们不需要修改，只需要修改二次编解码就可以了。
但是，如果二者合为一体了，那我们在后面实现 JSON 编解码的时候又要重新实现一下 “ 长度 + 内容 ” 的一次编解码的过程。

分层的思想很重要，在 Java 中随处可见，比如，著名的 MVC 分层思想。