【Netty】粘包和拆包问题及解决

发布时间:2023年12月25日

什么是粘包和拆包

粘包和拆包是TCP网络编程中不可避免的,无论是服务端还是客户端,当我们读取或者发送消息的时候,都需要考虑TCP底层的粘包/拆包机制。

TCP是个“流”协议,所谓流,就是没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义,它会根据TCP缓冲区的实际情况进行包的划分,所以在业务上认为,一个完整的包可能会被TCP拆分成多个包进行发送,也有可能把多个小的包封装成一个大的数据包发送,这就是所谓的TCP粘包和拆包问题。

如图所示,假设客户端分别发送了两个数据包D1和D2给服务端,由于服务端一次读取到的字节数是不确定的,故可能存在以下4种情况。

  1. 服务端分两次读取到了两个独立的数据包,分别是D1和D2,没有粘包和拆包

在这里插入图片描述

  1. 服务端一次接收到了两个数据包,D1和D2粘合在一起,被称为TCP粘包

在这里插入图片描述

  1. 如果D2的数据包比较大, 服务端分两次读取到了两个数据包,第一次读取到了完整的D1包和D2包的部分内容,第二次读取到了D2包的剩余内容,这被称为TCP拆包

在这里插入图片描述

  1. 如果D1, D2的数据包都很大, 服务端分多次才能将D1和D2包接收完全,期间发生多次拆包

在这里插入图片描述

TCP粘包和拆包产生的原因:

数据从发送方到接收方需要经过操作系统的缓冲区,而造成粘包和拆包的主要原因就在这个缓冲区上。粘包可以理解为缓冲区数据堆积,导致多个请求数据粘在一起,而拆包可以理解为发送的数据大于缓冲区,进行拆分处理。

粘包和拆包代码演示

粘包

客户端

修改通道就绪事件,发送消息的代码:

/**
 * 通道就绪事件
 *
 * @param channelHandlerContext
 * @throws Exception
 */
@Override
public void channelActive(ChannelHandlerContext channelHandlerContext) throws Exception {
    for (int i = 0; i < 10; i++) {
        channelHandlerContext.writeAndFlush(Unpooled.copiedBuffer("你好呀.我是Netty客户端" + i, CharsetUtil.UTF_8));
    }
}

循环多次发送消息。

服务端

修改通道读取事件,并统计读取次数:

public int count = 0;

/**
 * 通道读取事件
 *
 * @param channelHandlerContext
 * @param o
 * @throws Exception
 */
@Override
public void channelRead(ChannelHandlerContext channelHandlerContext, Object o) throws Exception {
    ByteBuf byteBuf = (ByteBuf) o;
    System.out.println("客户端发送过来的消息:" + byteBuf.toString(CharsetUtil.UTF_8));
    System.out.println("读取次数:"+(++count));
}

服务端运行结果:

服务端启动成功.
端口绑定成功!
客户端发送过来的消息:你好呀.我是Netty客户端0你好呀.我是Netty客户端1你好呀.我是Netty客户端2你好呀.我是Netty客户端3你好呀.我是Netty客户端4你好呀.我是Netty客户端5你好呀.我是Netty客户端6你好呀.我是Netty客户端7你好呀.我是Netty客户端8你好呀.我是Netty客户端9
读取次数:1

可以看到客户端多次发送的消息,服务端只接受一次数据就全部接受了,这就是沾包。

拆包

客户端

修改通道就绪事件,发送消息的代码:

/**
 * 通道就绪事件
 *
 * @param channelHandlerContext
 * @throws Exception
 */
@Override
public void channelActive(ChannelHandlerContext channelHandlerContext) throws Exception {
    //一次发送102400
    char[] chars = new char[102400];
    Arrays.fill(chars, 0, 102398, 'a');
    chars[102399] = '\n';
    for (int i = 0; i < 10; i++) {
        channelHandlerContext.writeAndFlush(Unpooled.copiedBuffer(chars, CharsetUtil.UTF_8));
    }
}

服务端

修改通道读取事件,并统计读取次数:

public int count = 0;

/**
 * 通道读取事件
 *
 * @param channelHandlerContext
 * @param o
 * @throws Exception
 */
@Override
public void channelRead(ChannelHandlerContext channelHandlerContext, Object o) throws Exception {
    ByteBuf byteBuf = (ByteBuf) o;
    System.out.println("客户端发送过来的消息:" + byteBuf.toString(CharsetUtil.UTF_8));
    System.out.println("长度是:" + byteBuf.readableBytes());
    System.out.println("读取次数:"+(++count));
}

运行结果

在这里插入图片描述

可以看到,客户端一次发送的消息,最后服务端分了18次来接收。这就是拆包。

粘包和拆包解决

业内解决方案

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

  • 消息长度固定,累计读取到长度和为定长LEN的报文后,就认为读取到了一个完整的信息
  • 将换行符作为消息结束符
  • 将特殊的分隔符作为消息的结束标志,回车换行符就是一种特殊的结束分隔符
  • 通过在消息头中定义长度字段来标识消息的总长度

Netty中的粘包和拆包解决方案

  • 固定长度的拆包器 FixedLengthFrameDecoder,每个应用层数据包的都拆分成都是固定长度的大小
  • 行拆包器 LineBasedFrameDecoder,每个应用层数据包,都以换行符作为分隔符,进行分割拆分
  • 分隔符拆包器 DelimiterBasedFrameDecoder,每个应用层数据包,都通过自定义的分隔符,进行分割拆分
  • 基于数据包长度的拆包器 LengthFieldBasedFrameDecoder,将应用层数据包的长度,作为接收端应用层数据包的拆分依据。按照应用层数据包的大小拆包。这个拆包器,有一个要求,就是应用层协议中包含数据包的长度。

代码实现

  1. LineBasedFrameDecoder解码器

使用行拆包器来拆分,解决粘包问题。

服务端向pipeline中添加自定义业务处理handler时,加行拆包器

ch.pipeline().addLast(new LineBasedFrameDecoder(2048));

客户端发每次消息后面加换行符

ctx.writeAndFlush(Unpooled.copiedBuffer("你好呀,我是Netty客户端"+i+"\n", CharsetUtil.UTF_8));
  1. DelimiterBasedFrameDecoder解码器

使用分隔符拆包器,自费定义分隔符,解决拆包问题

服务端向pipeline中添加自定义业务处理handler时,加自定义分隔符拆包器

ByteBuf byteBuf = Unpooled.copiedBuffer("$".getBytes(StandardCharsets.UTF_8)); 
ch.pipeline().addLast(new DelimiterBasedFrameDecoder(2048, byteBuf));

客户端发每次消息后面加换行符"$"

ctx.writeAndFlush(Unpooled.copiedBuffer("你好呀,我是Netty客户端"+i+"$", CharsetUtil.UTF_8));
文章来源:https://blog.csdn.net/qq_43745578/article/details/135198833
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。