Java随笔记 - 断包和粘包解决方法

红太狼 2022-12-28 06:12 141阅读 0赞

###  Java随笔记 - 断包和粘包 解决方法 ###

#### 断包和粘包 ####

*  断包和粘包是Socket编程中经常提及的一个问题，这里大致从概念角度进行讲解，后续博客应该会结合代码实例进行简单的实验对比。TCP协议是面向连接、面向流的，因此它并不知道它在传输的是什么具体内容。而且当我们在同一条连接上传输多笔数据的时候，TCP协议会根据数据包的大小，出于性能以及包大小限制的考虑，对数据包进行合并或者切分发送。也就是说，我们自定义的应用数据包，如果比较小，那么在同一个TCP数据包中就可能含有多个上述自定义的数据包；而如果我们的自定义数据包比较大，则需要进行切分，通过多个TCP完成发送。
 *  其实断包和拆包的情况不仅仅是TCP的原因，和缓冲区的使用也有关系。这里我们就不具体考虑进程缓冲区和内核缓冲区的区别了（详见[Java随笔记 - 内核缓冲区与进程缓冲区][Java_ -]），这里先把他们视为一个缓冲区来看。在数据传输的过程中，缓冲区可能已经缓冲了多笔数据，且这些数据可能是完整的，也可能是不完整的。因此，当进程每次从Socket读取数据时，其实是从缓冲区中读取了对端正在传输的或已经完成传输的多笔数据中的一部分。如下图所示：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pfX01heA_size_16_color_FFFFFF_t_70_pic_center]

*  如上图所示，缓冲区里是完整的应用数据包1和只有一半的应用数据包2。而TCP连接正在传输的是应用数据包2、3、4和5。一共会被切分成3个数据包，分别发送。
 *  进程第一次从Socket读取数据时，会读到应用数据包1和仅有一半的数据包2。从进程的角度来看，数据包2被断开了，也就是所谓的断包。而进程再次从Socket读取数据时，将会读到数据包2的后半部分、数据包3和4，以及数据包5的一小部分。其中数据包3和4都是完整的，且看似数据包4粘在了数据包3的后面，这就是所谓的粘包。如果我们的自定义数据包没有进行正确的封包，无法界定数据包之间的边界，就会出现将数据包4的内容当作数据包3处理的情况。
 *  而由于缓冲区的设置，进程从Socket读取数据时，实际是将数据从内核缓冲区复制到进程缓冲区中，所以即使我们禁止TCP使用Nagle算法进行数据包的合并发送，也不能完全消除粘包情况。

#### 解决方法 ####

*  断包和粘包问题都可以通过数据封包的方式解决，也就是给数据增加数据头或者数据尾标识，以明确界定每个数据包的开始和结束。比如，在待发送的每笔数据前加上一个整型数值（详见[Java随笔记 - BIO，Socket实例，实现多笔数据的传输][Java_ - BIO_Socket]）来标识该数据的总长度。也可以在数据包的尾部追加一个特殊标识，例如EOF。应用根据标识符，读取到一个完整的数据包后才进行相应的逻辑处理，反之则继续进行读取。
 *  以上图为例，进程在第一次从Socket读取数据时，发现数据包2的长度小于预期长度，就应该继续读取；而在第二次从Socket读取数据时，读取到数据包3后，读取的数据长度达到预期长度后就可以进行后续的处理了。

[Java_ -]: https://jiangnanmax.blog.csdn.net/article/details/110594525
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pfX01heA_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/d7b3f156ed1548dcb70ee91865e660aa.png
[Java_ - BIO_Socket]: https://jiangnanmax.blog.csdn.net/article/details/109781242