CN102984253A - 一种传输控制协议粘包处理方法及装置 - Google Patents
一种传输控制协议粘包处理方法及装置 Download PDFInfo
- Publication number
- CN102984253A CN102984253A CN2012104914830A CN201210491483A CN102984253A CN 102984253 A CN102984253 A CN 102984253A CN 2012104914830 A CN2012104914830 A CN 2012104914830A CN 201210491483 A CN201210491483 A CN 201210491483A CN 102984253 A CN102984253 A CN 102984253A
- Authority
- CN
- China
- Prior art keywords
- length
- message
- data
- data flow
- tcp
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请提供一种传输控制协议TCP粘包处理方法及装置。一种TCP粘包处理方法包括:接收TCP消息,所述TCP消息包括消息头和消息体,所述消息体用于携带数据,所述消息头用于记录一条完整数据的数据长度;从所述TCP消息中获取消息头,并读取所述消息头记录的数据长度;根据所述数据长度从接收缓冲区中提取完整数据。因此接收端的接收缓冲区中出现粘包现象后,可以依据记录一条完整数据的数据长度从接收缓冲区中提取一个完整数据,解决了接收端不能从粘连的数据包中提取完整数据的问题。
Description
技术领域
本申请涉及通信领域。尤其涉及一种传输控制协议粘包处理方法及装置。
背景技术
传输控制协议(Transmission Control Protocol,TCP)是一个面向连接的传输层协议,现广泛应用于各种网络主机间的通信。虽然TCP为用户提供可靠的端到端连接,以保证TCP消息有序无误的传输。但是TCP消息以数据形式进行数据传输,因而TCP消息在传输过程中会出现若干包数据粘连即粘包现象。
造成粘包现象的原因有两种:一是发送端在发送缓冲区中数据填满后触发发送机制发送TCP消息,而在发送缓冲区填满数据的过程中造成粘包;二是接收端未及时从接收缓冲区提取数据造成粘包。
现有技术中对于接收端引起的粘包,可通过优化程序设计、精简接收进程工作量以及提高接收进程优先级等措施,使接收端及时接收数据包,从而尽量避免出现粘包现象,但是上述所有方法在发送端的发送频率较高或由于网络突发可能使到达接收端的数据包较快,接收端仍无法及时接收,从而导致粘包,进一步接收端不能提取一个TCP消息所携带的完整数据。
发明内容
为解决上述技术问题,本申请实施例提供一种传输控制协议粘包处理方法及装置,以达到在接收端的接收缓冲区中出现粘包现象后,依据记录一条完整数据的数据长度从接收缓冲区中提取一个完整数据的目的,技术方案如下:
一种传输控制协议TCP粘包处理方法,包括:
接收TCP消息,所述TCP消息包括消息头和消息体,所述消息体用于携带数据,所述消息头用于记录一条完整数据的数据长度;
从所述TCP消息中获取消息头,并读取所述消息头记录的数据长度;
根据所述数据长度从接收缓冲区中提取完整数据。
优选的,根据所述数据长度从接收缓冲区中提取完整数据包括:
在当前待处理数据流长度等于所述数据长度的情况下,根据所述数据长度从接收缓冲区中提取完整数据,返回执行接收TCP消息,以接收下一个TCP消息;
在当前待处理数据流长度大于所述数据长度的情况下,根据所述数据长度从接收缓冲区中提取完整数据,并且将提取完整数据后接收缓冲区中剩余的待处理数据流长度作为当前待处理数据流长度;
在该当前待处理数据流长度不小于预设消息头长度的情况下,执行从所述TCP消息中获取消息头,并读取消息头记录的数据长度,该TCP消息为接收缓冲区中当前待处理数据流所包括的TCP消息;
在该当前待处理数据流长度小于预设消息头长度的情况下,返回执行接收TCP消息,以接收下一个TCP消息。
优选的,还包括:在当前待处理数据流长度小于所述数据长度的情况下,则返回执行接收TCP消息,以接收下一个TCP消息。
优选的,在比较结果为当前待处理数据流长度小于所述数据长度时,接收到下一个TCP消息之后还包括:
将所述下一个TCP消息合并到所述接收缓冲区中当前待处理数据流中,并将接收缓冲区中合并后的待处理数据流长度为当前待处理数据流长度,执行比较所述数据长度和接收缓冲区中当前待处理数据流长度,其中,该下一个TCP消息为携带有上一个TCP消息未传完的剩余数据的TCP消息,该数据长度为上一个TCP消息的消息头记录的数据长度;
或者,将所述下一个TCP消息合并到所述接收缓冲区中当前待处理数据流中,并将接收缓冲区中合并后的待处理数据流长度为当前待处理数据流长度,执行比较所述数据长度和接收缓冲区中当前待处理数据流长度,其中,该下一个TCP消息包括消息头和消息体,该消息头用于记录该下一个TCP消息所对应的完整数据的数据长度,该消息体用于携带上一个TCP消息未传完的剩余数据和该下一个TCP消息对应的数据,该数据长度为上一个TCP 消息的消息头记录的数据长度。
优选的,所述消息头还用于记录消息编号,所述消息编号按照TCP客户端对TCP消息进行消息头添加处理的顺序获得;
比较所述数据长度和接收缓冲区中当前待处理数据流长度包括按照所述消息头编号依次比较所述数据消息长度和接收缓冲区中当前待处理数据流长度。
一种TCP粘包处理装置,包括:
接收单元,用于接收TCP消息,所述TCP消息包括消息头和消息体,所述消息体用于携带数据,所述消息头用于记录一条完整数据的数据长度;
获取单元,用于从接收单元接收的TCP消息中获取消息头,并读取所述消息头记录的数据长度;
提取单元,用于根据所述获取单元读取的消息头记录的数据长度从接收缓冲区中提取完整数据。
优选的,所述提取单元包括:
第一比较单元,用于比较所述数据长度和接收缓冲区中当前待处理数据流长度;
第二比较单元,用于比较当前待处理数据流长度和预设消息头长度;
第一提取单元,用于在第一比较单元的比较结果为当前待处理数据流长度等于所述数据长度,则根据所述数据长度从接收缓冲区中提取完整数据,并触发所述接收单元;
第二提取单元,用于在第一比较单元的比较结果为当前待处理数据流长度大于所述数据长度,则根据所述数据长度从接收缓冲区中提取完整数据,并将提取完整数据后接收缓冲区中剩余的待处理数据流长度作为当前待处理数据流长度,且触发所述第二比较单元;
第二比较单元的比较结果为当前待处理数据流长度不小于预设消息头长度,则触发获取单元,所述获取单元中的TCP消息为接收缓冲区中当前待处理数据流所包括的TCP消息;
第二比较单元的比较结果为当前待处理数据流长度小于预设消息头长 度,触发接收单元;
第二触发单元,用于在第二比较单元的比较结果为当前待处理数据流长度小于预设消息头长度,触发所述接收单元。
优选的,还包括:
第一触发单元用于在第一比较单元的比较结果为当前待处理数据流长度小于所述数据长度,触发所述接收单元。
优选的,还包括:
合并单元,用于在比较结果为当前待处理数据流长度小于所述数据长度时,接收到下一个TCP消息后,将所述下一个TCP消息合并到所述接收缓冲区中当前待处理数据流中,并接收缓冲区中合并后的待处理数据流长度为当前待处理数据流长度,触发所述第一比较单元,其中,该下一个TCP消息为携带有上一个TCP消息未传完的剩余数据的TCP消息,该数据长度为上一个TCP消息的消息头记录的数据长度;
或者,合并单元,用于在比较结果为当前待处理数据流长度小于所述数据长度时,接收到下一个TCP消息后,将所述下一个TCP消息合并到所述接收缓冲区中当前待处理数据流中,并将接收缓冲区中合并后的待处理数据流长度为当前待处理数据流长度,触发所述第一比较单元,其中,该下一个TCP消息包括消息头和消息体,该消息头用于记录该下一个TCP消息所对应的完整数据的数据长度,该消息体用于携带上一个TCP消息未传完的剩余数据和该下一个TCP消息对应的数据;该数据长度为上一个TCP消息的消息头记录的数据长度。
优选的,所述接收单元接收的TCP消息包括的消息头还用于记录消息编号,所述消息头编号按照TCP客户端对TCP消息进行消息头添加处理的顺序获得;
所述第一比较单元具体用于按照所述消息头编号依次比较所述数据消息长度和接收缓冲区中当前待处理数据流长度。
与现有技术相比,本申请的有益效果是:
本申请的技术方案中,在接收到TCP消息后,可以从TCP消息中获取 消息头,并读取出消息头中用于记录一条完整数据的数据长度,进而依据数据长度从接收缓冲区中提取完整数据。因此接收端的接收缓冲区中出现粘包现象后,可以依据记录一条完整数据的数据长度从接收缓冲区中提取一个完整数据,解决了接收端不能从粘连的数据包中提取完整数据的问题。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请中记载的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本申请的一种传输控制协议粘包处理方法的一种流程图;
图2是本申请的一种传输控制协议粘包处理方法的另一种流程图;
图3是本申请的一种传输控制协议粘包处理方法的再一种流程图;
图4是本申请的一种传输控制协议粘包处理装置的一种结构图;
图5是本申请的一种传输控制协议粘包处理装置的另一种结构图;
图6是本申请的一种传输控制协议粘包处理装置的再一种结构图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
本申请提供的一种传输控制协议粘包处理方法可以首先接收TCP消息,所述TCP消息包括消息头和消息体,所述消息体用于携带数据,所述消息头用于记录一个TCP消息所对应的完整数据的数据长度,其次,从所述TCP消息中获取消息头,并读取所述消息头记录的数据长度,所述原始TCP消息长度用于记录TCP消息中所携带的数据长度,然后根据所述数据长度从接收缓冲区中提取完整数据。以下将列举实施例对本申请提供的一种传输控制协议粘包处理方法进行详细说明。
一个实施例
请参阅图1,其示出了本申请提供的一种传输控制协议粘包处理方法的一种流程图,可以包括以下步骤:
S11:接收TCP消息,所述TCP消息包括消息头和消息体,所述消息体用于携带数据,所述消息头用于一条完整数据的数据长度。
在本实施例中,接收端在接收到TCP消息后将该TCP消息存入接收缓冲区中。接收端接收发送端发送的TCP消息可以为发送端对一条数据进行消息头添加处理后的TCP消息。其中该TCP消息包括消息头和消息体,消息体用于携带数据,所述消息头用于记录所述一条完整数据的数据长度。该TCP消息可能包含一条完整数据,也可能包含多条完整数据,也可能包含一条不完整数据。
其中,所述完整数据为有完整结构的数据,例如,一种有完整结构的数据为“I am a scientist”,如果该完整数据和后面数据发生粘连,粘连后的数据如果为“I am a scientist I”,则粘连后的数据就为不完整数据。
S12:从所述TCP消息中获取消息头,并读取所述消息头记录的数据长度。
其中,数据长度用于记录一条完整数据的长度。当接收端需要从接收缓冲区中提取完整数据时,则首先需要从消息头中读取该数据长度。
S13:根据所述数据长度从接收缓冲区中提取完整数据。
由于数据长度可以记录一条完整数据的长度,所以接收端可以直接依据该数据长度从接收缓冲区中提取长度等于数据长度的完整数据。因此在接收端的接收缓冲区中出现粘包现象后,可以依据记录一条完整数据的数据长度从接收缓冲区中提取一个完整数据,解决了接收端不能从粘连的数据包中提取完整数据的问题。
进一步,接收端可以从粘连的数据包中提取完整数据,因此发送端可以连续发送TCP消息,即发送端不需要每次等待接收端提取完整数据后再发送新的TCP消息,提高发送效率。
另一个实施例
在本实施例中,根据数据长度从接收缓冲区中提取完整数据可以依据数据长度和接收缓冲区中当前待处理数据流长度的比较结果提取,其具体过程请参阅图2。其中图2为本申请提供的一种传输控制协议粘包处理方法的另一种流程图,其示出了提取完整数据的具体过程,可以包括以下步骤:
步骤S21和步骤S22分别与图1所示的一种传输控制协议粘包处理方法中的步骤S11和步骤S12相同,在此不再赘述。
步骤S23:比较所述消息头记录的数据长度和接收缓冲区中当前待处理数据流长度。
其中当前待处理数据流长度为接收缓冲区中当前缓存的数据流的长度,接收缓冲区中当前缓存的数据流为接收的TCP消息。
在本实施例中,数据长度和接收缓冲区中当前待处理数据流长度的比较结果有三种,分别是当前待处理数据流长度等于所述数据长度、当前待处理数据流长度大于所述数据长度以及当前待处理数据流长度小于所述数据长度。在比较结果不同时,接收端的具体操作以不同,下面会从对每个比较结果进行说明。
S24:在比较结果为当前待处理数据流长度等于所述数据长度时,根据所述数据长度从接收缓冲区中提取完整数据。
其中,比较结果为当前待处理数据流长度等于所述数据长度,说明当前待处理数据流包括一个消息头和一个消息体,该消息体携带的数据为一条完整数据。在本实施例中,根据所述数据长度从接收缓冲区中提取完整数据后返回执行步骤S21,以接收下一个TCP消息。
步骤S25:在比较结果为当前待处理数据流长度大于所述数据长度时,根据所述数据长度从接收缓冲区中提取完整数据,继续比较当前待处理数据流长度和预设消息头长度。
其中,比较结果为当前待处理数据流长度大于所述数据长度时,说明当前待处理数据流包括多个消息头和消息体,其中每个消息头后邻该消息头对应的消息体,且前邻不同于该消息体的消息体。步骤S 12读取的所述消息头 为接收缓冲区中当前待处理数据流中当前排列在首个位置的消息头。
在本实施例中,根据所述数据长度从接收缓冲区中提取完整数据之后,将提取完整数据后接收缓冲区中剩余的待处理数据流长度作为当前待处理数据流长度,然后执行步骤S26比较当前待处理数据流长度和预设消息头长度。
步骤S26:比较当前待处理数据流长度和预设消息头长度。
其中,所述预设消息头长度对于发送端和接收端是已知并且一致的,发送端依据预设消息头长度对每条数据添加的消息头长度相同且固定。当然,预设消息头长度也可以改变,但是在一种传输控制协议中消息头长度固定不变。在本步骤中当前待处理数据流长度为步骤S25提取完整数据后接收缓冲区中剩余的待处理数据流长度。
在本实施例中,当前待处理数据流长度和预设消息头长度的比较结果分别为:当前待处理数据流长度不小于预设消息头长度、当前待处理数据流长度小于预设消息头长度。在比较结果不同时,接收端的具体操作以不同,下面会从对每个比较结果进行说明。
步骤S27:在比较结果为当前待处理数据流不小于预设消息头长度时,执行步骤S22从所述TCP消息中获取消息头,并读取消息头记录的数据长度。
在本实施例中,在比较结果为当前待处理数据流不小于预设消息头长度,从TCP消息中获取消息头时,获取消息头的TCP消息为接收缓冲区中当前待处理数据流,执行步骤S22从所述TCP消息中获取消息头,并读取消息头记录的数据长度之后,继续执行步骤S23比较所述消息头记录的数据长度和接收缓冲区中当前待处理数据流长度。
步骤S28:在比较结果为当前待处理数据流长度小于预设消息头长度时,返回执行步骤S21接收TCP消息,以接收下一个TCP消息。
在本实施例中,比较结果为当前待处理数据流长度小于预设消息头长度,说明当前待处理数据流并不是一条完整数据,而且不是一个完整的消息头,此时执行步骤S21接收TCP消息,以接收下一个TCP消息。 步骤S29:在比较结果为当前待处理数据流长度小于所述数据长度则执行步骤S11接收TCP消息,以接收下一个TCP消息。
其中,比较结果为当前待处理数据流长度小于所述数据长度时,说明当前待处理数据流包括一个消息头和一个消息体,且该消息体携带的数据为一条不完整数据。因此在比较结果为当前待处理数据流长度小于所述消息头长度时,需要等待接收下一个TCP消息,以接收到完整数据,进而接收端可以提取完整数据。
S210:将所述下一个TCP消息合并到所述接收缓冲区中当前待处理数据流中。
在本实施例中,该下一个TCP消息可能包括两种内容,一种内容为上一个TCP消息未传完的剩余数据;一种内容为消息头和消息体,该消息头用于记录该下一个TCP消息所对应的完整数据的数据长度,该消息体用于携带上一个TCP消息未传完的剩余数据和该下一个TCP消息对应的数据。合并后的数据为接收缓冲区中当前待处理数据流,然后继续执行步骤S23比较所述数据长度和接收缓冲区中当前待处理数据流长度,该数据长度为上一个TCP消息的消息头记录的数据长度。
下面以“I am a scientist”这样一个完整数据作为具体实例对下一个TCP消息的两种情况进行说明。
例如,接收端接收到的上一个TCP消息中消息头携带的数据为“I am”,则接收缓冲区当前的待处理数据流为“I am”,可见当前待处理数据流为结构不完整的数据,完整数据中的剩余数据“a scientist”未传完,则发送端将“ascientist”携带于下一个TCP消息中发送给接收端,接收端所接收到的下一个TCP消息的消息头中携带未传完的剩余数据“a scientist”,接收到“a scientist”之后与所述接收缓冲区中已缓存的待处理数据流合并,合并后的数据流为当前待处理数据流。
当然,发送端在将“a scientist”携带于下一个TCP消息中发送给接收端的同时,还可以在下一个TCP消息中封装另一个完整数据如“you are a teacher”至消息体中,并将该完整数据的数据长度记录在下一个TCP消息的消息头 中。
本实施例阐述了依据数据长度和接收缓冲区中当前待处理数据流长度的比较结果提取完整数据的具体过程,当然,提取完整数据还可以有其他方式,对此本实施例不再加以阐述。
另一个实施例
请参阅图3,其示出了本申请的一种传输控制协议粘包处理方法的再一种流程图,其与图1所示的TCP粘包处理方法不同之处在于:
消息头还用于记录消息编号,所述消息头编号按照TCP客户端对TCP消息进行消息头添加处理的顺序获得,且将消息体一并存入接收缓冲区中。并且图3所示的TCP粘包处理方法在提取完整数据时可以参照图2所示的具体实现过程,但不同之处在于获取消息头时按照消息编号依次获取,并按照消息编号依次比较所述数据长度和接收缓冲区中当前待处理数据流长度。
与上述实施例相对应,本申请还提供了的一种传输控制协议粘包处理装置的一种结构图,请参阅图4,传输控制协议粘包处理装置包括:接收单元41,获取单元42,提取单元43。
其中,接收单元41用于接收TCP消息,所述TCP消息包括消息头和消息体,所述消息体用于携带数据,所述消息头用于记录一条完整数据的数据长度;
在本实施例中,接收单元41在接收到TCP消息后将该TCP消息存入接收缓冲区中。接收端接收发送端发送的TCP消息可以为发送端对一条数据进行消息头添加处理后的TCP消息。其中该TCP消息包括消息头和消息体,消息体用于携带数据,所述消息头用于记录所述一条完整数据的数据长度。
获取单元42,用于从接收单元41接收的TCP消息中获取消息头,并读取所述消息头记录的数据长度;
其中,获取单元读取的数据长度用于记录一条完整数据的长度。当接收端提取单元43从接收缓冲区中提取完整数据时,则首先需要从获取单元42获取的消息头中读取该数据长度。
提取单元43,用于根据所述获取单元42读取的消息头记录的数据长度从接收缓冲区中提取完整数据。
由于获取单元42读取的数据长度可以记录一条完整数据的长度,所以接收端提取单元43可以直接依据该数据长度从接收缓冲区中提取长度等于数据长度的完整数据。因此在接收端的接收缓冲区中出现粘包现象后,提取单元43可以依据获取单元42读取的记录一条完整数据的数据长度从接收缓冲区中提取一个完整数据。
请参阅图5,其示出了本申请的一种传输控制协议粘包处理装置的另一种结构图,其中,提取单元53具体可以包括第一比较单元531、第一提取单元532、第二提取单元533、第二比较单元534和第二触发单元535。其中,
接收单元51和获取单元52与图4所示的一种传输控制协议粘包处理装置中的接收单元41和获取单元42相同,在此不再赘述。
第一比较单元531,用于比较所述数据长度和接收缓冲区中当前待处理数据流长度。其中当前待处理数据流长度为接收缓冲区中当前缓存的数据流的长度,接收缓冲区中当前缓存的数据流为接收的TCP消息。
在比较结果为当前待处理数据流长度等于所述数据长度时,根据所述数据长度从接收缓冲区中提取完整数据。
其中,比较结果为当前待处理数据流长度等于所述数据长度,说明当前待处理数据流包括一个消息头和一个消息体,该消息体携带的数据为一条完整数据。在本实施例中,根据所述数据长度从接收缓冲区中提取完整数据后触发接收单元51。
在比较结果为当前待处理数据流长度大于所述数据长度时,第二提取单元533根据所述数据长度从接收缓冲区中提取完整数据,第二比较单元534继续比较当前待处理数据流长度和预设消息头长度。
其中,比较结果为当前待处理数据流长度大于所述数据长度时,说明当前待处理数据流包括多个消息头和消息体,其中每个消息头后邻该消息头对应的消息体,且前邻不同于该消息体的消息体。获取单元52读取的所述消 息头为接收缓冲区中当前待处理数据流中当前排列在首个位置的消息头。
在本实施例中,,第二提取单元533根据所述数据长度从接收缓冲区中提取完整数据之后,将提取完整数据后接收缓冲区中剩余的待处理数据流长度作为当前待处理数据流长度,然后触发第二比较单元534。
在比较结果为当前待处理数据流长度小于所述数据长度则触发接收单元51。
其中,比较结果为当前待处理数据流长度小于所述数据长度时,说明当前待处理数据流包括一个消息头和一个消息体,且该消息体携带的数据为一条不完整数据。
第一提取单元532,用于在第一比较单元531的比较结果为当前待处理数据流长度等于所述数据长度,则根据所述数据长度从接收缓冲区中提取完整数据,并触发所述接收单元51。
第二提取单元533,用于在第一比较单元531的比较结果为当前待处理数据流长度大于所述数据长度,则根据所述数据长度从接收缓冲区中提取完整数据,并将提取完整数据后接收缓冲区中剩余的待处理数据流长度作为当前待处理数据流长度,且触发所述第二比较单元534。
第二比较单元534,用于比较当前待处理数据流长度和预设消息头长度。
其中,所述预设消息头长度对于发送端和接收端是已知并且一致的,发送端依据预设消息头长度对每条数据添加的消息头长度相同且固定。当然,预设消息头长度也可以改变,但是在一种传输控制协议中消息头长度固定不变。在本单元中当前待处理数据流长度为第二提取单元533提取完整数据后接收缓冲区中剩余的待处理数据流长度。
在比较结果为当前待处理数据流不小于预设消息头长度时,触发获取单元52。
在本实施例中,在比较结果为当前待处理数据流不小于预设消息头长度,获取单元52从TCP消息中获取消息头时,获取消息头的TCP消息为接收缓冲区中当前待处理数据流.
在比较结果为当前待处理数据流长度小于预设消息头长度时,触发接收 单元51。
在本实施例中,比较结果为当前待处理数据流长度小于预设消息头长度,说明当前待处理数据流并不是一条完整数据,而且不是一个完整的消息头。
第二触发单元535,用于在第二比较单元534的比较结果为当前待处理数据流长度小于预设消息头长度,触发所述接收单元51。
请参阅图6,其示出了本申请的一种传输控制协议粘包处理装置的再一种结构图,在图5基础上还包括:第一触发单元61和合并单元62。
第一触发单元61,用于在第一比较单元531的比较结果为当前待处理数据流长度小于所述数据长度,触发所述接收单元51。
合并单元62,用于在比较结果为当前待处理数据流长度小于所述数据长度时,接收到下一个TCP消息后,将所述下一个TCP消息合并到所述接收缓冲区中当前待处理数据流中,并接收缓冲区中合并后的待处理数据流长度为当前待处理数据流长度,触发所述第一比较单元531。
在本实施例中,该该下一个TCP消息可能包括两种内容,一种内容为上一个TCP消息未传完的剩余数据;一种内容为消息头和消息体,该消息头用于记录该下一个TCP消息所对应的完整数据的数据长度,该消息体用于携带上一个TCP消息未传完的剩余数据和该下一个TCP消息对应的数据。合并后的数据为接收缓冲区中当前待处理数据流,然后触发第一比较单元531比较所述数据长度和接收缓冲区中当前待处理数据流长度,该数据长度为上一个TCP消息的消息头记录的数据长度。
接收单元51在接收到TCP消息后,将接收到的TCP消息存入接收缓冲区中,获取单元52则从接收缓冲区中获取接收到的TCP消息的消息头,并读取消息头记录的数据长度,然后第一比较单元531比较获取单元52读取的数据长度和接收缓冲区中当前待处理数据流长度,在第一比较单元531比较结果为为当前待处理数据流长度等于所述数据长度时,触发第一提取单元532,在比较结果为为当前待处理数据流长度大于所述数据长度时,触发第二提取单元533,第二提取单元533被触发后根据所述数据长度从接收缓冲 区中提取完整数据,并将提取完整数据后接收缓冲区中剩余的待处理数据流长度作为当前待处理数据流长度,且触发第二比较单元534,第二比较单元534被触发后,比较当前待处理数据流长度和预设消息头长度,在第二比较单元比534较结果为当前待处理数据流长度不小于预设消息头长度,则触发获取单元,在第二比较单元534比较结果为当前待处理数据流长度小于预设消息头长度,触发接收单元,在第一比较单元531比较结果为为当前待处理数据流长度小于所述数据长度时,触发接收单元51,然后合并单元62将接收单元接收到的新TCP消息合并到所述当前待处理数据流中,并将接收缓冲区中合并后的待处理数据流长度为当前待处理数据流长度,触发所述第一比较单元531。
另外,图4至图6所示的一种传输控制协议粘包处理装置中的接收单元接收的TCP消息包括的消息头还用于记录消息编号,所述消息头编号按照TCP客户端对TCP消息进行消息头添加处理的顺序获得,且将消息体一并存入接收缓冲区中。并且图4至图6所示的TCP粘包处理装置包括的提取单元获取消息头时还可以按照消息编号依次获取,并按照消息编号依次比较所述数据长度和接收缓冲区中当前待处理数据流长度。
需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说是显而易见的,本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下,在其它实施例中实现。因此,本发明将不会被限制于本文所示的这些实施例,而是要符合与本文所公开的原理和新颖特点相一致的最宽范围。
Claims (10)
1.一种传输控制协议TCP粘包处理方法,其特征在于,包括:
接收TCP消息,所述TCP消息包括消息头和消息体,所述消息体用于携带数据,所述消息头用于记录一条完整数据的数据长度;
从所述TCP消息中获取消息头,并读取所述消息头记录的数据长度;
根据所述数据长度从接收缓冲区中提取完整数据。
2.根据权利要求1所述的方法,其特征在于,根据所述数据长度从接收缓冲区中提取完整数据包括:
在当前待处理数据流长度等于所述数据长度的情况下,根据所述数据长度从接收缓冲区中提取完整数据,返回执行接收TCP消息,以接收下一个TCP消息;
在当前待处理数据流长度大于所述数据长度的情况下,根据所述数据长度从接收缓冲区中提取完整数据,并且将提取完整数据后接收缓冲区中剩余的待处理数据流长度作为当前待处理数据流长度;
在该当前待处理数据流长度不小于预设消息头长度的情况下,执行从所述TCP消息中获取消息头,并读取消息头记录的数据长度,该TCP消息为接收缓冲区中当前待处理数据流所包括的TCP消息;
在该当前待处理数据流长度小于预设消息头长度的情况下,返回执行接收TCP消息,以接收下一个TCP消息。
3.根据权利要求2所述的方法,其特征在于,还包括:在当前待处理数据流长度小于所述数据长度的情况下,则返回执行接收TCP消息,以接收下一个TCP消息。
4.根据权利要求3所述的方法,其特征在于,在比较结果为当前待处理数据流长度小于所述数据长度时,接收到下一个TCP消息之后还包括:
将所述下一个TCP消息合并到所述接收缓冲区中当前待处理数据流中,并将接收缓冲区中合并后的待处理数据流长度为当前待处理数据流长度,执行比较所述数据长度和接收缓冲区中当前待处理数据流长度,其中,该下一个TCP消息为携带有上一个TCP消息未传完的剩余数据的TCP消息,该数据长度为上一个TCP消息的消息头记录的数据长度;
或者,将所述下一个TCP消息合并到所述接收缓冲区中当前待处理数据流中,并将接收缓冲区中合并后的待处理数据流长度为当前待处理数据流长度,执行比较所述数据长度和接收缓冲区中当前待处理数据流长度,其中,该下一个TCP消息包括消息头和消息体,该消息头用于记录该下一个TCP消息所对应的完整数据的数据长度,该消息体用于携带上一个TCP消息未传完的剩余数据和该下一个TCP消息对应的数据,该数据长度为上一个TCP消息的消息头记录的数据长度。
5.根据权利要求2所述的方法,其特征在于,所述消息头还用于记录消息编号,所述消息编号按照TCP客户端对TCP消息进行消息头添加处理的顺序获得;
比较所述数据长度和接收缓冲区中当前待处理数据流长度包括按照所述消息头编号依次比较所述数据消息长度和接收缓冲区中当前待处理数据流长度。
6.一种TCP粘包处理装置,其特征在于,包括:
接收单元,用于接收TCP消息,所述TCP消息包括消息头和消息体,所述消息体用于携带数据,所述消息头用于记录一条完整数据的数据长度;
获取单元,用于从接收单元接收的TCP消息中获取消息头,并读取所述消息头记录的数据长度;
提取单元,用于根据所述获取单元读取的消息头记录的数据长度从接收缓冲区中提取完整数据。
7.根据权利要求6所述的装置,其特征在于,所述提取单元包括:
第一比较单元,用于比较所述数据长度和接收缓冲区中当前待处理数据流长度;
第二比较单元,用于比较当前待处理数据流长度和预设消息头长度;
第一提取单元,用于在第一比较单元的比较结果为当前待处理数据流长度等于所述数据长度,则根据所述数据长度从接收缓冲区中提取完整数据,并触发所述接收单元;
第二提取单元,用于在第一比较单元的比较结果为当前待处理数据流长度大于所述数据长度,则根据所述数据长度从接收缓冲区中提取完整数据,并将提取完整数据后接收缓冲区中剩余的待处理数据流长度作为当前待处理数据流长度,且触发所述第二比较单元;
第二比较单元的比较结果为当前待处理数据流长度不小于预设消息头长度,则触发获取单元,所述获取单元中的TCP消息为接收缓冲区中当前待处理数据流所包括的TCP消息;
第二比较单元的比较结果为当前待处理数据流长度小于预设消息头长度,触发接收单元;
第二触发单元,用于在第二比较单元的比较结果为当前待处理数据流长度小于预设消息头长度,触发所述接收单元。
8.根据权利要求7所述的装置,其特征在于,还包括:
第一触发单元用于在第一比较单元的比较结果为当前待处理数据流长度小于所述数据长度,触发所述接收单元。
9.根据权利要求8所述的装置,其特征在于,还包括:
合并单元,用于在比较结果为当前待处理数据流长度小于所述数据长度时,接收到下一个TCP消息后,将所述下一个TCP消息合并到所述接收缓冲区中当前待处理数据流中,并接收缓冲区中合并后的待处理数据流长度为当前待处理数据流长度,触发所述第一比较单元,其中,该下一个TCP消息为携带有上一个TCP消息未传完的剩余数据的TCP消息,该数据长度为上一个TCP消息的消息头记录的数据长度;
或者,合并单元,用于在比较结果为当前待处理数据流长度小于所述数据长度时,接收到下一个TCP消息后,将所述下一个TCP消息合并到所述接收缓冲区中当前待处理数据流中,并将接收缓冲区中合并后的待处理数据流长度为当前待处理数据流长度,触发所述第一比较单元,其中,该下一个TCP消息包括消息头和消息体,该消息头用于记录该下一个TCP消息所对应的完整数据的数据长度,该消息体用于携带上一个TCP消息未传完的剩余数据和该下一个TCP消息对应的数据;该数据长度为上一个TCP消息的消息头记录的数据长度。
10.根据权利要求7所述的装置,其特征在于,所述接收单元接收的TCP消息包括的消息头还用于记录消息编号,所述消息头编号按照TCP客户端对TCP消息进行消息头添加处理的顺序获得;
所述第一比较单元具体用于按照所述消息头编号依次比较所述数据消息长度和接收缓冲区中当前待处理数据流长度。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210491483.0A CN102984253B (zh) | 2012-11-27 | 2012-11-27 | 一种传输控制协议粘包处理方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210491483.0A CN102984253B (zh) | 2012-11-27 | 2012-11-27 | 一种传输控制协议粘包处理方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102984253A true CN102984253A (zh) | 2013-03-20 |
CN102984253B CN102984253B (zh) | 2015-10-14 |
Family
ID=47857987
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201210491483.0A Active CN102984253B (zh) | 2012-11-27 | 2012-11-27 | 一种传输控制协议粘包处理方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102984253B (zh) |
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103532668A (zh) * | 2013-10-12 | 2014-01-22 | 成都阜特科技股份有限公司 | 一种确保tcp通信数据完整及正确的方法 |
CN104410613A (zh) * | 2014-11-20 | 2015-03-11 | 广西大学 | 一种处理传输控制协议粘包方法及装置 |
CN104901904A (zh) * | 2015-04-22 | 2015-09-09 | 上海昭赫信息技术有限公司 | 从pcie加速子卡到主机的数据传输方法及装置 |
CN105306355A (zh) * | 2015-09-22 | 2016-02-03 | 上海斐讯数据通信技术有限公司 | 一种传输控制协议粘包处理方法及装置 |
CN105530256A (zh) * | 2015-12-18 | 2016-04-27 | 航天恒星科技有限公司 | 一种卫星通信协议数据的处理装置和*** |
CN105991223A (zh) * | 2015-02-13 | 2016-10-05 | Tcl集团股份有限公司 | 一种tcp网络传输数据中防粘包的方法及*** |
CN107026713A (zh) * | 2017-03-17 | 2017-08-08 | 广东蜂助手网络技术股份有限公司 | 一种在网络通讯包粘连的情况下提高网络速度的方法 |
CN107040549A (zh) * | 2017-06-08 | 2017-08-11 | 山大鲁能信息科技有限公司 | 一种tcp粘包处理方法、服务器及*** |
CN107135167A (zh) * | 2017-04-19 | 2017-09-05 | 畅捷通信息技术股份有限公司 | 数据传输方法、数据传输装置和服务器 |
CN108306865A (zh) * | 2018-01-15 | 2018-07-20 | 厦门科灿信息技术有限公司 | 基于Netty框架的modbus粘包处理方法、装置 |
CN108718311A (zh) * | 2018-05-18 | 2018-10-30 | 深圳市腾讯网络信息技术有限公司 | 移动终端的网页直播方法、装置及*** |
CN109257355A (zh) * | 2018-09-26 | 2019-01-22 | 郑州云海信息技术有限公司 | 一种基于tcp协议数据传输方法、***及相关组件 |
CN109347825A (zh) * | 2018-10-19 | 2019-02-15 | 海南易乐物联科技有限公司 | 一种基于tcp协议数据分包黏包的处理方法 |
CN110086703A (zh) * | 2018-01-26 | 2019-08-02 | 香港乐蜜有限公司 | 一种基于tcp协议的消息传输方法及装置 |
CN111091697A (zh) * | 2019-11-29 | 2020-05-01 | 湖北航天飞行器研究所 | 遥测数据的处理*** |
CN114125081A (zh) * | 2021-10-27 | 2022-03-01 | 桂林长海发展有限责任公司 | 一种接收数据的处理方法、装置及存储介质 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1486031A (zh) * | 2002-09-23 | 2004-03-31 | 华为技术有限公司 | 一种数据传输方法 |
US20050060428A1 (en) * | 2003-09-11 | 2005-03-17 | International Business Machines Corporation | Apparatus and method for caching lookups based upon TCP traffic flow characteristics |
CN101753586A (zh) * | 2010-01-20 | 2010-06-23 | 北京数码视讯科技股份有限公司 | 发送数据的方法、接收数据的处理方法和装置 |
-
2012
- 2012-11-27 CN CN201210491483.0A patent/CN102984253B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1486031A (zh) * | 2002-09-23 | 2004-03-31 | 华为技术有限公司 | 一种数据传输方法 |
US20050060428A1 (en) * | 2003-09-11 | 2005-03-17 | International Business Machines Corporation | Apparatus and method for caching lookups based upon TCP traffic flow characteristics |
CN101753586A (zh) * | 2010-01-20 | 2010-06-23 | 北京数码视讯科技股份有限公司 | 发送数据的方法、接收数据的处理方法和装置 |
Cited By (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103532668B (zh) * | 2013-10-12 | 2016-11-23 | 成都阜特科技股份有限公司 | 一种确保tcp通信数据完整及正确的方法 |
CN103532668A (zh) * | 2013-10-12 | 2014-01-22 | 成都阜特科技股份有限公司 | 一种确保tcp通信数据完整及正确的方法 |
CN104410613A (zh) * | 2014-11-20 | 2015-03-11 | 广西大学 | 一种处理传输控制协议粘包方法及装置 |
CN105991223A (zh) * | 2015-02-13 | 2016-10-05 | Tcl集团股份有限公司 | 一种tcp网络传输数据中防粘包的方法及*** |
CN104901904A (zh) * | 2015-04-22 | 2015-09-09 | 上海昭赫信息技术有限公司 | 从pcie加速子卡到主机的数据传输方法及装置 |
CN105306355A (zh) * | 2015-09-22 | 2016-02-03 | 上海斐讯数据通信技术有限公司 | 一种传输控制协议粘包处理方法及装置 |
CN105530256A (zh) * | 2015-12-18 | 2016-04-27 | 航天恒星科技有限公司 | 一种卫星通信协议数据的处理装置和*** |
CN105530256B (zh) * | 2015-12-18 | 2019-10-25 | 航天恒星科技有限公司 | 一种卫星通信协议数据的处理装置和*** |
CN107026713A (zh) * | 2017-03-17 | 2017-08-08 | 广东蜂助手网络技术股份有限公司 | 一种在网络通讯包粘连的情况下提高网络速度的方法 |
CN107026713B (zh) * | 2017-03-17 | 2018-04-10 | 广东蜂助手网络技术股份有限公司 | 一种在网络通讯包粘连的情况下提高网络速度的方法 |
CN107135167A (zh) * | 2017-04-19 | 2017-09-05 | 畅捷通信息技术股份有限公司 | 数据传输方法、数据传输装置和服务器 |
CN107040549A (zh) * | 2017-06-08 | 2017-08-11 | 山大鲁能信息科技有限公司 | 一种tcp粘包处理方法、服务器及*** |
CN107040549B (zh) * | 2017-06-08 | 2021-03-19 | 山大鲁能信息科技有限公司 | 一种tcp粘包处理方法、服务器及*** |
CN108306865A (zh) * | 2018-01-15 | 2018-07-20 | 厦门科灿信息技术有限公司 | 基于Netty框架的modbus粘包处理方法、装置 |
CN108306865B (zh) * | 2018-01-15 | 2021-02-12 | 厦门科灿信息技术有限公司 | 基于Netty框架的modbus粘包处理方法、装置 |
CN110086703B (zh) * | 2018-01-26 | 2021-10-26 | 卓米私人有限公司 | 一种基于tcp协议的消息传输方法及装置 |
CN110086703A (zh) * | 2018-01-26 | 2019-08-02 | 香港乐蜜有限公司 | 一种基于tcp协议的消息传输方法及装置 |
CN108718311A (zh) * | 2018-05-18 | 2018-10-30 | 深圳市腾讯网络信息技术有限公司 | 移动终端的网页直播方法、装置及*** |
CN109257355A (zh) * | 2018-09-26 | 2019-01-22 | 郑州云海信息技术有限公司 | 一种基于tcp协议数据传输方法、***及相关组件 |
CN109347825B (zh) * | 2018-10-19 | 2020-01-14 | 海南易乐物联科技有限公司 | 一种基于tcp协议数据分包黏包的处理方法 |
CN109347825A (zh) * | 2018-10-19 | 2019-02-15 | 海南易乐物联科技有限公司 | 一种基于tcp协议数据分包黏包的处理方法 |
CN111091697A (zh) * | 2019-11-29 | 2020-05-01 | 湖北航天飞行器研究所 | 遥测数据的处理*** |
CN114125081A (zh) * | 2021-10-27 | 2022-03-01 | 桂林长海发展有限责任公司 | 一种接收数据的处理方法、装置及存储介质 |
CN114125081B (zh) * | 2021-10-27 | 2023-09-22 | 桂林长海发展有限责任公司 | 一种接收数据的处理方法、装置及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN102984253B (zh) | 2015-10-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102984253A (zh) | 一种传输控制协议粘包处理方法及装置 | |
CN104410613A (zh) | 一种处理传输控制协议粘包方法及装置 | |
CN102217251B (zh) | 一种数据转发方法、数据处理方法、***以及相关设备 | |
CN104270684A (zh) | 一种面向实时应用的视音频数据网络传输***和方法 | |
CN101662418A (zh) | 一种传输文件的检测方法及终端 | |
CN103746938A (zh) | 一种发送数据包的方法及装置 | |
CN106452833A (zh) | 一种rtu多协议动态加载的数据传输方法 | |
CN101478462B (zh) | 存储数据读取和写入的装置和方法及固态硬盘 | |
CN105450969B (zh) | 一种实时视频数据传输方法及电子设备 | |
CN104270344A (zh) | 万兆网闸 | |
CN113986192B (zh) | 一种CoaXPress接口数据和Cameralink接口数据互相转换的方法 | |
CN102333210A (zh) | 一种视频数据存储方法及其设备 | |
CN101860738A (zh) | 基于以太网的非压缩视频的传输方法和接收方法 | |
CN101650872B (zh) | 用电信息采集***及方法 | |
CN105580322B (zh) | 接入网中家庭网络信号中继装置及使用其的接入网中家庭网络信号中继方法 | |
CN102917212A (zh) | 一种基于rtp和rtsp的3g无线视频监控实现方法及*** | |
CN101191413B (zh) | 井下数字电视数据的高速传输方法及其传输*** | |
CN103227802B (zh) | 基于udp/tcp协议的多元数据传输方法 | |
CN101572716A (zh) | 传输小型计算机***接口scsi包的方法和装置 | |
CN104378438B (zh) | 数据同步方法及其装置 | |
CN101895470B (zh) | 流控信息传递方法和装置 | |
CN104980259A (zh) | 一种多链路数据传输方法及装置 | |
CN104426746A (zh) | 客户端消息的推送方法、装置和服务器 | |
CN103297474A (zh) | 一种批量处理分包方法和*** | |
CN104507107A (zh) | 一种信令数据的预处理方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
TR01 | Transfer of patent right |
Effective date of registration: 20211206 Address after: 250014 No. 41-1 Qianfo Shandong Road, Lixia District, Jinan City, Shandong Province Patentee after: SHANDONG CIVIC SE COMMERCIAL MIDDLEWARE Co.,Ltd. Address before: 250014 No. 41-1 Qianfo Shandong Road, Lixia District, Jinan City, Shandong Province Patentee before: SHANDONG CVIC SOFTWARE ENGINEERING Co.,Ltd. Patentee before: Shandong Zhongchuang software commercial middleware Co., Ltd |
|
TR01 | Transfer of patent right |