拼多多面试:Netty 如何解决粘包问题?
粘包和拆包问题也叫做粘包和半包问题,它是指在数据传输时,接收方未能正常读取到一条完整数据的情况(只读取了部分数据,或多读取到了另一条数据的情况)就叫做粘包或拆包问题。
从严格意义上来说,粘包问题和拆包问题属于两个不同的问题,接下来我们分别来看。
1.粘包问题
粘包问题是指在网络通信中,发送方连续发送的多个小数据包被接收方一次性接收的现象。这可能是因为底层传输层协议(如 TCP)会将多个小数据包合并成一个大的数据块进行传输,导致接收方在接收数据时一次性接收了多个数据包,造成粘连。
例如以下案例,正常情况下客户端发送了两条消息,分别为“ABC”和“DEF”,那么接收端也应该收到两条消息“ABC”和“DEF”才对,但是接收端却收到了“ABCD”这样的消息,这种情况就叫做粘包,如下图所示:
2.拆包/半包问题
拆包问题是指发送方发送的一个大数据包被接收方拆分成多个小数据包进行接收的现象。这可能是因为底层传输层协议(如 TCP)将一个大数据包拆分成多个小的数据块进行传输,导致接收方在接收数据时分别接收了多个小数据包,造成拆开。
例如以下案例,客户端发送了一条消息“ABC”,而接收端却收到了“AB”和“C”两条信息,这种情况就叫做半包,如下图所示:
PS:大部分情况下我们都把粘包问题和拆包问题看成同一个问题,所以下文就用粘包问题来替代粘包和拆包问题。
3.为什么会有粘包问题?
粘包问题通常发生在 TCP/IP 协议中,因为 TCP 是面向连接的传输协议,它是以“流”的形式传输数据的,而“流”数据是没有明确的开始和结尾边界的,所以就会出现粘包问题。
4.常见解决方案
粘包问题的常见解决方案有以下 3 种:
固定大小方法:发送方和接收方固定发送数据大小,当字符长度不够时用空字符弥补,有了固定大小之后就知道每条消息的具体边界了,这样就没有粘包的问题了。
自定义数据协议(定义数据长度):在 TCP 协议的基础上封装一层自定义数据协议,在自定义数据协议中,包含数据头(存储数据的大小)和 数据的具体内容,这样服务端得到数据之后,通过解析数据头就可以知道数据的具体长度了,也就没有粘包的问题了。
特殊分割符:以特殊的字符结尾,比如以“\n”结尾,这样我们就知道数据的具体边界了,从而避免了粘包问题。
以上三种方案中,第一种固定大小的方法可能会造成网络流量的浪费,以及传输性能慢的问题;第二种解决方案实现难度大,且不利于维护,所以比较推荐的是第三种方案,使用特殊分隔符来区分消息的边界,从而避免粘包问题。
5.Netty 解决方案
Netty 解决方案也延续了上面的常见解决方案,它的解决方案有以下几个:
使用定长解码器(FixedLengthFrameDecoder):每个数据包都拥有固定的长度,接收端根据固定长度对数据进行切分,从而解决了粘包问题。
使用行分隔符解码器(LineBasedFrameDecoder):以行为单位进行数据包的解码,从而解决粘包问题。
使用分隔符解码器(DelimiterBasedFrameDecoder):使用特定的分隔符来标识消息边界,这样接收端可以根据分隔符正确切分消息。
使用长度字段解码器(LengthFieldBasedFrameDecoder):在消息头部加入表示消息长度的字段,接收端根据长度字段来确定消息的边界,而从解决粘包问题。
PS:在 Netty 中,解码器(Decoder)起着非常重要的作用。解码器主要负责将从网络中接收到的原始字节流数据转换为应用程序能够理解的 Java 对象或消息格式。使用解码器可以解决粘包和拆包问题、协议转换问题、消息编码(如文本转换为字节流)等问题。
这些解码器的使用如下。
5.1 定长解码器
定长解码器(FixedLengthFrameDecoder)使用示例如下:
5.2 行分隔符解码器
行分隔符解码器(LineBasedFrameDecoder)使用示例如下:
5.3 分隔符解码器
分隔符解码器(DelimiterBasedFrameDecoder)使用示例如下:
5.4 长度字段解码器
长度字段解码器(LengthFieldBasedFrameDecoder)使用示例如下:
课后思考
除了定长解码器、行分隔符解码器、分隔符解码器、长度字段解码器之外,Netty 还有其他解决粘包问题的解决方案吗?如何自定义解码器?
本文已收录到我的面试小站 www.javacn.site,其中包含的内容有:Redis、JVM、并发、并发、MySQL、Spring、Spring MVC、Spring Boot、Spring Cloud、MyBatis、设计模式、消息队列等模块。
评论