上一章

上一章介绍了Netty的入门应用：
Netty权威指南（三）Netty入门应用

一、介绍

熟悉TCP编程的读者可能都知道，无论是服务端还是客户端，当我们读取或者发送消息的时候，都需要考虑TCP底层的粘包/拆包机制。

TCP是个流的协议，所谓流就是没有界限的一串数据，大家可以想想河里的水，他们是连成一片的，其间并没有分界线。TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分。所以在业务上认为，一个完整的包可能会被TCP拆分成多个包进行发送，也可能会把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包/拆包问题。

1.1 TCP粘包/拆包问题说明

假设客户端分别发送了两个数据包D1和D2给服务端，由于服务端一次读取到的字节数不是确定的，故可能存在四种情况：

1. 服务端分两次读取到两个独立的包，分别是D1和D2，没有粘包和拆包。
2. 服务端一次接受到两个数据包，D1和D1粘合在一起，被称为TCP粘包。
3. 服务端分两次接收到了两个数据包，第一次读取到了完成的D1包和D2包的部分内容，第二次读取到了D2包的剩余内容，这被称为TCP的拆包。
4. 服务端分两次接受到了两个数据包，第一次读取到了D1包的部分内容D1-1，第二次读取到了D1包的剩余内容D1-2和D2包的整包。

如果此时服务端TCP接收滑窗非常小，而数据包D1和D2比较大，很有可能会发生第五中可能 ，即服务端分多次才能将D1和D2包完全接收，期间发生多次拆包。

1.2 TCP粘包/拆包发生的原因

1. 应用程序write写入的字节大小大于套接字发送缓冲区大小。
2. 进行MSS大小的TCP分段。
3. 以太网帧的payload大于MTU进行IP分段。

1.3 粘包问题的解决策略

由于底层的TCP无法理解业务上层的业务数据，所以在地城无法保证数据包不被拆分和重组。这个问题只能通过上层的应用协议栈设计来解决，根据业界的主流协议的解决方案，可以归纳如下：

1. 消息定长，例如每个报文的大小为固定长度200字节，如果不够，空位补空格。
2. 在包尾增加回车换行符进行分割，例如FTP协议。
3. 将消息分为消息头和消息体，消息头中包含表示消息总长度（或者消息体长度）的字段，通常设计思路为消息头的第一个字段使用int32来表示消息的总长度。
4. 更复杂的应用层协议。

下面我们就通过实际案例来看看如何使用Netty提供的半包解码器来解决TCP粘包/拆包问题。

二、未考虑TCP粘包导致的功能异常案例

2.1 TimeServerHandler的改造

package com.lsh.netty;import io.netty.buffer.ByteBuf;
import io.netty.buffer.Unpooled;
import io.netty.channel.ChannelHandlerAdapter;
import io.netty.channel.ChannelHandlerContext;import java.io.UnsupportedEncodingException;
import java.util.Date;/*** @author ：LiuShihao* @date ：Created in 2021/3/8 12:39 下午* @desc ：未考虑TCP粘包导致的功能异常案例*/
public class TimeServerHandler extends ChannelHandlerAdapter {private int counter;@Overridepublic void channelRead(ChannelHandlerContext ctx, Object msg) throws UnsupportedEncodingException {ByteBuf buf = (ByteBuf) msg;byte[] req = new byte[buf.readableBytes()];buf.readBytes(req);//	处理客户端发送的消息，不截取 分隔符separatorString body = new String( req,"UTF-8").substring(0,req.length- System.getProperty("line.separator").length());System.out.println("The time server receive order :"+body +" ； the counter is " + ++counter);String currentTime = "QUERY TIME ORDER".equalsIgnoreCase(body) ? new Date(System.currentTimeMillis()).toString() : "BAD ORDER";// 返回给客户端响应，带上分隔符currentTime =currentTime + System.getProperty("line.separator");ByteBuf resp = Unpooled.copiedBuffer(currentTime.getBytes());ctx.writeAndFlush(resp);}@Overridepublic void channelReadComplete(ChannelHandlerContext ctx) throws  Exception{ctx.flush();}@Overridepublic void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {ctx.close();}}

每读到一条消息后，就计一次数，然后发送应答消息给客户端。按照设计服务端接收到的消息总数应该与跟客户端发送的消息总数相同。而且请求消息删除回车换行符后应该为“QUERY TIME ORDER”

2.2 TimeClientHandler的改造

package com.lsh.netty;import io.netty.buffer.ByteBuf;
import io.netty.buffer.Unpooled;
import io.netty.channel.ChannelHandlerAdapter;
import io.netty.channel.ChannelHandlerContext;/*** @author ：LiuShihao* @date ：Created in 2021/3/17 12:13 下午* @desc ：*/
public class TimeClientHandler extends ChannelHandlerAdapter {private int counter;private byte[] req;public TimeClientHandler() {//构造方法 初始化 req字节数组 请求消息为 QUERY TIME ORDER 加上分隔符req = ("QUERY TIME ORDER" + System.getProperty("line.separator")).getBytes();}@Overridepublic void channelActive(ChannelHandlerContext ctx){ByteBuf message = null;//向服务端发送一百次请求for (int i = 0; i < 100 ; i++) {message = Unpooled.buffer(req.length);message.writeBytes(req);ctx.writeAndFlush(message);}}/***读取服务端的响应 */@Overridepublic void channelRead(ChannelHandlerContext ctx,Object msg) throws Exception{ByteBuf buf = (ByteBuf) msg;//根据ByteBuf的长度创建响应长度的字节数组byte[] req = new byte[buf.readableBytes()];//将ByteBuf中的消息读到字节数组中buf.readBytes(req);//根据字节数组构造字符串String body = new String(req, "UTF-8");System.out.println("Now is :"+body +" ; the counter is "+ ++counter);}@Overridepublic void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {System.out.println("Unexpected exception from downstrean : "+ cause.getMessage());ctx.close();}}

2.3 运行

服务端控制台：

服务端运行结果表明它只接收到了两条消息。

客户端控制台：

按照设计初衷，客户端应该受到100条当前系统时间的消息，但实际上只收到了一条，因为服务端只收到了两条请求消息，所以实际服务端只发送了2条应答，由于消息不满足查询条件，所以返回了BAD ORDER，但实际上客户端也只收到了一条包含2条BAD ORDER指令的消息，说明服务端返回的应答消息也发生了粘包。

三、利用LineBasedFrameDecoder解决TCP粘包问题

为了解决TCP粘包/拆包问题导致的半包读写问题，Netty默认提供了多种编码器应用于处理半包，只要能熟练掌握这些类库的使用，TCP粘包问题从此会变得非常的容易，你甚至不需要关心他们，这也是其他NIO框架和原生的NIO API所无法匹敌的。

3.1 支持TCP粘包的TimeServer

在原理的TimeServerHandler之前新增了两个解码器：LineBasedFrameDecoder和StringDecoder。

3.2 支持TCP粘包的TimeClient

3.3 运行

程序的结果完全符合预期，说明通过使用LineBasedFrameDecoder和StringDecoder成功解决了TCP粘包导致的读半包问题，对于使用者来说，只要将支持半包解码的Handler添加到ChannelPipeline中即可，不需要写额外的代码，用户使用起来非常简单。

3.4 LineBasedFrameDecoder和StringDecoder的原理分析

LIneBasedFrameDecoder的工作原理是它依次遍历ByteBuf中的可读字节，判断看到是否有"/n"或者"/n/r"，如果有，就以次位置为结束位置，从可读索引到结束位置区间字节就组成了一行，它是以换行符为结束标志的解码器，支持携带结束符和不携带结束符两种解码方式，同时支持配置单行的最大长度。如果连续读取到最大长度仍然没有发现换行符，就会抛出异常，同时忽略到之前读到的异常码流。

StringDecoder的功能非常简单，就是将接收到的对象转换成字符串，然后继续调用后面的Handler。LineBasedFrameDecoder + StringDecoder 组合就是按行切换的文本解码器，它被设计用来支持TCP的粘包和拆包。

如果发送的消息不是以换行符结束的怎么办？或者没有回车换行符，靠消息头中的长度字段来分包怎么办？是不是需要自己写半包解码器？答案是否定的，Netty提供了多种TCP粘包/拆包的解码器，用来满足用户的不同诉求。

下一章

下一章介绍 LineBasedFrameDecoder 和 FixedLengthBasedDecoder 另外两种使用的解码器，前者可以自动完成以分隔符做结束标志的消息的解码，后者可以自动完成对定长消息的解码，他们都能解决TCP粘包/拆包导致的读半包问题。

Netty权威指南（五）分隔符和定长解码器