TCP粘包/拆包问题解决之道

上一章
一、介绍
- 1.1 TCP粘包/拆包问题说明
- 1.2 TCP粘包/拆包发生的原因
- 1.3 粘包问题的解决策略
二、未考虑TCP粘包导致的功能异常案例
- 2.1 TimeServerHandler的改造
- 2.2 TimeClientHandler的改造
- 2.3 运行
三、利用LineBasedFrameDecoder解决TCP粘包问题
- 3.1 支持TCP粘包的TimeServer
- 3.2 支持TCP粘包的TimeClient
- 3.3 运行
- 3.4 LineBasedFrameDecoder和StringDecoder的原理分析
下一章

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

一、介绍

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

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

1.1 TCP粘包/拆包问题说明

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

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

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

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

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

1.3 粘包问题的解决策略

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

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

下面我们就通过实际案例来看看如何使用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权威指南（五）分隔符和定长解码器

Netty权威指南（四）TCP粘包/拆包问题相关推荐

Netty（二）——TCP粘包/拆包
转载请注明出处:http://www.cnblogs.com/Joanna-Yan/p/7814644.html 前面讲到:Netty(一)--Netty入门程序主要内容: TCP粘包/拆包的基础知 ...
Java基础之《netty（28）—TCP粘包拆包原理》
一.基本介绍 1.TCP是面向连接的,面向流的,提供高可靠性服务.收发两端(客户端和服务器端)都要有一一成对的socket,因此,发送端为了将多个发给接收端的包,更有效的发给对方,使用了优化方法(Na ...
《精通并发与Netty》学习笔记（13 - 解决TCP粘包拆包（一）概念及实例演示）
一.粘包/拆包概念 TCP是一个"流"协议,所谓流,就是没有界限的一长串二进制数据.TCP作为传输层协议并不不了解上层业务数据的具体含义,它会根据TCP缓冲区的实际情况进行数据包的 ...
Netty详解（五）：Netty TCP粘包拆包
1. 概述无论是服务端还是客户端,我们读取或者发送消息的时候,都需要考虑TCP底层的粘包和拆包机制.下面我们来通过Netty来详解TCP底层的粘包和拆包机制. 2. TCP底层的粘包和拆包机制 TC ...
Netty学习总结（5）——Netty之TCP粘包/拆包问题的解决之道
无论是服务端还是客户端,读取或者发送消息的时候,都需要考虑TCP底层的粘包/拆包机制. TCP粘包/拆包 TCP是个"流"协议. 流:没有界限的一串数据.如同河里的流水,它们是连成 ...
Netty解决TCP粘包/拆包导致的半包读写问题
一.TCP粘包/拆包问题说明 TCP是个"流"协议,就是没有界限的一串数据.TCP底层并不了解上层业务数据的具体含义,它会根据TCP缓冲区的实际情况进行包拆分,所以在业务上认为,一 ...
一起学Netty（六）之 TCP粘包拆包场景
TCP编程底层都有粘包和拆包机制,因为我们在C/S这种传输模型下,以TCP协议传输的时候,在网络中的byte其实就像是河水,TCP就像一个搬运工,将这流水从一端转送到另一端,这时又分两种情况: 1)如 ...
netty解决TCP粘包/拆包导致的半包读写问题的三种方案
解决方案一:LineBasedFrameDecoder+StringDecoder来解决TCP的粘包/拆包问题只需要在客户端和服务端加上45.46两行代码并且在发送消息的时候加上换行符即可解决TCP ...
TCP——粘包/拆包
TCP粘包/拆包 TCP是个"流"协议,所谓流,就是没有界限的一串数据.大家可以想想河里的流水,它们是连成一片的,其间并没有分界线.TCP底层并不了解上层业务数据的具体含义,它会根 ...

Netty权威指南（四）TCP粘包/拆包问题