内容简介:因为自己造一个RPC框架的轮子时,需要解决TCP的粘包问题,特此记录,希望方便他人。这是我写的RPC框架的TCP粘包就是在TCP数据传输过程中,因为某些原因,接收方收到读取的数据并不是但存的一次数据,而是多个数据包的字节流组装在一起,导致多个数据粘在一起,接收端在读取的时候不知道怎么样把数据分成预期的多组数据,这就是粘包。TCP之所以造成粘包现象是因为其发送端和接收端的缓冲区及TCP数据流引起的。
因为自己造一个RPC框架的轮子时,需要解决TCP的粘包问题,特此记录,希望方便他人。这是我写的RPC框架的 GitHub地址 github.com/yangzhenkun… 欢迎star,fork。已经写了多篇文章对这个框架的原理进行说明。对原理有兴趣的欢迎交流。
1.什么是粘包
1.1 什么是TCP粘包
TCP粘包就是在TCP数据传输过程中,因为某些原因,接收方收到读取的数据并不是但存的一次数据,而是多个数据包的字节流组装在一起,导致多个数据粘在一起,接收端在读取的时候不知道怎么样把数据分成预期的多组数据,这就是粘包。
1.2 形成原因
TCP之所以造成粘包现象是因为其发送端和接收端的缓冲区及TCP数据流引起的。
例如nagle算法,会将瞬间的很多小包数据拼装称一个大的数据,以提高的带宽的利用率。(具体nagle算法就不展开将)。
但即使关闭了nagle算法,粘包依旧存在。因为这不是造成tcp粘包的根本原因。因为有缓冲区的存在,在缓存区没有打满之前是不会发送出去的,同时接收端也是利用缓存区接收数据,在接着从缓存区读取接收的数据解析。这时有人问,如果数据量很小,总是没有打满缓冲区那怎么办,这就依赖发送和接收端的定时器了,他们会定时的处理数据,要不这不就成了bug了。
就是因为缓冲区的存在以及tcp数据流的形式,造成了多组数据的拼接,形成了粘包,半 包问题。
1.3 如何解决
目前常用的方法是定义 起始 边届符+数据长度来告诉接收端一个数据包具体的长度。
不过也有定义固定长度的,不过这样可能会造成的空白字节的浪费以及超出长度这种不易扩展的方式。纯边界符的方式 怕发生实际消息体与边界符的碰撞,造成消息的误截断。
2.netty如何解决
netty对NIO模式的TCP通信的封装可谓是完美。可让人快速写出可用的tcp通信的服务端和客户端,并且很简单的解决粘包问题。
netty有提供基于分隔符和长度的编解码器,方便开发者使用。 DelimiterBaseFrameDecoder是可以用户自定义数据分隔符来分割的,LineBaseFrameDecoder是由行尾符(\n或者\r\n)分割,速度比前者还要块。 还有基于长度的FixedLengthFrameDecoder定长的解码器,LengthFieldBasedFrameDecoder动态长度的解码器。这4中方式都有对应的编解码器。
同时对于数据类型的边界吗,netty也支持byte,string,protobuf等,大家可以去看MessageToMessageDecoder的子类,就能发现netty提供很多编解码的规则。
3.实战-RPC框架的客户和服务端实现
在自己写KRPC时,一开始没有把NIO的计划提这么早,奈何在第一版用同步IO写客户端,压测时发现竟然那么不堪,遂决定用NIO改写,一开始觉得用Netty写客户端不方便(当时没到怎么写),便决定用 java 原生的NIO来写客户端,写到最后发现处理粘包特别困难,需要自己定义 特殊分界符号,然后设置长度,在客户端和服务端解析起来特别繁杂。于是尝试用netty写,发现特别简单。
bootstrap.group(bossGroup, workerGroup).channel(NioServerSocketChannel.class) .childHandler(new ChannelInitializer<SocketChannel>() { @Override protected void initChannel(SocketChannel ch) throws Exception { ChannelPipeline pipeline = ch.pipeline(); /** * 采用可变长度来解决粘包 * 前4位保存数据长度,所以一次调用最大支持的长度是65535个字节长度,同时把前4位长度过滤掉 */ pipeline.addLast("frameDecoder", new LengthFieldBasedFrameDecoder(Integer.MAX_VALUE, 0, 4, 0, 4)); /** * 计算数据长度,并放倒传输的数据中 */ pipeline.addLast("frameEncoder", new LengthFieldPrepender(4)); pipeline.addLast("decoder", new ByteArrayDecoder()); pipeline.addLast("encoder", new ByteArrayEncoder()); pipeline.addLast(new ServerHandler()); } }).option(ChannelOption.SO_BACKLOG, 128) .childOption(ChannelOption.SO_KEEPALIVE, true) .childOption(ChannelOption.RCVBUF_ALLOCATOR, new AdaptiveRecvByteBufAllocator(64,Global.getInstance().getMaxBuf(),Global.getInstance().getMaxBuf())); 复制代码
这就是服务端的代码,有没有特别简单,因为TCP将传输的数据序列化由压缩后的数据为 字节数组,所以使用的自带的ByteArray编解码器,使用了动态长度的LengthFieldBaseFrame来解决粘包问题。就这样解决了粘包问题。
如果想了解更具体的代码,可以去 github 下载,包含了krpc所有的代码。欢迎大家交流学习。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 隐私保护新突破:高斯差分隐私框架与深度学习结合
- 利用策略模式结合alibaba/alpha框架优化你的图片上传功能
- 天融信关于ThinkPHP5.1框架结合RCE漏洞的深入分析
- Google高性能序列化框架Protobuf认识及与Netty的结合
- The-Forge将开源的TressFX与Vulkan进一步结合,对其他框架进行改进
- 代理模式——结合SpringAOP讲解
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。