Netty如何解决TCP的粘包半包问题？

现象演示

服务端：

public class Server { private int port; public Server(int port) { this.port = port; } public void start(){ EventLoopGroup bossGroup = new NioEventLoopGroup(); EventLoopGroup workGroup = new NioEventLoopGroup(); ServerBootstrap server = new ServerBootstrap().group(bossGroup,workGroup) .channel(NioServerSocketChannel.class) .childHandler(new ServerChannelInitializer()); try { ChannelFuture future = server.bind(port).sync(); future.channel().closeFuture().sync(); } catch (InterruptedException e) { System.out.println("server start fail"); }finally { bossGroup.shutdownGracefully(); workGroup.shutdownGracefully(); } } public static void main(String[] args) { Server server = new Server(8090); server.start(); } } 

客户端

package io.netty.example.sticky; import io.netty.bootstrap.Bootstrap; import io.netty.channel.ChannelFuture; import io.netty.channel.ChannelOption; import io.netty.channel.EventLoopGroup; import io.netty.channel.nio.NioEventLoopGroup; import io.netty.channel.socket.nio.NioSocketChannel; /**
 * @author JavaEdge
 * @date 2021/2/8
 */
public class Client { private  int port; private  String address; public Client(int port, String address) { this.port = port; this.address = address; } public void start(){ EventLoopGroup group = new NioEventLoopGroup(); Bootstrap bootstrap = new Bootstrap(); bootstrap.group(group) .channel(NioSocketChannel.class) .option(ChannelOption.TCP_NODELAY, true) .handler(new ClientChannelInitializer()); try { ChannelFuture future = bootstrap.connect(address,port).sync(); future.channel().writeAndFlush("Hello world, i'm online"); future.channel().closeFuture().sync(); } catch (Exception e) { System.out.println("client start fail"); }finally { group.shutdownGracefully(); } } public static void main(String[] args) { Client client = new Client(8090,"127.0.0.1"); client.start(); } } 

粘包现象：

1 TCP为何会有粘包半包? 1.1 粘包

• 发送方每次写入数据 < 套接字缓冲区大小
• 接收方读取套接字缓冲区数据不够及时

1.2 半包

• 发送方写入数据 > 套接字缓冲区大小
• 发送的数据大于协议的MTU ( Maximum Transmission Unit,最大传输单元)，必须拆包

而且

• 一个发送可能被多次接收，多个发送可能被一次接收
• 一个发送可能占用多个传输包，多个发送可能公用一个传输包

本质是因为 TCP 是流式协议，消息无边界。

UDP就像快递，虽然一次运输多个，但每个包都有边界，一个个签收，所以无此类问题。

清楚了问题本质，就知道如何避免了，即确定消息边界。

2 解决方案 2.1 改为短连接

一个请求一个短连接。建立连接到释放连接之间的信息即为传输信息。 简单，但效率低下，不推荐。

2.2 封装成帧 2.2.1 固定长度

• 解码：FixedLengthFrameDecoder
• 满足固定长度即可。

简单，但空间浪费，不推荐。

2.2.2 分割符

• 解码：DelimiterBasedFrameDecoder，分隔符之间即为消息。

空间不浪费，也比较简单，但内容本身出现分隔符时需转义，所以需扫描内容。 推荐度低。

2.2.3 固定长度字段存个内容的长度信息

• 解码：LengthFieldBasedFrameDecoder
• 编码：LengthFieldPrepender 先解析固定长度的字段获取长度，然后读取后续内容。这就没有之前的缺点了

精确定位用户数据，内容也不用转义。 但长度理论上有限制，需提前预知可能的最大长度，从而定义长度占用字节数。 如果直接定义成最大长度，但实际上每次传输的又远没达到最大值，不就浪费空间啦，所以根据需要设置最大长度。

重点推荐使用。

其他方式比如 json 可看{}是否已经成对。但这种明显要扫描全部内容才知道是否成对。