Socket粘包问题

2021-11-24 来自：CSDN 字体大小：【大 中 小】

•

摘要：这两天看csdn有一些关于socket粘包，socket缓冲区设置的问题，发现自己不是很清

楚，所以查资料了解记录一下 •

这两天看csdn有一些关于socket粘包，socket缓冲区设置的问题，发现自己不是很清楚，所以查资料了解记录一下： 一两个简单概念长连接与短连接： 1.长连接

Client方与Server方先建立通讯连接，连接建立后不断开， 然后再进行报文发送和接收。 2.短连接

Client方与Server每进行一次报文收发交易时才进行通讯连接，交易完毕后立即断开连接。此种方式常用于一点对多点 通讯，比方多个Client连接一个Server. 二 什么时候需要考虑粘包问题?

1:如果利用tcp每次发送数据，就与对方建立连接，然后双方发送完一段数据后，就关闭连接，这样就不会出现粘包问题〔因为只有一种包结构,类似于 协议〕。关闭连接主要要双方都发送close连接〔参考tcp关闭协议〕。如：A需要发送一段字符串给B，那么A与B建立连接，然后发送双方都默认好的协议字符如\"hello give me sth abour yourself\"，然后B收到报文后，就将缓冲区数据接收,然后关闭连接，这样粘包问题不用考虑到，因为大家都知道是发送一段字符。

2：如果发送数据无结构，如文件传输，这样发送方只管发送，接收方只管接收存储就ok，也不用考虑粘包

3：如果双方建立连接，需要在连接后一段时间内发送不同结构数据，如连接后，有好几种结构：

1)\"hello give me sth abour yourself\" 2)\"Don't give me sth abour yourself\"

那这样的话，如果发送方连续发送这个两个包出去，接收方一次接收可能会是\"hello give me sth abour yourselfDon't give me sth abour yourself\" 这样接收方就傻了，到底是要干嘛？不知道，因为协议没有规定这么诡异的字符串，所以要处理把它分包，怎么分也需要双方组织一个比拟好的包结构，所以一般可能会在头加一个数据长度之类的包，以确保接收。

三 粘包出现原因：在流传输中出现，UDP不会出现粘包，因为它有消息边界(参考Windows 网络编程)

1 发送端需要等缓冲区满才发送出去，造成粘包 2 接收方不及时接收缓冲区的包，造成多个包接收 解决方法：

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

以上提到的三种措施，都有其缺乏之处。第一种编程设置方法虽然可以防止发送方引起的粘包，但它关闭了优化算法，降低了网络发送效率，影响应用程序的性能，一般不建议使用。第二种方法只能减少出现粘包的可能性，但并不能完全防止粘包，当发送频率较高时，或由于网络突发可能使某个时间段数据包到达接收方较快，接收方还是有可能来不及接收，从而导致粘包。第三种方法虽然防止了粘包，但应用程序的效率较低，对实时应用的场合不适合。

相关文章截取：

一个包没有固定长度，以太网在46－1500字节，1500就是以太网的MTU，超过这个量，TCP会为IP数据报设置偏移量进行分片传输，现在一般可允许应用层设置8k〔NTFS系〕的缓冲区，8k的数据由底层分片，而应用看来只是一次发送。windows的缓冲区经验值是4k,Socket本身分为两种，流(TCP)和数据报(UDP)，你的问题针对这两种不同使用而结论不一 样。甚至还和你是用阻塞、还是非阻塞Socket来编程有关。

1、通信长度，这个是你自己决定的，没有系统强迫你要发多大的包，实际应该根据需求和网络状况来决定。对于TCP，这个长度可以大点，但要知道，Socket内部默认的收发缓冲区大小大概是8K，你可以用SetSockOpt来改变。但对于UDP，就不要太大，一般在1024至10K。注意一点，你无论发多大的包，IP层和链路层都会把你的包进行分片发送，一般局域网就是1500左右，广域网就只有几十字节。分片后的包将经过不同的路由到达接收方，对于UDP而言，要是其中一个分片丧失，那么接收方的IP层将把整个发送包丢弃，这就形成丢包。显然，要是一个UDP发包佷大，它被分片后，链路层丧失分片的几率就佷大，你这个UDP包，就佷容易丧失，但是太小又影响效率。最好可以配置这个值，以根据不同的环境来调整到最正确状态。

send()函数返回了实际发送的长度，在网络不断的情况下，它绝不会返回(发送失败的)错误，最多就是返回0。对于TCP你可以字节写一个循环发送。当send函数返回SOCKET_ERROR时，

才标志着有错误。但对于UDP，你不要写循环发送，否那么将给你的接收带来极大的麻烦。所以UDP需要用SetSockOpt来改变Socket内部Buffer的大小，以能容纳你的发包。明确一点，TCP作为流，发包是不会整包到达的，而是源源不断的到，那接收方就必须组包。而UDP作为消息或数据报，它一定是整包到达接收方。

2、关于接收，一般的发包都有包边界，首要的就是你这个包的长度要让接收方知道，于是就有个包头信息，对于TCP，接收方先收这个包头信息，然后再收包数据。一次收齐整个包也可以，可要对结果是否收齐进行验证。这也就完成了组包过程。UDP，那你只能整包接收了。要是你提供的接收Buffer过小，TCP将返回实际接收的长度，余下的还可以收，而UDP不同的是，余下的数据被丢弃并返回WSAEMSGSIZE错误。注意TCP，要是你提供的Buffer佷大，那么可能收到的就是多个发包，你必须别离它们，还有就是当Buffer太小，而一次收不完Socket内部的数据，那么Socket接收事件(OnReceive)，可能不会再触发，使用事件方式进行接收时，密切注意这点。这些特性就是表达了流和数据包的区别。

相关参考文章：

解决TCP网络传输“粘包〞问题

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

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

TCP是一个面向连接的传输层协议，虽然TCP不属于iso制定的协议集，但由于其在商业界和工业界的成功应用，它已成为事实上的网络标准，广泛应用于各种网络主机间的通信。 作为一个面向连接的传输层协议，TCP的目标是为用户提供可靠的端到端连接，保证信息有序无误的传输。它除了提供根本的数据传输功能外，还为保证可靠性采用了数据编号、校验和计算、数据确认等一系列措施。它对传送的每个数据字节都进行编号，并请求接收方回传确认信息〔ack〕。发送方如果在规定的时间内没有收到数据确认，就重传该数据。数据编号使接收方能够处理数据的失序和重复问题。数据误码问题通过在每个传输的数据段中增加校验和予以解决，接收方在接收到数据后检查校验和，假设校验和有误，那么丢弃该有

误码的数据段，并要求发送方重传。流量控制也是保证可靠性的一个重要措施，假设无流控，可能会因接收缓冲区溢出而丧失大量数据，导致许多重传，造成网络拥塞恶性循环。TCP采用可变窗口进行流量控制，由接收方控制发送方发送的数据量。

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

二、粘包问题分析与对策

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

出现粘包现象的原因是多方面的，它既可能由发送方造成，也可能由接收方造成。发送方引起的粘包是由TCP协议本身造成的，TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一包数据。假设连续几次发送的数据都很少，通常TCP会根据优化算法把这些数据合成一包后一次发送出去，这样接收方就收到了粘包数据。接收方引起的粘包是由于接收方用户进程不及时接收数据，从而导致粘包现象。这是因为接收方先把收到的数据放在系统接收缓冲区，用户进程从该缓冲区取数据，假设下一包数据到达时前一包数据尚未被用户进程取走，那么下一包数据放到系统接收缓冲区时就接到前一包数据之后，而用户进程根据预先设定的缓冲区大小从系统接收缓冲区取数据，这样就一次取到了多包数据〔图1所示〕。

图1

图2

图3

粘包情况有两种，一种是粘在一起的包都是完整的数据包〔图1、图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)假设n2)假设n=m，那么说明数据流内容恰好是一完整结构数据，直接将其存入临时缓冲区即可。

3)假设n>m，那么说明数据流内容尚不够构成一完整结构数据，需留待与下一包数据合并后再行处理。

对分包算法具体内容及软件实现有兴趣者，可与作者联系。 四、实验结果分析 实验结果如下：

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〕，几乎不影响应用程序的正常工作。

tmeteor