粘包半包以及Netty的解决办法
粘包问题
粘包:指通信双方中的一端发送了多个数据包,但在另一端则被读取成了一个数据包,比如客户端发送123、ABC
两个数据包,但服务端却收成的却是123ABC
这一个数据包。造成这个问题的主要是因为TPC
为了优化传输效率,将多个小包合并成一个大包发送,同时多个小包之间没有界限分割造成的。
沾包问题解决方案
①当使用TCP
短连接时,不必考虑沾包问题。
②当发送无结构数据,如文件传输时,也不需要考虑沾包问题,因为这类数据只管发送和接收保存即可。
③如果使用长连接,那么则需要考虑沾包问题:
- 固定长度的消息;
- 特殊字符作为边界;
- 自定义消息结构,一部分是头部,一部分是内容体;其中头部结构大小固定,且有一个字段声明内容体的大小。
半包问题
半包:指通信双方中的一端发送一个大的数据包,但在另一端被读取成了多个数据包,例如客户端向服务端发送了一个数据包:ABCDEFGXYZ
,而服务端则读取成了ABCEFG、XYZ
两个包,这两个包实际上都是一个数据包中的一部分,这个现象则被称之为半包问题(产生这种现象的原因在于:接收方的数据接收缓冲区过小导致的)。
粘包、半包问题的产生原因
粘包:发送12345、ABCDE
两个数据包,被接收成12345ABCDE
一个数据包,多个包粘在一起。
- 应用层:接收方的接收缓冲区太大,导致读取多个数据包一起输出。
TCP
滑动窗口:接收方窗口较大,导致发送方发出多个数据包,接收方处理不及时造成粘包。Nagle
算法:由于发送方的数据包体积过小,导致多个数据包合并成一个包发送。
半包:发送12345ABCDE
一个数据包,被接收成12345、ABCDE
两个数据包,一个包拆成多个。
- 应用层:接收方缓冲区太小,无法存方发送方的单个数据包,因此拆开读取。
- 滑动窗口:接收方的窗口太小,无法一次性放下完整数据包,只能读取其中一部分。
MSS
限制:发送方的数据包超过MSS
限制,被拆分为多个数据包发送。
netty中有哪几种解码器解决粘包的,你的项目怎么处理的?
有定长帧解码器、行帧解码器、分隔符帧解码器、LTC帧解码器。
定长帧解码器的确能够有效避免粘包、半包问题的出现,因为每个数据包之间,会以八个字节的长度作为界限,然后分割数据。但这种方式也存在三个致命缺陷:
- ①只适用于传输固定长度范围内的数据场景,而且客户端在发送数据前,还需自己根据长度补齐数据。
- ②如果发送的数据超出固定长度,服务端依旧会按固定长度分包,所以仍然会存在半包问题。
- ③对于未达到固定长度的数据,还需要额外传输补齐的
*
号字符,会占用不必要的网络资源。
相较于原本的定长解码器,行解码器、自定义分隔符解码器显然更加灵活,因为支持可变长度的数据,但这两种解码器,依旧存在些许缺点:
- ①对于每一个读取到的字节都需要判断一下:是否为结尾的分隔符,这会影响整体性能。
- ②依旧存在最大长度限制,当数据超出最大长度后,会自动将其分包,在数据传输量较大的情况下,依旧会导致半包现象出现。
项目用的LTC帧解码器
public class LengthFieldBasedFrameDecoder extends ByteToMessageDecoder {
public LengthFieldBasedFrameDecoder(
int maxFrameLength,
int lengthFieldOffset,
int lengthFieldLength,
int lengthAdjustment,
int initialBytesToStrip) {
this(maxFrameLength,
lengthFieldOffset,
lengthFieldLength,
lengthAdjustment,
initialBytesToStrip, true);
}
// 暂时省略其他参数的构造方法......
}
从上述构造器中可明显看出,LTC
中存在五个参数,看起来都比较长,接着简单解释一下:
maxFrameLength
:数据最大长度,允许单个数据包的最大长度,超出长度后会自动分包。lengthFieldOffset
:长度字段偏移量,表示描述数据长度的信息从第几个字段开始。lengthFieldLength
:长度字段的占位大小,表示数据中的使用了几个字节描述正文长度。lengthAdjustment
:长度调整数,表示在长度字段的N
个字节后才是正文数据的开始。initialBytesToStrip
:头部剥离字节数,表示先将数据去掉N
个字节后,再开始读取数据。