CN113364862B - 一种拼包解码系统及方法 - Google Patents
一种拼包解码系统及方法 Download PDFInfo
- Publication number
- CN113364862B CN113364862B CN202110620319.4A CN202110620319A CN113364862B CN 113364862 B CN113364862 B CN 113364862B CN 202110620319 A CN202110620319 A CN 202110620319A CN 113364862 B CN113364862 B CN 113364862B
- Authority
- CN
- China
- Prior art keywords
- packet
- data packet
- decoding
- cache
- pdu
- 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.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
本发明提供了一种拼包解码系统及方法,涉及通信技术领域,该方法包括:拼包器:接收外部数据包输入,并基于拼包缓存,完成对数据包的拼包重组;再将重组后的数据包TCP负载字节数组输出到应用层解码器进行解码;应用层解码器:对来自拼包器步骤中的重组应用层协议PDU字节数组进行解码,供业务分析。本发明能够省去大部分单包解码操作,提高整体拼包解码的性能;提高乱序和丢包场景下的解码效率,节省大量无效解码开销;且能够避免对因乱序和丢包导致的不连续PDU数据包的解码;通过控制拼包缓存数量上限值,防止拼包缓存内存分配无限制增长。
Description
技术领域
本发明涉及通信技术领域,具体地,涉及一种拼包解码系统及方法。
背景技术
网络数据包包含了从网络层到应用层的所有信息。通过对网络中的数据包流量进行处理分析,我们可以获得网络主机之间的通信记录,进而实现对网络所承载业务的事件追踪和性能监控。
通常的应用层协议报文,或称作协议数据单元(PDU,Payload Data Unit),使用可靠的TCP/IP协议来进行传输。TCP/IP协议会根据MTU(最大传输单元)将一段长的PDU拆解到若干个数据包进行传输。所以,如果要从网络数据包中提取完整的PDU内容,需要对数据包流根据TCP/IP协议规范进行拼包重组,得到应用层通信字节流,然后根据应用层协议规范对字节流进行PDU分段和解码。
通常的做法时,在每个数据包到来时,根据应用层协议规范,预解码判断当前数据包是否是PDU开始。如果是,则进行后续解码。如果不是,则尝试和之前的数据包拼在一起进行解码。在此过程中,由于需要对每个数据包进行预解码判断是否是PDU开始,所以在PDU特别长、拆解的数据包特别多的场景下,会出现除第一个数据包判断成功,后续数据包都判断失败的现象,造成无效的计算浪费。正常情况下,如果存在之前的数据包缓存,那就说明之前的数据包无法完整拼凑应用层PDU,需要后续数据包来补充。而如果当前数据包能够连接到之前缓存数据包的末尾,就说明当前数据包就是应用层PDU的中段或末尾部分,无需判断是否是PDU开始。
公开号为CN101964751B的中国专利,公开了一种数据包的传输方法及装置,所述方法具体包括:首先在上行时,将基本信元进行调度,并进行拼包处理后发送给交换网;所述拼包处理为:将具有相同上行拼包规则的数据包进行拼包;下行,从交换网接收拼包后的数据包,将所述数据包交叉进行解拼包和包重组操作,并将解拼包和包重组后的数据包进行缓存;将缓存的解拼包和包重组后的数据包进行调度后输出。通过上述技术方案的实施,就可以提高上行节点的拼包成功率,减少了对资源的消耗。
现有技术当中只要当前数据包能拼接在缓存数据包末尾,就尝试进行一次解码。而在数据包乱序或丢包场景下,往往由于PDU数据包不连续,造成即使完成拼接,也无法成功解码,从而产生大量无效解码,浪费计算资源。现有方法在拼包缓存中只维护一个PDU,即在遇到新的PDU开始数据包时就清空缓存。虽然这种机制简单易于实现,但在数据包乱序场景下,提早到来的后续PDU开始数据包就会把之前还未拼完整的PDU给冲掉,造成输出PDU缺失。
发明内容
针对现有技术中的缺陷,本发明提供一种拼包解码系统及方法。
根据本发明提供的一种拼包解码系统及方法,所述方案如下:
第一方面,提供了一种拼包解码系统,所述系统包括:
拼包器:接收外部数据包输入,并基于拼包缓存,完成对数据包的拼包重组;再将重组后的数据包TCP负载字节数组输出到应用层解码器进行解码;
应用层解码器:对来自拼包器步骤中的重组PDU字节数组进行解码,供业务分析。
优选的,所述拼包器中的拼包缓存用于缓存接收到的PDU被拆解的部分数据包。
第二方面,提供了一种拼包解码方法,所述方法包括:
步骤S1:输入新数据包,判断新数据包是否能拼接到缓存数据包之后;
步骤S2:将当前数据包添加到拼包缓存;即将新数据包连接到步骤S1中寻找到的缓存数据包的末尾;
步骤S3:判断是否存在前溯连续PDU开始数据包;
步骤S4:从前溯连续PDU开始处尝试解码;
步骤S5:判断是否解码成功;即判断步骤S4解码结果,若解码成功,则说明重组的TCP负载字节数组已经成功组成了一个完整的应用层协议PDU,进入步骤S6,否则跳转到步骤S19;
步骤S6:从拼包缓存中清除解码成功的数据包;即在拼包缓存中,清除用于TCP负载重组和解码的相关数据包,以释放内存,然后进入步骤S7;
步骤S7:输出应用层解码信息;将之前解码获得的应用层协议PDU信息结构体输出到其他业务系统做进一步分析,整个拼包解码过程结束;
步骤S8:判断是否存在后续连续数据包;
步骤S9:尝试解码新数据包连同后续连续数据包;即将新数据包和所有后续连续数据包重组在一起,并进行应用层解码,获得解码结果,然后进入步骤S10;
步骤S10:判断是否解码成功;如果成功,则进入步骤S6。否则跳转到步骤S17;
步骤S11:尝试解码新数据包;将新数据包TCP负载单独进行应用层解码,获得解码结果后进入步骤S10;
步骤S12:判断新数据包是否能拼接到缓存数据包之前;
步骤S13:新数据包拼接在缓存数据包之前,将新数据包加入拼包缓存,并拼接在步骤S12所找到的后续连续数据包之前,然后跳转到步骤S17;
步骤S14:尝试解码新数据包;将当前数据包TCP负载字节数组传递给应用层解码器进行解码,获得解码结果后,进入步骤S15;
步骤S15:判断是否解码成功;
步骤S16:新数据包孤立地加入拼包缓存;即将新数据包加入拼包缓存中并与其它缓存数据包不连续,然后进入步骤S17;
步骤S17:判断当前数据包是否是应用层PDU开始;
步骤S18:标记PDU开始数据包位置;在拼包缓存中将刚加入的新数据包标记为PDU开始数据包,然后进入步骤S19;
步骤S19:判断拼包缓存数量是否超过上限;如果拼包缓存中的数据包数量已经超过预先设定的拼包缓存数量上限,则进入步骤S20,否则整个拼包解码过程结束;
步骤S20:从拼包缓存中删除第一段连续数据包。
优选的,所述步骤S3具体包括:在拼包缓存中定位到步骤S2中添加的新数据包位置,往前回溯寻找能够拼接在一起,并且被标记为应用层PDU开始位置的前驱数据包;若寻找到,则进入步骤S4,否则进入步骤S8。
优选的,所述步骤S4具体包括:以步骤S3中寻找到的PDU开始数据包作为开始数据包,以新数据包作为结束数据包,将开始和结束数据包之间的数据包TCP负载连接在一起,组成字节数组,并传递给应用层解码器进行解码;解码结束后,进入步骤S5。
优选的,所述步骤S8具体包括:在拼包缓存中寻找一个缓存数据包,满足其TCPSequence Number正好等于新数据包的TCP Sequence Number加上新数据包的TCP负载长度;如果存在,进入步骤S9,否则进入步骤S11。
优选的,所述步骤S12具体包括:在拼包缓存中寻找一段连续数据包的第一个数据包,满足其TCP Sequence Number正好等于新数据包的TCP Sequence Number加上新数据包的TCP负载长度;如果存在,进入步骤S13,否则进入步骤S14。
优选的,所述步骤S15具体包括:判断步骤S14得到的解码结果,若解码成功,则说明新数据包已经包含一个完整的应用层协议PDU,进入步骤S7,否则进入步骤S16。
优选的,所述步骤S17具体包括:根据步骤S14的解码结果,判断新数据包的TCP负载是否是应用层PDU的开始;如果是,进入步骤S18,否则进入步骤S19。
优选的,所述步骤S20具体包括:从拼包缓存中找到第一个数据包,然后连同其后续存在的连续数据包进行删除并释放内存空间。
与现有技术相比,本发明具有如下的有益效果:
1、针对长PDU数据分包传输场景,针对健康网络状况优化拼包解码过程,省去了大部分单包解码操作,提高了整体拼包解码的性能;
2、提高乱序和丢包场景下的解码效率,节省大量无效解码开销;
3、在当前数据包加入拼包缓存后,通过判断是否存在前溯连续PDU开始数据包,来决定是否尝试解码,避免对因乱序和丢包导致的不连续PDU数据包的解码;
4、针对数据包丢包现象提供必要的保护机制,通过控制拼包缓存数量上限值,防止拼包缓存内存分配无限制增长。
附图说明
通过阅读参照以下附图对非限制性实施例所作的详细描述,本发明的其它特征、目的和优点将会变得更明显:
图1为为本系统模块图;
图2为拼包缓存模块图;
图3本发明方法流程示意图;
图4为拼包场景说明图;
图5为拼包场景说明图;
图6为拼包场景说明图;
图7为拼包场景说明图。
具体实施方式
下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明,但不以任何形式限制本发明。应当指出的是,对本领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干变化和改进。这些都属于本发明的保护范围。
本发明实施例提供了一种拼包解码系统,参照图1所示,该系统包括拼包器:接收外部数据包输入,并基于拼包缓存,完成对数据包的拼包重组;再将重组后的数据包TCP负载字节数组输出到应用层解码器进行解码。
应用层解码器:对来自拼包器步骤中的重组PDU字节数组进行解码,供业务分析。应用层解码是指根据应用层协议规范,将字节数组中的不同区域读取成协议字段信息。例如,解码HTTP协议PDU,输出HTTP方法(HTTP Method),URI,HTTP状态码(HTTP StatusCodde)等信息。
参照图2所示,拼包器中的拼包缓存,用于缓存接收到的PDU被拆解的部分数据包。这些数据包缺少组成完整PDU的其它数据包,所以还无法成功完成应用层解码,所以需要被缓存,以等待剩余数据包进行重组。
拼包缓存将数据包按TCP Sequence Number由小到大排列。拼包缓存将连续的数据包拼接在一起。所谓连续是指后一个数据包的TCP Sequence Number正好等于前一个数据包的TCP Sequence Number加上前一个数据包的TCP负载长度。例如图2中,数据包1、2、3和4都是连续的,但和数据包5不连续。连续的数据包的TCP负载能够被重组连接为字节数组,供应用层协议解码。如果重组后的TCP负载包含一个完整的应用层协议PDU,则解码成功,就可以从拼包缓存中删除这些数据包。如果重组后的TCP负载不完整,则还需缓存这些数据包,等待剩余数据包输入并重新重组后再次尝试应用层协议解码。
本发明实施例还提供了一种拼包解码方法,基于拼包器和应用层协议解码器来运行,参照图3所示,本方法具体包括如下步骤:
步骤S1:输入新数据包,判断新数据包是否能拼接到缓存数据包之后;具体是,读取新数据包的TCP Sequence Number,记为S1。在拼包缓存中寻找一个缓存数据包,满足S1正好等于该缓存数据包的TCP Sequence Number加上其TCP负载长度。如果存在,则进入步骤S2,否则进入步骤S12。例如,参照图4所示,新数据包(数据包4)的TCP Sequence Number为14500,正好等于缓存数据包3的TCP Sequence Number(13000)加上其TCP负载长度(1500),所以新数据包能拼接在数据包3的末尾。
步骤S2:将当前数据包添加到拼包缓存;具体是,将新数据包连接到步骤S1中寻找到的缓存数据包的末尾;例如,如图4,将新数据包缓存并连接到数据包3的右侧,然后进入步骤S3。
步骤S3:判断是否存在前溯连续PDU开始数据包;具体是,在拼包缓存中定位到步骤S2中添加的新数据包位置,往前回溯寻找能够拼接在一起,并且被标记为应用层PDU开始位置的前驱数据包。若寻找到,则进入步骤S4,否则进入步骤S8。例如,如图4,由于数据包1被标记为PDU开始位置,而且能够和新数据包连接在一起,所以数据包1就是新数据包的前溯连续PDU开始数据包。而如果数据包5是新数据包,由于其无法和之前任何缓存的数据包连接在一起,所以不存在前溯PDU开始数据包。参照图5所示,如果数据包6是新数据包,它虽然能够和数据包5和6连接在一起,但是数据包5和6都未标记为PDU开始位置数据包,所以也不存在前溯PDU开始数据包。
步骤S4:从前溯连续PDU开始处尝试解码;具体是,以步骤S3中寻找到的PDU开始数据包作为开始数据包,以新数据包作为结束数据包,将开始和结束数据包之间(包含开始和结束)的数据包TCP负载连接在一起,组成字节数组,并传递给应用层解码器进行解码。解码结束后,进入步骤S5。例如,参考图2所示,数据包1、2、3、4的TCP负载被连接在一起传递给应用层解码器。
步骤S5:判断是否解码成功;即判断步骤S4解码结果,若解码成功,则说明重组的TCP负载字节数组已经成功组成了一个完整的应用层PDU,进入步骤S6,否则跳转到步骤S19;
步骤S6:从拼包缓存中清除解码成功的数据包;具体是,在拼包缓存中,清除用于TCP负载重组和解码的相关数据包,以释放内存,然后进入步骤S7;
步骤S7:输出应用层解码信息;将之前解码获得的应用层协议PDU信息结构体输出到其他业务系统做进一步分析,整个拼包解码过程结束;
步骤S8:判断是否存在后续连续数据包;具体是,在拼包缓存中寻找一个缓存数据包,满足其TCP Sequence Number正好等于新数据包的TCP Sequence Number加上新数据包的TCP负载长度,如果存在,进入步骤S9,否则进入步骤S11。例如,参考图6,数据包5和6能够成为新数据包(数据包4)的后续连续数据包。
步骤S9:尝试解码新数据包连同后续连续数据包;具体是,将新数据包和所有后续连续数据包重组在一起,并进行应用层解码,获得解码结果,然后进入步骤S10;
步骤S10:判断是否解码成功;如果成功,则进入步骤S6。否则跳转到步骤S17;
步骤S11:尝试解码新数据包;具体是,将新数据包TCP负载单独进行应用层解码,获得解码结果后进入步骤S10;
步骤S12:判断新数据包是否能拼接到缓存数据包之前;具体是,在拼包缓存中寻找一段连续数据包的第一个数据包,满足其TCP Sequence Number正好等于新数据包的TCPSequence Number加上新数据包的TCP负载长度。如果存在,进入步骤S13,否则进入步骤S14。例如,参照图5所示,新数据包能够被拼接到缓存数据包5之前。
步骤S13:新数据包拼接在缓存数据包之前,将新数据包加入拼包缓存,并拼接在步骤S12所找到的后续连续数据包之前,然后跳转到步骤S17;
步骤S14:尝试解码新数据包;将当前数据包TCP负载字节数组传递给应用层解码器进行解码,获得解码结果后,进入步骤S15;
步骤S15:判断是否解码成功;具体是,判断步骤S14得到解码结果,若解码成功,则说明新数据包已经包含一个完整的应用层PDU,进入步骤S7,否则进入步骤S16。
步骤S16:新数据包孤立地加入拼包缓存;具体是,将新数据包加入拼包缓存中并与其它缓存数据包不连续,然后进入步骤S17;例如,参照图7所示,由于新数据包的TCPSequence Number处于数据包3和数据包5之间,且和它们的TCP Sequence Number不相连,所以被孤立地存放到它们之间。
步骤S17:判断当前数据包是否是应用层PDU开始;具体是,根据步骤S14的解码结果,判断新数据包的TCP负载是否是应用层PDU的开始;如果是,进入步骤S18,否则进入步骤S19。
步骤S18:标记PDU开始数据包位置;在拼包缓存中将刚加入的新数据包标记为PDU开始数据包,然后进入步骤S19;
步骤S19:判断拼包缓存数量是否超过上限;如果拼包缓存中的数据包数量已经超过预先设定的拼包缓存数量上限,则进入步骤S20,否则整个拼包解码过程结束。
步骤S20:从拼包缓存中删除第一段连续数据包。具体为,从拼包缓存中找到第一个数据包,然后连同其后续存在的连续数据包(如果存在)进行删除并释放内存空间。由于拼包缓存中第一个数据包是最旧的数据包,如果迟迟得不到释放,一般是由于丢包导致缺少必要的数据包来重组成完整PDU。
本发明实施例提供了一种拼包解码系统及方法,1、针对长PDU数据分包传输场景,针对健康网络状况优化拼包解码过程,省去了大部分单包解码操作,提高了整体拼包解码的性能。
举例来说,对于一个典型的HTTP请求来说,响应如果是HTML页面,一般在2MB~10MB,响应如果是XML或者SOAP等,根据业务情况,一般是500KB~3MB。那么,假设网络MTU是1514字节,那么除去MAC地址14字节,除去IP包头典型的20字节,再除去TCP包头典型的20字节(或者其他<=60字节的数据),可知,数据链路允许的最大TCP业务长度是1460字节。所以,
对于2M~10MB的HTML响应来说,需要1437~7183个数据包,
对于500K~3M的XML/SOAP响应来说,需要351~2155个数据包,
因此本发明可以节约巨大的单包解码开销,只需做1次完整解码,从而大大提高解码性能。
2、在数据据包乱序和丢包场景下,本发明省去了大量无效解码开销。假设一次HTTP请求需要1000个数据包,并假设在极端场景下,第1个数据包最后到来。现有技术由于需要针对一个数据包同时尝试单包解码和拼接在之前数据包之后解码,总共需要花费2000次解码。而本发明在第3到第1000个数据包到来时,由于前溯连续可达的最早数据包时第2个数据包,它不是PDU开始,所以只需要进行一次单包解码以检测当前数据包是否是新PDU开始数据包,所以总共需要花费1000次解码,相比现有技术省去了一半的拼包后解码次数,从而提高解码性能。
3、本发明能够在数据包乱序场景下,保证PDU不丢失。在后续PDU开始数据包提早到来时,保留之前PDU的未完整数据包缓存,以等待后续到来的数据包补充完整,保证了之前PDU的解码机会。另外通过控制缓存数据包数量上限值,来发生数据包乱序时能保证PDU不缺失。如果不能正确处理这种场景,那么方法的准确性低,解码获得的PDU数据不完整,无法实际使用。
4、本发明针对数据包丢包现象提供必要的保护机制,通过控制拼包缓存数量上限值,防止拼包缓存内存分配无限制增长。如果不能正确处理这种场景,那么这种方法将无法实际使用。
本领域技术人员知道,除了以纯计算机可读程序代码方式实现本发明提供的系统及其各个装置、模块、单元以外,完全可以通过将方法步骤进行逻辑编程来使得本发明提供的系统及其各个装置、模块、单元以逻辑门、开关、专用集成电路、可编程逻辑控制器以及嵌入式微控制器等的形式来实现相同功能。所以,本发明提供的系统及其各项装置、模块、单元可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置、模块、单元也可以视为硬件部件内的结构;也可以将用于实现各种功能的装置、模块、单元视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
以上对本发明的具体实施例进行了描述。需要理解的是,本发明并不局限于上述特定实施方式,本领域技术人员可以在权利要求的范围内做出各种变化或修改,这并不影响本发明的实质内容。在不冲突的情况下,本申请的实施例和实施例中的特征可以任意相互组合。
Claims (2)
1.一种拼包解码方法,其特征在于,基于拼包解码系统,所述拼包解码系统包括:
拼包器:接收外部数据包输入,并基于拼包缓存,完成对数据包的拼包重组;再将重组后的数据包TCP负载字节数组输出到应用层解码器进行解码;
应用层解码器:对来自拼包器步骤中的重组PDU字节数组进行解码,供业务分析;
所述拼包器中的拼包缓存用于缓存接收到的PDU被拆解的部分数据包;
所述拼包解码方法包括:
步骤S1:输入新数据包,判断新数据包是否能拼接到缓存数据包之后;
步骤S2:将当前数据包添加到拼包缓存;即将新数据包连接到步骤S1中寻找到的缓存数据包的末尾;
步骤S3:判断是否存在前溯连续PDU开始数据包;
步骤S4:从前溯连续PDU开始处尝试解码;
步骤S5:判断是否解码成功;即判断步骤S4解码结果,若解码成功,则说明重组的TCP负载字节数组已经成功组成了一个完整的应用层协议PDU,进入步骤S6,否则跳转到步骤S19;
步骤S6:从拼包缓存中清除解码成功的数据包;即在拼包缓存中,清除用于TCP负载重组和解码的相关数据包,以释放内存,然后进入步骤S7;
步骤S7:输出应用层解码信息;将之前解码获得的应用层协议PDU信息结构体输出到其他业务系统做进一步分析,整个拼包解码过程结束;
步骤S8:判断是否存在后续连续数据包;
步骤S9:尝试解码新数据包连同后续连续数据包;即将新数据包和所有后续连续数据包重组在一起,并进行应用层解码,获得解码结果,然后进入步骤S10;
步骤S10:判断是否解码成功;如果成功,则进入步骤S6; 否则跳转到步骤S17;
步骤S11:尝试解码新数据包;将新数据包TCP负载单独进行应用层解码,获得解码结果后进入步骤S10;
步骤S12:判断新数据包是否能拼接到缓存数据包之前;
步骤S13:新数据包拼接在缓存数据包之前,将新数据包加入拼包缓存,并拼接在步骤S12所找到的后续连续数据包之前,然后跳转到步骤S17;
步骤S14:尝试解码新数据包;将当前数据包TCP负载字节数组传递给应用层解码器进行解码,获得解码结果后,进入步骤S15;
步骤S15:判断是否解码成功;
步骤S16:新数据包孤立地加入拼包缓存;即将新数据包加入拼包缓存中并与其它缓存数据包不连续,然后进入步骤S17;
步骤S17:判断当前数据包是否是应用层PDU开始;
步骤S18:标记PDU开始数据包位置;在拼包缓存中将刚加入的新数据包标记为PDU开始数据包,然后进入步骤S19;
步骤S19:判断拼包缓存数量是否超过上限;如果拼包缓存中的数据包数量已经超过预先设定的拼包缓存数量上限,则进入步骤S20,否则整个拼包解码过程结束;
步骤S20:从拼包缓存中删除第一段连续数据包;
所述步骤S3具体包括:在拼包缓存中定位到步骤S2中添加的新数据包位置,往前回溯寻找能够拼接在一起,并且被标记为应用层PDU开始位置的前驱数据包;若寻找到,则进入步骤S4,否则进入步骤S8;
所述步骤S4具体包括:以步骤S3中寻找到的PDU开始数据包作为开始数据包,以新数据包作为结束数据包,将开始和结束数据包之间的数据包TCP负载连接在一起,组成字节数组,并传递给应用层解码器进行解码;解码结束后,进入步骤S5;
所述步骤S8具体包括:在拼包缓存中寻找一个缓存数据包,满足其TCP SequenceNumber正好等于新数据包的TCP Sequence Number加上新数据包的TCP负载长度;如果存在,进入步骤S9,否则进入步骤S11;
所述步骤S12具体包括:在拼包缓存中寻找一段连续数据包的第一个数据包,满足其TCP Sequence Number正好等于新数据包的TCP Sequence Number加上新数据包的TCP负载长度;如果存在,进入步骤S13,否则进入步骤S14;
所述步骤S15具体包括:判断步骤S14得到的解码结果,若解码成功,则说明新数据包已经包含一个完整的应用层协议PDU,进入步骤S7,否则进入步骤S16;
所述步骤S17具体包括:根据步骤S14的解码结果,判断新数据包的TCP负载是否是应用层PDU的开始;如果是,进入步骤S18,否则进入步骤S19。
2.据权利要求1所述的拼包解码方法,其特征在于,所述步骤S20具体包括:从拼包缓存中找到第一个数据包,然后连同其后续存在的连续数据包进行删除并释放内存空间。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110620319.4A CN113364862B (zh) | 2021-06-03 | 2021-06-03 | 一种拼包解码系统及方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110620319.4A CN113364862B (zh) | 2021-06-03 | 2021-06-03 | 一种拼包解码系统及方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN113364862A CN113364862A (zh) | 2021-09-07 |
CN113364862B true CN113364862B (zh) | 2022-10-11 |
Family
ID=77531740
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110620319.4A Active CN113364862B (zh) | 2021-06-03 | 2021-06-03 | 一种拼包解码系统及方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113364862B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114024924B (zh) * | 2022-01-05 | 2022-04-12 | 北京安博通科技股份有限公司 | 一种tcp流重组方法、装置、电子设备及存储介质 |
CN114465966B (zh) * | 2022-01-23 | 2024-05-28 | 山东云海国创云计算装备产业创新中心有限公司 | 一种数据包重组控制系统和数据包重组方法 |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101631122B (zh) * | 2009-08-03 | 2012-01-11 | 杭州安恒信息技术有限公司 | 一种丢包环境下提升tds协议解析正确率的方法 |
CN101841545B (zh) * | 2010-05-14 | 2012-08-01 | 中国科学院计算技术研究所 | 一种tcp流重组拼包方法和装置 |
CN108881062A (zh) * | 2017-05-12 | 2018-11-23 | 深圳市中兴微电子技术有限公司 | 一种数据包传输方法和设备 |
CN107743102B (zh) * | 2017-10-31 | 2020-01-31 | 北京亚鸿世纪科技发展有限公司 | 一种高效的tcp会话重组方法 |
CN110401513B (zh) * | 2019-08-02 | 2021-12-17 | 视联动力信息技术股份有限公司 | 一种数据传输方法和装置 |
CN112491871B (zh) * | 2020-11-25 | 2023-07-28 | 北京宝兰德软件股份有限公司 | 一种tcp重组方法、装置、电子设备及存储介质 |
CN112565115A (zh) * | 2020-11-27 | 2021-03-26 | 上海金仕达软件科技有限公司 | Tcp数据的传输方法、装置、计算机设备及存储介质 |
CN114024924B (zh) * | 2022-01-05 | 2022-04-12 | 北京安博通科技股份有限公司 | 一种tcp流重组方法、装置、电子设备及存储介质 |
-
2021
- 2021-06-03 CN CN202110620319.4A patent/CN113364862B/zh active Active
Also Published As
Publication number | Publication date |
---|---|
CN113364862A (zh) | 2021-09-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN113364862B (zh) | 一种拼包解码系统及方法 | |
US7953817B2 (en) | System and method for supporting TCP out-of-order receive data using generic buffer | |
US8526441B2 (en) | System and method for handling out-of-order frames | |
KR100506253B1 (ko) | 데이터 통신 시스템에서 전송 지연을 최소화하기 위한장치 및 방법 | |
US7602809B2 (en) | Reducing transmission time for data packets controlled by a link layer protocol comprising a fragmenting/defragmenting capability | |
US8259728B2 (en) | Method and system for a fast drop recovery for a TCP connection | |
JP2008512895A (ja) | 通信ネットワーク内でヘッダを生成するための方法及び装置 | |
KR102633193B1 (ko) | 메시지 처리 방법 및 관련 장치 | |
WO2014135038A1 (zh) | 基于pcie总线的报文传输方法与装置 | |
US20070291782A1 (en) | Acknowledgement filtering | |
CN114513335B (zh) | 一种基于单向光闸的数据流融合高效传输方法 | |
CN111181819B (zh) | 一种基于链表结构的接收多字节数据帧的串口通讯方法 | |
US7283527B2 (en) | Apparatus and method of maintaining two-byte IP identification fields in IP headers | |
JP5473406B2 (ja) | ネットワーク処理装置及びその処理方法 | |
CN107707548B (zh) | Tlv报文解析方法、装置、电子设备及存储介质 | |
CN117527722A (zh) | 流量管理方法、系统、设备及可读存储装置 | |
CN107332839B (zh) | 一种报文传输方法及装置 | |
CN112433977B (zh) | 一种基于vb环境下电测系统多台串口设备通讯方法 | |
CN114615347A (zh) | 基于udp gso的数据传输方法和装置 | |
CN106330834B (zh) | 一种虚拟通道连接建立方法及装置 | |
CN114979793A (zh) | 一种直播数据传输方法、装置、系统、设备和介质 | |
CN114157730A (zh) | 一种报文去重的方法和装置 | |
WO2014187348A1 (zh) | 报文处理方法和装置 | |
CN110691043B (zh) | 一种支持多源多虚通道非连续传输的插花整理方法 | |
CN116016687B (zh) | 一种基于dpdk的报文分流方法及系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |