可能有人不知道 Netty 是什么，这里简单介绍下：
Netty 是一个 Java 开源框架。Netty 提供异步的、事件驱动的网络应用程序框架和工具，用以快速开发高性能、高可靠性的网络服务器和客户端程序。
也就是说，Netty 是一个基于 NIO 的客户、服务器端编程框架，使用Netty 可以确保你快速和简单的开发出一个网络应用，例如实现了某种协议的客户，服务端应用。
Netty 相当简化和流线化了网络应用的编程开发过程，例如，TCP 和 UDP 的 Socket 服务开发。
通信协议
在上一章中，我们实现了客户端和服务端的连接功能。而本小节，我们要让它们两能够说上话，即进行数据的读写。
在日常项目的开发中，前端和后端之间采用 HTTP 作为通信协议，使用文本内容进行交互，数据格式一般是 JSON。但是在 TCP 的世界里，我们需要自己基于二进制构建，构建客户端和服务端的通信协议。
我们以客户端向服务端发送消息来举个例子，假设客户端要发送一个登录请求。
对应的类如下：
public class AuthRequest {/** 用户名 **/ private String username; /** 密码 **/ private String password;}
显然：我们无法将一个 Java 对象直接丢到 TCP Socket 当中，而是需要将其转换成 byte 字节数组，才能写入到 TCP Socket 中去。即，需要将消息对象通过序列化，转换成 byte 字节数组。
同时：在服务端收到 byte 字节数组时，需要将其又转换成 Java 对象，即反序列化。不然，服务端对着一串 byte 字节处理个毛线？！
友情提示：服务端向客户端发消息，也是一样的过程哈！
序列化的工具非常多，例如说 Google 提供的 Protobuf，性能高效，且序列化出来的二进制数据较小。Netty 对 Protobuf 进行集成，提供了相应的编解码器。
但是考虑到很多可能对 Protobuf 并不了解，因为它实现序列化又增加额外学习成本。因此，仔细一个捉摸，还是采用 JSON 方式进行序列化。可能有人会疑惑，JSON 不是将对象转换成字符串吗？嘿嘿，我们再把字符串转换成 byte 字节数组就可以啦~
下面，我们新建 lab-67-netty-demo-common 项目，并在 codec 包下，实现我们自定义的通信协议。
创建 Invocation 类，通信协议的消息体。
代码如下：
/*** 通信协议的消息体 */public class Invocation { /** * 类型 */ private String type; /** * 消息，JSON 格式 */ private String message; // 空构造方法 public Invocation() { } public Invocation(String type, String message) { this.type = type; this.message = message; } public Invocation(String type, Message message) { this.type = type; this.message = JSON.toJSONString(message); } // ... 省略 setter、getter、toString 方法}
①type 属性，类型，用于匹配对应的消息处理器。如果类比 HTTP 协议，type 属性相当于请求地址。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询
②message 属性，消息内容，使用 JSON 格式。
另外，Message 是我们定义的消息接口，代码如下：
public interface Message {// ... 空，作为标记接口}
粘包与拆包
在开始看 Invocation 的编解码处理器之前，我们先了解下粘包与拆包的概念。
产生粘包和拆包问题的主要原因是，操作系统在发送 TCP 数据的时候，底层会有一个缓冲区，例如 1024 个字节大小。
如果一次请求发送的数据量比较小，没达到缓冲区大小，TCP 则会将多个请求合并为同一个请求进行发送，这就形成了粘包问题。
例如说：在《详解 Socket 编程 --- TCP_NODELAY 选项》文章中我们可以看到，在关闭 Nagle 算法时，请求不会等待满足缓冲区大小，而是尽快发出，降低延迟。
如果一次请求发送的数据量比较大，超过了缓冲区大小，TCP 就会将其拆分为多次发送，这就是拆包，也就是将一个大的包拆分为多个小包进行发送。
1）A 和 B 两个包都刚好满足 TCP 缓冲区的大小，或者说其等待时间已经达到 TCP 等待时长，从而还是使用两个独立的包进行发送；2）A 和 B 两次请求间隔时间内较短，并且数据包较小，因而合并为同一个包发送给服务端；3）B 包比较大，因而将其拆分为两个包 B_1 和 B_2 进行发送，而这里由于拆分后的 B_2 比较小，其又与 A 包合并在一起发送。
对于粘包和拆包问题，常见的解决方案有三种。
①客户端在发送数据包的时候，每个包都固定长度。比如 1024 个字节大小，如果客户端发送的数据长度不足 1024 个字节，则通过补充空格的方式补全到指定长度。
这种方式，暂时没有找到采用这种方式的案例。
②客户端在每个包的末尾使用固定的分隔符。例如 \r\n，如果一个包被拆分了，则等待下一个包发送过来之后找到其中的 \r\n，然后对其拆分后的头部部分与前一个包的剩余部分进行合并，这样就得到了一个完整的包。具体的案例，有 HTTP、WebSocket、Redis。
③将消息分为头部和消息体，在头部中保存有当前整个消息的长度，只有在读取到足够长度的消息之后才算是读到了一个完整的消息。
友情提示：方案 ③ 是 ① 的升级版，动态长度。
本文将采用这种方式，在每次 Invocation 序列化成字节数组写入 TCP Socket 之前，先将字节数组的长度写到其中。
①MessageToByteEncoder 是 Netty 定义的编码 ChannelHandler 抽象类，将泛型 消息转换成字节数组。
②#encode(ChannelHandlerContext ctx, Invocation invocation, ByteBuf out) 方法，进行编码的逻辑。
<2.1> 处，调用 JSON 的 #toJSONBytes(Object object, SerializerFeature... features) 方法，将 Invocation 转换成 字节数组。
<2.2> 处，将字节数组的长度，写入到 TCP Socket 当中。这样，后续「5.4 InvocationDecoder」可以根据该长度，解析到消息，解决粘包和拆包的问题。
友情提示：MessageToByteEncoder 会最终将 ByteBuf out 写到 TCP Socket 中。
<2.3> 处，将字节数组，写入到 TCP Socket 当中。
创建 InvocationDecoder 类，实现从 TCP Socket 读取字节数组，反序列化成 Invocation。
①ByteToMessageDecoder 是 Netty 定义的解码 ChannelHandler 抽象类，在 TCP Socket 读取到新数据时，触发进行解码。
②在 <2.1>、<2.2>、<2.3> 处，从 TCP Socket 中读取长度。
③在 <3.1>、<3.2>、<3.3> 处，从 TCP Socket 中读取字节数组，并反序列化成 Invocation 对象。
最终，添加 List<Object> out 中，交给后续的 ChannelHandler 进行处理。稍后，我们将在「6. 消息分发」小结中，会看到 MessageDispatcher 将 Invocation 分发到其对应的 MessageHandler 中，进行业务逻辑的执行。
引入依赖
创建 pom.xml 文件，引入 Netty、FastJSON 等等依赖。