rocketMQ源码解析网络通信篇：自定义协议

粘包半包问题

  以netty为例，接收消息的单位是ByteBuf ，但是TCP是按照字节流来发送数据，所以就需要进行二次拼装，将字节流拼装成ByteBuf ，这就避不可免会产生粘包和半包的问题，由于tcp协议的机制（面向链接的三次握手的可靠协议）客户端和服务端会维持一个链接，可以持续不断地将多个数据包发向服务器，当数据包比较小的时候，tcp会启用nagle算法对较小的数据包进行合并，这样的话就产生了粘包，如果数据包比较大，tcp会将数据包分割为多个，这样就产生了半包现象。
  由于TCP并不能理解上层业务数据，所以它并不能保证数据包不被拆分和重组，这个问题只能在应用层协议解决，目前主流的解决方案如下：
1、特殊分隔符
2、消息定长 例如每个报文大小为100字节，不够补空格
3、分为消息头和消息体 消息头中第一个字段为消息总长度

如何自定义协议

  典型的自定义协议（ccx-rpc）由消息头和消息体组成。格式如下：

±–±--±------±–±--±–±--±----------±--------±-------±–±--±–±--±–±--±–±--+
| magic |version| full length |messageType|serialize|compress| RequestId |
±–±--±------±–±--±–±--±----------±--------±-------±–±--±–±--±–±--±–±--+
| |
| body |
| |
| … … |
±---------------------------------------------------------------------------------------------+
2B magic（魔数）
1B version（版本）
4B full length（消息长度）
1B messageType（消息类型）
1B serialize（序列化类型）
1B compress（压缩类型）
8B requestId（请求的Id）
body（object类型数据）

字段解释

魔数

  是通信双方协商的一个暗号，两个字节，用户在服务端收到数据时先解析魔数进行正确性对比，如果不匹配，则认为是非法数据，可采用丢弃数据包、关闭连接等方式增强安全性。

版本

  为了应对业务需求的变化，可能需要对自定义协议的结构或字段进行改动。不同版本的协议对应的解析方法也是不同的。所以在生产级项目中强烈建议预留协议版本这个字段。

消息长度

  记录了整个消息的长度，这个字段是报文分包的关键。

消息类型

  消息类型包括，普通请求、普通响应、心跳 ping、心跳 pong。解码器可以根据消息类型来确定解析的类型。

序列化类型

  通过这个类型来确定使用哪种序列化方式，将字节流序列化成对应的对象。

压缩类型

  序列化的字节流，还可以进行压缩，使得体积更小，在网络传输更快，但是同时会消耗 CPU 资源。
  如果使用压缩效果好的序列化器，可以考虑不适用压缩。

requestId

  每个请求分配好请求Id，这样响应数据的时候，才能对的上。使用 8 字节的 long 类型，可以支持更多的请求。