TCP粘包分析与处理

简介:

TCP粘包现象

TCP粘包通俗来讲,就是发送方发送的多个数据包,到接收方后粘连在一起,导致数据包不能完整的体现发送的数据。

TCP粘包原因分析

导致TCP粘包的原因,可能是发送方的原因,也有可能是接受方的原因。

发送方

由于TCP需要尽可能高效和可靠,所以TCP协议默认采用Nagle算法,以合并相连的小数据包,再一次性发送,以达到提升网络传输效率的目的。但是接收方并不知晓发送方合并数据包,而且数据包的合并在TCP协议中是没有分界线的,所以这就会导致接收方不能还原其本来的数据包。

接收方

TCP是基于“流”的。网络传输数据的速度可能会快过接收方处理数据的速度,这时候就会导致,接收方在读取缓冲区时,缓冲区存在多个数据包。在TCP协议中接收方是一次读取缓冲区中的所有内容,所以不能反映原本的数据信息。

解决TCP粘包

分析了产生TCP粘包的原因之后,针对发生的原因,针对性的采取解决方法。

禁用Negle算法

因为TCP协议采用Negle算法,导致粘包。所以可以禁用Nagle算法。

const char chOpt = 1;
int nErr = setsockopt(m_socket, IPPROTO_TCP, TCP_NODELAY, &chOpt, sizeof(char)); if(nErr == -1) { TRACE( "setsockopt() error\n", WSAGetLastError()); return ; }

这种方法虽然能一定程度上解决TCP粘包,但是并不能完全解决问题。因为接收方也是可能造成粘包的原因,这种方法只是发送方有效。而且禁用Nagle算法,一定程度上使TCP传输效率降低了。所以,这并不是一种理想的方法。

PUSH标志

PUSH是TCP报头中的一个标志位,发送方在发送数据的时候可以设置这个标志位。该标志通知接收方将接收到的数据全部提交给接收进程。这里所说的数据包括与此PUSH包一起传输的数据以及之前就为该进程传输过来的数据。
当Server端收到这些数据后,它需要立刻将这些数据提交给应用层进程,而不再等待是否还有额外的数据到达。
设置PUSH标志也不能完全解决TCP粘包,只是降低了接收方粘包的可能性。实际上现在的TCP协议栈基本上都可以自行处理这个问题,而不是交给应用层处理。所以设置PUSH标志,也不是一种理想的方法。

自定协议

自定协议,将数据包分为了封包和解包两个过程。在发送方发送数据时,对发送的数据进行封包操作。在接收方接收到数据时对接收的数据包需要进行解包操作。
自定协议时,封包就是为发送的数据增加包头,包头包含数据的大小的信息,数据就跟随在包头之后。当然包头也可以有其他的信息,比如一些做校验的信息。这里主要讨论TCP粘包的问题,所以不考虑其他的。

发送方封包

PACKAGE_HEAD pPackageHead; //PACKAGE_HEAD 包头结构体
char PackageHead[1024];
int headLen = sizeof(PACKAGE_HEAD); int packgeContextLen = strlen(packageContext); //packageContext 发送的数据 pPackageHead->nDataLen = packgeContextLen; //包的大小 char *packge = (char*)malloc(headLen + packgeContextLen); //包的内存分配 memset(packge, 0, headLen + packgeContextLen); char *packgeCpy = (char*)memcpy(packge, (char*)&pPackageHead, headLen);//拷贝包头 packgeCpy += headLen; packge = (char*)memcpy(packgeCpy, (char*)&packageContext, packgeContextLen);//拷贝包内容 int ret = 0; ret = send(m_hSocket, packge, headLen + packgeContextLen, 0); //发送包 if (ret == SOCKET_ERROR || ret == 0) { return ret; }

接收方解包

char PackageHead[1024];
char PackageContext[1024*20]; int len; PACKAGE_HEAD *pPackageHead; //PACKAGE_HEAD 包头结构体 while( m_bClose == false ) { memset(PackageHead, 0, sizeof(PACKAGE_HEAD)); len = ReceiveSize(m_TcpSock, (char*)PackageHead, sizeof(PACKAGE_HEAD)); //接收包头 if( len == SOCKET_ERROR ) { break; } if(len == 0) { break; } pPackageHead = (PACKAGE_HEAD *)PackageHead; memset(PackageContext,0,sizeof(PackageContext)); if(pPackageHead->nDataLen>0) //根据包头中的数据长度,接收数据 { len = ReceiveSize(m_TcpSock, (char*)PackageContext,pPackageHead->nDataLen); } }

接收指定长度的数据函数

//接收指定长度的数据
int ReceiveSize(SOCKET m_hSocket, char* strData, int gLen) { if(strData == NULL) return ERR_BADPARAM; char *p = strData; int len = gLen; int ret = 0; int returnlen = 0; while( len > 0) { ret = recv( m_hSocket, p+(iLen-len), iLen-returnlen, 0); if (ret == SOCKET_ERROR || ret == 0) { return ret; } len -= ret; returnlen += ret; } return returnlen; }

这样就可以达到解决TCP粘包的问题。在实际使用中包头还带有更多的信息,而且包尾可能还会带上分隔符,在redis、FTP中就是这样处理的。

UDP不存在粘包

由于UDP不是面向‘流’的,而且UDP是具有消息边界的。也就是说UDP的发送的每一个数据包都是独立的。所以UDP并不存在粘包的问题。

目录
相关文章
|
网络协议
ACK的累加规则-wireshark抓包分析-不包含tcp头部、ip头部、数据链路层头部等。
ACK的累加规则-wireshark抓包分析-不包含tcp头部、ip头部、数据链路层头部等。
ACK的累加规则-wireshark抓包分析-不包含tcp头部、ip头部、数据链路层头部等。
|
网络协议 算法 程序员
坦白局,TCP粘包:我只是犯了每个数据包都会犯的错
李东,自称亚健康终结者,尝试使用互联网+的模式拓展自己的业务。在某款新开发的聊天软件琛琛上发布广告。 键盘说来就来。疯狂发送"李东",回车发送!,"亚健康终结者",再回车发送!
|
移动开发 网络协议 Java
TCP 粘包/拆包问题
《基础系列》
128 0
TCP 粘包/拆包问题
|
网络协议 安全 测试技术
TCP 编程快速入门案例分析 | 学习笔记
快速学习 TCP 编程快速入门案例分析
129 0
TCP 编程快速入门案例分析 | 学习笔记
|
网络协议 图形学
Socket TCP协议解决粘包、半包问题的三种解决方案
Socket TCP协议解决粘包、半包问题的三种解决方案
233 1
Socket TCP协议解决粘包、半包问题的三种解决方案
|
移动开发 网络协议
TCP的粘包拆包问题+解决方案
TCP的粘包拆包问题+解决方案
124 0
TCP的粘包拆包问题+解决方案
|
Web App开发 网络协议 测试技术
技术分享 | 抓包分析 TCP 协议
tcpdump 是一款**将网络中传送的数据包的“头”完全截获下来提供分析**的工具。它支持针对网络层、协议、主机、网络或端口的过滤,并提供 and、or、not 等逻辑语句去掉无用的信息。
|
网络协议
TCP的粘包和拆包
TCP的粘包和拆包
140 0
|
移动开发 网络协议 IDE
Netty通信遇到了TCP拆包粘包问题?看这篇文章如何解决
在上一篇文章中主要是使用Springboot开发了一个Netty通信的基本案例,这篇文章是在上一篇文章的基础之上进行讲解的,主要是考虑传输数据如果遇到粘包问题该如何解决。 这篇文章会按照一下步骤进行讲解,希望对你有所收获: 1、什么是TCP粘包拆包 2、Netty中粘包问题的问题重现 3、Netty中粘包问题的解决方案 OK,在你心中有这么一个基本的脉络之后就可以开始今天的文章了。本系列所有的文章都会给出完整的代码,且在电脑上真实运行了一遍,确保无误。
227 0
Netty通信遇到了TCP拆包粘包问题?看这篇文章如何解决
|
监控 网络协议 NoSQL
不为人知的网络编程(十一):从底层入手,深度分析TCP连接耗时的秘密
TCP的开销到底有多大,能否进行量化。一条TCP连接的建立需要耗时延迟多少,是多少毫秒,还是多少微秒?能不能有一个哪怕是粗略的量化估计?
495 0
不为人知的网络编程(十一):从底层入手,深度分析TCP连接耗时的秘密