室内设计效果图qq群关键词优化靠谱推荐

粘包问题

粘包：指通信双方中的一端发送了多个数据包，但在另一端则被读取成了一个数据包，比如客户端发送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个字节后，再开始读取数据。