1 何为粘包 / 半包? 对方一次性接收了多条消息这种现象,我们就称之为 粘包现象。 对方多次接收了不完整消息这种现象,我们就称之为 半包现象。
粘包的原因: 发送方发送的消息 < 缓冲区大小 接收方读取消息不及时
半包的原因 类比粘包,如果发送的消息太大,已经 超过了缓冲区的大小,这时候就 必须拆分发送,也就 形成了半包现象。 半包的原因: 发送方发送的消息 > 缓冲区的大小 发送方发送的消息 > 协议的 MTU
表面原因: 1 发送消息的时候如果消息太小,先放到缓冲区里面放着,等数据够多了再一起发送;如果消息太大,则拆成多个消息分批发送。 2 那么,本质原因是缓冲区吗?当然不是,缓冲区的存在是为了提高发送消息的效率。 本质原因是: TCP 是流式协议,消息无边界 TCP 协议本身像水流一样,源源不断,完全不知道消息的边界在哪里。
UDP 协议不会出现粘包 / 半包现象,它的消息是有明确边界的,不会像 TCP 一样出现粘包 / 半包现象。
怎么解决粘包 / 半包? 根本方法:解决消息的边界
业界就衍生出了三种常用的解决粘包 / 半包问题的方法: 定长法、 分割符法、 长度 + 内容法 Netty 为什么解码类后面都是 *FrameDecoder 呢?那是因为被解码之后的消息又叫作一帧一帧的消息,所以称为 “ 帧解码器 。
为什么需要一次编解码和二次编解码呢? 一次解码主要用于解决粘包 / 半包的问题,将缓冲区中的字节数组按照协议本身的格式进行分割,其实,分割后的数据还是字节数组。 二次解码,可以将字节数组转换成 Java 对象。
既然一次解码的时候都已经解出了对应的字节数组,何不顺势将其序列化成 Java 对象呢?所以,一次编解码和二次编解码可以合并吗? 可以,但是不建议,这里主要运用了分层的思想。 举个简单的例子, 比如一次编解码我们采用的是 “ 长度 + 内容法 ” ,二次编解码一开始使用的是 XML ,后面换成了 JSON ,其实一次编解码我们不需要修改,只需要修改二次编解码就可以了。但是,如果二者合为一体了,那我们在后面实现 JSON 编解码的时候又要重新实现一下 “ 长度 + 内容 ” 的一次编解码的过程。分层的思想很重要,在 Java 中随处可见,比如,著名的 MVC 分层思想。
|