JAVA网络编程：解决TCP网络传输“粘包”问题

当前在网络传输应用中，普遍采用的是TCP/IP通讯协议及其标准的socket应用开发编程接口（API）。TCP/IP传输层有两个并列的协议：TCP和UDP。其中TCP（transport control protocol，传输控制协议）是面向链接的，提供高可靠性服务。UDP（user datagram protocol，用户数据报协议）是无链接的，提供高效率服务。在实际工程应用中，对可靠性和效率的选择取决于应用的环境和需求。通常状况下，普通数据的网络传输采用高效率的udp，重要数据的网络传输采用高可靠性的TCP。

在应用开发过程当中，笔者发现基于TCP网络传输的应用程序有时会出现粘包现象（即发送方发送的若干包数据到接收方接收时粘成一包）。针对这种状况，咱们进行了专题研究与实验。本文重点分析了TCP网络粘包问题，并结合实验结果提出了解决该问题的对策和方法，供有关工程技术人员参考。

1、TCP协议简介

TCP是一个面向链接的传输层协议，虽然TCP不属于iso制定的协议集，但因为其在商业界和工业界的成功应用，它已成为事实上的网络标准，普遍应用于各类网络主机间的通讯。

做为一个面向链接的传输层协议，TCP的目标是为用户提供可靠的端到端链接，保证信息有序无误的传输。它除了提供基本的数据传输功能外，还为保证可靠性采用了数据编号、校验和计算、数据确认等一系列措施。它对传送的每一个数据字节都进行编号，并请求接收方回传确认信息（ack）。发送方若是在规定的时间内没有收到数据确认，就重传该数据。数据编号使接收方可以处理数据的失序和重复问题。数据误码问题经过在每一个传输的数据段中增长校验和予以解决，接收方在接收到数据后检查校验和，若校验和有误，则丢弃该有误码的数据段，并要求发送方重传。流量控制也是保证可靠性的一个重要措施，若无流控，可能会因接收缓冲区溢出而丢失大量数据，致使许多重传，形成网络拥塞恶性循环。TCP采用可变窗口进行流量控制，由接收方控制发送方发送的数据量。

TCP为用户提供了高可靠性的网络传输服务，但可靠性保障措施也影响了传输效率。所以，在实际工程应用中，只有关键数据的传输才采用TCP，而普通数据的传输通常采用高效率的udp。

2、粘包问题分析与对策

TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。

出现粘包现象的缘由是多方面的，它既可能由发送方形成，也可能由接收方形成。发送方引发的粘包是由TCP协议自己形成的，TCP为提升传输效率，发送方每每要收集到足够多的数据后才发送一包数据。若连续几回发送的数据都不多，一般TCP会根据优化算法把这些数据合成一包后一次发送出去，这样接收方就收到了粘包数据。接收方引发的粘包是因为接收方用户进程不及时接收数据，从而致使粘包现象。这是由于接收方先把收到的数据放在系统接收缓冲区，用户进程从该缓冲区取数据，若下一包数据到达时前一包数据还没有被用户进程取走，则下一包数据放到系统接收缓冲区时就接到前一包数据以后，而用户进程根据预先设定的缓冲区大小从系统接收缓冲区取数据，这样就一次取到了多包数据（图1所示）。

图1


图2


图3

粘包状况有两种，一种是粘在一块儿的包都是完整的数据包（图一、图2所示），另外一种状况是粘在一块儿的包有不完整的包（图3所示），此处假设用户接收缓冲区长度为m个字节。

不是全部的粘包现象都须要处理，若传输的数据为不带结构的连续流数据（如文件传输），则没必要把粘连的包分开（简称分包）。但在实际工程应用中，传输的数据通常为带结构的数据，这时就须要作分包处理。

在处理定长结构数据的粘包问题时，分包算法比较简单；在处理不定长结构数据的粘包问题时，分包算法就比较复杂。特别是如图3所示的粘包状况，因为一包数据内容被分在了两个连续的接收包中，处理起来难度较大。实际工程应用中应尽可能避免出现粘包现象。

为了不粘包现象，可采起如下几种措施。一是对于发送方引发的粘包现象，用户可经过编程设置来避免，TCP提供了强制数据当即传送的操做指令push，TCP软件收到该操做指令后，就当即将本段数据发送出去，而没必要等待发送缓冲区满；二是对于接收方引发的粘包，则可经过优化程序设计、精简接收进程工做量、提升接收进程优先级等措施，使其及时接收数据，从而尽可能避免出现粘包现象；三是由接收方控制，将一包数据按结构字段，人为控制分屡次接收，而后合并，经过这种手段来避免粘包。

以上提到的三种措施，都有其不足之处。第一种编程设置方法虽然能够避免发送方引发的粘包，但它关闭了优化算法，下降了网络发送效率，影响应用程序的性能，通常不建议使用。第二种方法只能减小出现粘包的可能性，但并不能彻底避免粘包，当发送频率较高时，或因为网络突发可能使某个时间段数据包到达接收方较快，接收方仍是有可能来不及接收，从而致使粘包。第三种方法虽然避免了粘包，但应用程序的效率较低，对实时应用的场合不适合。

一种比较周全的对策是：接收方建立一预处理线程，对接收到的数据包进行预处理，将粘连的包分开。对这种方法咱们进行了实验，证实是高效可行的。

三、编程与实现

1．实现框架

实验网络通讯程序采用TCP/IP协议的socket api编程实现。socket是面向客户机/服务器模型的。TCP实现框架如图4所示。

图4

2．实验硬件环境：

服务器：pentium 350 微机

客户机：pentium 166微机

网络平台：由10兆共享式hub链接而成的局域网

3．实验软件环境：

操做系统：windows 98

编程语言：visual c++ 5.0

4．主要线程

编程采用多线程方式，服务器端共有两个线程：发送数据线程、发送统计显示线程。客户端共有三个线程：接收数据线程、接收预处理粘包线程、接收统计显示线程。其中，发送和接收线程优先级设为thread_priority_time_critical（最高优先级），预处理线程优先级为thread_priority_above_normal（高于普通优先级），显示线程优先级为thread_priority_normal（普通优先级）。

实验发送数据的数据结构如图5所示：

图5

5．分包算法

针对三种不一样的粘包现象，分包算法分别采起了相应的解决办法。其基本思路是首先将待处理的接收数据流（长度设为m）强行转换成预约的结构数据形式，并从中取出结构数据长度字段，即图5中的n，然后根据n计算获得第一包数据长度。

1)若n

2)若n=m，则代表数据流内容刚好是一完整结构数据，直接将其存入临时缓冲区便可。

3)若n>m，则代表数据流内容尚不够构成一完整结构数据，需留待与下一包数据合并后再行处理。

对分包算法具体内容及软件实现有兴趣者，可与做者联系。

4、实验结果分析

实验结果以下：

1．在上述实验环境下，当发送方连续发送的若干包数据长度之和小于1500b时，常会出现粘包现象，接收方经预处理线程处理后能正确解开粘在一块儿的包。若程序中设置了“发送不延迟”：（setsockopt (socket_name，ipproto_tcp，tcp_nodelay，(char *) &on，sizeof on) ，其中on=1），则不存在粘包现象。

2．当发送数据为每包1kb～2kb的不定长数据时，若发送间隔时间小于10ms，偶尔会出现粘包，接收方经预处理线程处理后能正确解开粘在一块儿的包。

3．为测定处理粘包的时间，发送方依次循环发送长度为1.5kb、1.9kb、1.2kb、1.6kb、1.0kb数据，共计1000包。为制造粘包现象，接收线程每次接收前都等待10ms，接收缓冲区设为5000b，结果接收方收到526包数据，其中长度为5000b的有175包。经预处理线程处理可获得1000包正确数据，粘包处理总时间小于1ms。

实验结果代表，TCP粘包现象确实存在，但可经过接收方的预处理予以解决，并且处理时间很是短（实验中1000包数据总共处理时间不到1ms），几乎不影响应用程序的正常工做。

 

推荐阅读：

  Socket粘包问题