netty如何解决TCP粘包问题

netty如何解决TCP粘包问题，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。因为自己造一个RPC框架的轮子时，需要解决TCP的粘包问题，特此记录，希望方便他人。这是我写的RPC框架的GitHub地址https://github.com/yangzhenkun/krpc。
欢迎star，fork。已经写了多篇文章对这个框架的原理进行说明。对原理有兴趣的欢迎交流。TCP粘包就是在TCP数据传输过程中，因为某些原因，接收方收到读取的数据并不是但存的一次数据，而是多个数据包的字节流组装在一起，导致多个数据粘在一起，接收端在读取的时候不知道怎么样把数据分成预期的多组数据，这就是粘包。TCP之所以造成粘包现象是因为其发送端和接收端的缓冲区及TCP数据流引起的。例如nagle算法，会将瞬间的很多小包数据拼装称一个大的数据，以提高的带宽的利用率。（具体nagle算法就不展开将）。但即使关闭了nagle算法，粘包依旧存在。因为这不是造成tcp粘包的根本原因。因为有缓冲区的存在，在缓存区没有打满之前是不会发送出去的，同时接收端也是利用缓存区接收数据，在接着从缓存区读取接收的数据解析。这时有人问，如果数据量很小，总是没有打满缓冲区那怎么办，这就依赖发送和接收端的定时器了，他们会定时的处理数据，要不这不就成了bug了。就是因为缓冲区的存在以及tcp数据流的形式，造成了多组数据的拼接，形成了粘包，半包问题。目前常用的方法是定义起始边届符+数据长度来告诉接收端一个数据包具体的长度。不过也有定义固定长度的，不过这样可能会造成的空白字节的浪费以及超出长度这种不易扩展的方式。纯边界符的方式怕发生实际消息体与边界符的碰撞，造成消息的误截断。netty对NIO模式的TCP通信的封装可谓是完美。可让人快速写出可用的tcp通信的服务端和客户端，并且很简单的解决粘包问题。netty有提供基于分隔符和长度的编解码器，方便开发者使用。
DelimiterBaseFrameDecoder是可以用户自定义数据分隔符来分割的，LineBaseFrameDecoder是由行尾符（n或者rn）分割，速度比前者还要块。
还有基于长度的FixedLengthFrameDecoder定长的解码器，LengthFieldBasedFr 香港云主机ameDecoder动态长度的解码器。这4中方式都有对应的编解码器。同时对于数据类型的边界吗，netty也支持byte，string，protobuf等，大家可以去看MessageToMessageDecoder的子类，就能发现netty提供很多编解码的规则。在自己写KRPC时，一开始没有把NIO的计划提这么早，奈何在第一版用同步IO写客户端，压测时发现竟然那么不堪，遂决定用NIO改写，一开始觉得用Netty写客户端不方便（当时没到怎么写），便决定用java原生的NIO来写客户端，写到最后发现处理粘包特别困难，需要自己定义特殊分界符号，然后设置长度，在客户端和服务端解析起来特别繁杂。于是尝试用netty写，发现特别简单。这就是服务端的代码，有没有特别简单，因为TCP将传输的数据序列化由压缩后的数据为字节数组，所以使用的自带的ByteArray编解码器，使用了动态长度的LengthFieldBaseFrame来解决粘包问题。就这样解决了粘包问题。关于netty如何解决TCP粘包问题问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注开发云行业资讯频道了解更多相关知识。

相关推荐: C++中如何使用make_unique构建unique_ptr

这篇文章将为大家详细讲解有关C++中如何使用make_unique构建unique_ptr，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。For convenience and consistency withs…