CN111949542A - 回归测试或者压力测试的生成数据的提取方法及装置 - Google Patents
回归测试或者压力测试的生成数据的提取方法及装置 Download PDFInfo
- Publication number
- CN111949542A CN111949542A CN202010821304.XA CN202010821304A CN111949542A CN 111949542 A CN111949542 A CN 111949542A CN 202010821304 A CN202010821304 A CN 202010821304A CN 111949542 A CN111949542 A CN 111949542A
- Authority
- CN
- China
- Prior art keywords
- packet
- application layer
- session
- layer data
- determining
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明提供的一种回归测试或者压力测试的生成数据的提取方法及装置,可用于信息安全技术领域,通过对待提取数据进行抓包,得到多个封包文件;然后解析每个封包文件,得到解析的数据以及多个标志位上的参数;最后结合所述多个标志位从解析得到的数据中提取每个会话对应的应用层数据。相较于提取单个封包文件,避免了Wireshark一次加载大文件引起的内存溢出,同时可以通过标志位来锚定每个会话的起始和终点,保证每个会话应用层数据的完整性,可以提取出完整的应用层数据,避免因TCP层被分片导致不完整的问题。
Description
技术领域
本发明涉及数据提取技术领域,尤其涉及一种回归测试或者压力测试的生成数据的提取方法及装置。
背景技术
本部分旨在为权利要求书中陈述的本发明实施例提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。
目前回归测试/压力测试数据生成的方法之一,是使用Tcpdump在生产环境抓取网络封包保存成封包文件(单个),通过Wireshark脚本(tshark、pyshark等)解析封包文件,从单个TCP封包提取出应用层数据,变形后作为测试数据使用。
上述方法存在3个问题:
第一,当应用层数据超过TCP的MSS(MaximumSegmentSize最大报文段长度,一般1460字节),应用层数据会在TCP层被分片,从单个TCP封包提取的应用层数据不一定是完整数据。
第二,对于交易量大、抓取时间长的场景,捕获的单封包文件可能达数G。Wireshark脚本是把整个封包文件读入内存再解析,因此对大文件的数据提取受限于机器内存;当文件超出内存限制,Wireshark将自动退出。该问题已被记录在Wireshark官网(https://wiki.wireshark.org/KnownBugs/OutOfMemory),Wireshark方面给出的解决方案是增加物理内存和虚拟内存,但这些方法受设备的软硬件限制。
第三,针对第二个问题,可以限制Tcpdump捕获的单个封包文件大小,但又存在与第一点类似的问题:若存在TCP分片,则同一个TCP会话的不同分片可能会存在于不同的封包文件,提取到的应用层数据仍然不一定是完整数据。
发明内容
为了解决上述问题的至少一个,本发明实施例提供一种回归测试或者压力测试的生成数据的提取方法及装置,通过将数据抓包成多个封包小文件,然后利用标志位实现应用层数据的提取,能够提取得到完整的应用层数据。
本发明的一个方面,一种回归测试或者压力测试的生成数据的提取方法,包括:
对回归测试或者压力测试产生的数据进行抓包,得到多个封包文件;所述回归测试或者压力测试数据产生的数据包括终端与交互***进行至少一次会话产生的应用层数据;
解析每个封包文件,得到所有会话对应的应用层数据包;
基于会话协议的交互信息确定每个会话各自对应的应用层数据包,进而得到每个会话对应的应用层数据。
在某些实施例中,所述交互信息包括:每个应用层数据包的包序号、确认包序号和封包类型,以及双方交互的地址信息;
所述基于会话协议的交互信息确定每个会话各自对应的应用层数据包,包括:
根据每个应用层数据包的封包类型以及包序号、确认包序号确定单次会话的起始应用层数据包和终点应用层数据包,以及
结合每个应用层数据包的抓包序号和封包类型,以及双方交互的地址信息、包序号和确认包序号,根据每个所述起始应用层数据包和所述终点应用层数据包,确定每个会话对应的所有应用层数据包,其中,每个会话对应的所有应用层数据包中的数据按照所述抓包序号的大小排序形成所述应用层数据。
在某些实施例中,所述基于会话协议的交互信息确定每个会话各自对应的应用层数据包,还包括:
根据每个应用层数据包的封包类型确定对应交互双方的端口状态;
所述结合每个应用层数据包的抓包序号和封包类型,以及双方交互的地址信息、包序号和确认包序号,根据每个所述起始应用层数据包和所述终点应用层数据包,确定每个会话对应的所有应用层数据包,包括:
结合每个应用层数据包的抓包序号和端口状态,以及双方交互的地址信息、包序号和确认包序号,根据每个所述起始应用层数据包和所述终点应用层数据包,确定每个会话对应的所有应用层数据包及对应的应用层数据包顺序。
在某些实施例中,所述基于会话协议的交互信息确定每个会话各自对应的应用层数据包,还包括:
根据每个应用层数据包的会话标志位上的特征值确定应用层数据包的封包类型。
在某些实施例中,所述会话标志位包括:SEQ标志位、LEN标志位、ACK标志位;所述特征值包括0和1。
在某些实施例中,所述封包类型包括:SYN、SYN+ACK、ACK、PSH+ACK、RST+ACK、FIN+ACK以及URG+ACK;
所述根据每个应用层数据包的封包类型确定对应交互双方的端口状态,包括:
若封包类型为SYN的应用层数据包,确定源端口状态为SYN_SENT;目的端口状态为空;
对于封包类型为SYN+ACK的应用层数据包,确定源端口状态为SYN_SENT,目的端口状态为SYN_RECV;
对于封包类型为ACK的应用层数据包,确定源端口状态为ESTABLISHED,目的端口状态为SYN_RECV;
对于封包类型为ACK的应用层数据包,区分该封包类型为ACK的应用层数据包的会话状态为携带数据、三次握手的第3次、四次挥手第2次、四次挥手第4次交互中的一个,若所述会话状态为三次握手的第3次,则确定源端口状态为ESTABLISHED,若所述会话状态为四次挥手第2次,则确定源端口状态为CLOSE_WAIT,若四次挥手第4次,则确定源端口状态为TIME_WAIT,目的端口状态为SYN_RECV;
对于封包类型为PSH+ACK的应用层数据包,确定交互双方端口为ESTABLISHED;
对于封包类型为FIN+ACK,区分该封包类型为ACK的应用层数据包的会话状态为四次挥手的第1次或者第3次交互,若为四次挥手的第1次,则源端口状态确定为FIN_WIAT1;若是四次挥手第2次,则源端口状态确定为LAST_ACK。
在某些实施例中,还包括:若在单次会话中存在一封包类型为RST+ACK的应用层数据包,丢弃对应会话的所有应用层数据。
本发明另一方面提供一种回归测试或者压力测试的生成数据的提取装置,包括:
抓包模块,对待提取数据进行抓包,得到多个封包文件;所述待提取数据包括终端与交互***进行至少一次会话产生的应用层数据;
解析模块,解析每个封包文件,得到解析的数据以及多个标志位,所述标志位与每种封包类型一一对应;
提取模块,结合所述多个标志位从解析得到的数据中提取每个会话对应的应用层数据。
在优选的实施例中,所述提取模块,包括:
类型确定单元,根据每个会话的标志位判断每个封包的类型;
应用层数据提取单元,根据每个封包的类型、每个封包类型下会话对应的双方地址、双方端口及双方端口状态,提取每个会话对应的应用层数据。
在优选的实施例中,所述抓包模块通过TcpDump抓包工具对待提取数据进行抓包。
在优选的实施例中,所述解析模块通过Wireshark解析每个封包文件。
本发明又一方面提供了一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现上述第一方面任一所述方法。
本发明又一方面提供了一种计算机可读存储介质,所述计算机可读存储介质存储有执行上述第一方面任一所述方法的计算机程序。
本发明的有益效果如下:
综上所述,本发明提供的一种回归测试或者压力测试的生成数据的提取方法及装置,通过对待提取数据进行抓包,得到多个封包文件;然后解析每个封包文件,得到解析的数据以及多个标志位上的参数;最后结合所述多个标志位从解析得到的数据中提取每个会话对应的应用层数据。相较于提取单个封包文件,避免了Wireshark一次加载大文件引起的内存溢出,同时可以通过标志位来锚定每个会话的起始和终点,保证每个会话应用层数据的完整性,可以提取出完整的应用层数据,避免因TCP层被分片导致不完整的问题。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。在附图中:
图1为本发明实施例中提供的各类封包处理步骤示意图。
图2为本发明实施例中提供的SYN+ACK封包处理步骤示意图。
图3为本发明实施例中提供的ACK封包处理步骤示意图。
图4为本发明实施例中提供的PSH+ACK封包处理步骤示意图。
图5为本发明实施例中提供的FIN+ACK封包处理步骤示意图。
图6为本发明实施例中提供的一种回归测试或者压力测试的生成数据的提取方法流程示意图。
图7为本发明实施例中提供的A服务器与B服务器会话场景示意图之一。
图8为本发明实施例中提供的A服务器与B服务器会话场景示意图之二。
图9为本发明实施例中提供的A服务器与B服务器会话场景示意图之三。
图10为本发明实施例中提供的A服务器与B服务器会话场景示意图之四。
图11为本发明实施例中提供的A服务器与B服务器会话场景示意图之五。
图12为本发明实施例中提供的A服务器与B服务器会话场景示意图之六。
图13为本发明实施例中提供的A服务器与B服务器会话场景示意图之七。
图14为本发明实施例中提供的A服务器与B服务器会话场景示意图之八。
图15为本发明实施例中提供的A服务器与B服务器会话场景示意图之九。
图16为本发明实施例中提供的A服务器与B服务器会话场景示意图之十。
图17为本发明实施例中提供的A服务器与B服务器会话场景示意图之十一。
图18为本发明实施例中提供的A服务器与B服务器会话场景示意图之十二。
图19为本发明实施例中提供的一种回归测试或者压力测试的生成数据的提取装置的结构示意图。
图20为本发明实施例中提供的TCP封包报文的示意图。
图21为适用于实现本发明中的回归测试或者压力测试的生成数据的提取方法的计算机设备结构示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
下面参考本发明的若干代表性实施方式,详细阐释本发明的原理和精神。
虽然本发明提供了如下述实施例或附图所示的方法操作步骤或装置结构,但基于常规或者无需创造性的劳动在所述方法或装置中可以包括更多或者更少的操作步骤或模块单元。在逻辑性上不存在必要因果关系的步骤或结构中,这些步骤的执行顺序或装置的模块结构不限于本发明实施例或附图所示的执行顺序或模块结构。所述的方法或模块结构的在实际中的装置或终端产品应用时,可以按照实施例或者附图所示的方法或模块结构进行顺序执行或者并行执行。
需要说明的是,本发明可以用于信息安全技术领域,当然也可以用于其他技术领域,本发明对此不做限定。
图6示出了本发明实施例中一种回归测试或者压力测试的生成数据的提取方法,包括:
S1:对回归测试或者压力测试产生的数据进行抓包,得到多个封包文件;所述回归测试或者压力测试数据产生的数据包括终端与交互***进行至少一次会话产生的应用层数据;
S2:解析每个封包文件,得到所有会话对应的应用层数据包;
S3:基于会话协议的交互信息确定每个会话各自对应的应用层数据包,进而得到每个会话对应的应用层数据。
本发明提供的一种回归测试或者压力测试的生成数据的提取方法,通过对待提取数据进行抓包,得到多个封包文件;然后解析每个封包文件,得到解析的数据以及多个标志位上的参数;最后结合所述多个标志位从解析得到的数据中提取每个会话对应的应用层数据。相较于提取单个封包文件,避免了Wireshark一次加载大文件引起的内存溢出,同时可以通过标志位来锚定每个会话的起始和终点,保证每个会话应用层数据的完整性,可以提取出完整的应用层数据,避免因TCP层被分片导致不完整的问题。
在一些实施例中,所述交互信息包括:每个应用层数据包的包序号、确认包序号和封包类型,以及双方交互的地址信息;
所述步骤S3具体包括:
S31:根据每个应用层数据包的封包类型以及包序号、确认包序号确定单次会话的起始应用层数据包和终点应用层数据包,以及
S32:结合每个应用层数据包的抓包序号和封包类型,以及双方交互的地址信息、包序号和确认包序号,根据每个所述起始应用层数据包和所述终点应用层数据包,确定每个会话对应的所有应用层数据包,其中,每个会话对应的所有应用层数据包中的数据按照所述抓包序号的大小排序形成所述应用层数据。
进一步的,步骤S3还包括:
S33:根据每个应用层数据包的封包类型确定对应交互双方的端口状态;
S34:所述结合每个应用层数据包的抓包序号和封包类型,以及双方交互的地址信息、包序号和确认包序号,根据每个所述起始应用层数据包和所述终点应用层数据包,确定每个会话对应的所有应用层数据包,包括:
S35:结合每个应用层数据包的抓包序号和端口状态,以及双方交互的地址信息、包序号和确认包序号,根据每个所述起始应用层数据包和所述终点应用层数据包,确定每个会话对应的所有应用层数据包及对应的应用层数据包顺序。
与现有技术不同的是,现有技术直接加载对数据进行抓包形成的单个封包文件,当文件过大时会导致本发明背景技术记载的问题,本发明采用多个封包结合标志位锚定每个对话的方式,提取出完整对话的应用层数据,而且多个封包文件避免了内存处理的负担,同时可以多线程处理封包,提高了处理效率。
进一步的,在一些实施例中,本发明的步骤S3具体还包括:
S36:根据每个应用层数据包的会话标志位上的特征值确定应用层数据包的封包类型;
具体而言,可以通过封包中的标志位,区分封包类型,TCP报文头格式如图20所示,其中URG、ACK、PSH、RST、SYN、FIN为标志位,用于区分报文类型。其具体含义为:
URG:紧急标志。该标志很少使用,由发送方设置,若设置则说明16位紧急指针有效。紧急指针用于标记紧急数据在数据中的偏移。紧急数据可以和正常数据放在同一个TCP报文,也可以分开放置。在Java语言紧急数据长度只支持1字节。发送方侧TCP会优先投递设置URG的报文。在Java语言接收方侧TCP会把URG报文和非URG报文一起交付到应用层,应用层无法区分URG报文和非URG报文数据。URG标志和ACK一起使用。
ACK:确认标志:接收方收到发送方的报文后,发送给发送方的确认报文。
PSH:推送标志:表示接收方在收到该报文后应尽快将这个报文交付给应用层,而不是在缓冲区等待。
RST:重置标志:用于重置由于主机崩溃或其他原因出现错误的连接,或者用于拒绝非法的报文段和拒绝连接请求。
SYN:同步标志:用于建立连接的三次握手的前两次。
FIN:结束标志:用于关闭连接的第一和第三次挥手。
S32:根据每个封包的类型、每个封包类型下会话对应的双方地址、双方端口及双方端口状态,提取每个会话对应的应用层数据。
此外,在步骤S32中,可以根据不同类型的封包以及每个会话对应的双方地址、双方端口及双方端口状态,提取出每个会话对应的应用层数据。
在一些具体实施例中,封包类型按照TCP标志位分为SYN、SYN+ACK、ACK、PSH+ACK、RST+ACK、URG+ACK、FIN+ACK。
在一些实施例中,所述会话标志位包括:SEQ标志位、LEN标志位、ACK标志位;所述特征值包括0和1。
针对每种封包类型,其对应的处理方式不同,例如所述封包类型包括:SYN、SYN+ACK、ACK、PSH+ACK、RST+ACK、FIN+ACK以及URG+ACK;
所述根据每个应用层数据包的封包类型确定对应交互双方的端口状态,包括:
若封包类型为SYN的应用层数据包,确定源端口状态为SYN_SENT;目的端口状态为空;
对于封包类型为SYN+ACK的应用层数据包,确定源端口状态为SYN_SENT,目的端口状态为SYN_RECV;
对于封包类型为ACK的应用层数据包,确定源端口状态为ESTABLISHED,目的端口状态为SYN_RECV;
对于封包类型为ACK的应用层数据包,区分该封包类型为ACK的应用层数据包的会话状态为携带数据、三次握手的第3次、四次挥手第2次、四次挥手第4次交互中的一个,若所述会话状态为三次握手的第3次,则确定源端口状态为ESTABLISHED,若所述会话状态为四次挥手第2次,则确定源端口状态为CLOSE_WAIT,若四次挥手第4次,则确定源端口状态为TIME_WAIT,目的端口状态为SYN_RECV;
对于封包类型为PSH+ACK的应用层数据包,确定交互双方端口为ESTABLISHED;
对于封包类型为FIN+ACK,区分该封包类型为ACK的应用层数据包的会话状态为四次挥手的第1次或者第3次交互,若为四次挥手的第1次,则源端口状态确定为FIN_WIAT1;若是四次挥手第2次,则源端口状态确定为LAST_ACK。
下面逐一说明每个封包的处理方式:
“SYN”包处理步骤如下(对应图1的步骤01):
该类包是三次握手的第1次,捕获到该类包说明源端口状态已变成SYN_SENT。在第一表格新建记录,记录源地址到A地址、目的地址到B地址、源端口到A端口、目的端口到B端口、包序号到A包序号,记录A端口状态=SYN_SENT,A包序号加数=1。
如图7所示,当前封包是一个从A服务器(地址:192.168.1.1,端口10000)发送到B服务器(地址:192.168.1.2,端口10001)的SYN包,则说明A服务器的10000端口状态已变成SYN_SENT,则可在第一表格新建记录(加粗字段为变更字段):
表1-第一表格更新记录表之一
“SYN+ACK”包处理步骤如下(对应图1的步骤02):
该类包是三次握手的第2次,捕获该类包说明源端口状态已变成SYN_RECV。
[对应图2步骤101]在第一表格按A地址=目的地址、B地址=源地址、A端口=目的端口、B端口=源端口、A端口状态=SYN_SENT的查找记录,若存在则检验报文中确认序号是否等于A包序号+A包序号加数,若是则更新B端口状态=SYN_RECV,B包序号=包序号,B->A确认包序号=确认序号,B包序号加数=1。
如图8所示,当前封包是一个从B服务器(地址:192.168.1.2,端口10001)发送到A服务器(地址:192.168.1.1,端口10000)的SYN+ACK包,则说明B服务器的10001端口状态已变成SYN_RECV。此时第一表格中对应记录的A包序号=0,A包序号加数=1,报文中的ACK=1,符合A包序号+A包序号加数=ACK序号。更新第一表格记录为(加粗字段为变更字段):
表2-第一表格更新记录表之二
“ACK”包处理步骤如下(对应图1的步骤06):
捕获到该类包,需区分携带数据、三次握手的第3次、四次挥手第2次、四次挥手第4次交互。若是三次握手的第3次,则说明源端口状态已变为ESTABLISHED;若是四次挥手第2次,则说明源端口状态已变为CLOSE_WAIT;若是四次挥手第4次,则说明源端口状态已变成TIME_WAIT。这三种情况均需设置第一表格对应记录的源端口状态。
步骤1[对应图3步骤301]:若封包上层数据长度不为0,处理步骤同PSH+ACK。
步骤2[对应图3步骤302]:若步骤1不符合,则在第一表格查找A地址=源地址、B地址=目的地址、A端口=源端口、B端口=目的端口、A端口状态=SYN_SENT、B端口状态=SYN_RECV的记录,若记录存在则说明是三次握手的第3次。校验报文中确认序号是否等于B包序号+B包序号加数,若是则更新A端口状态=ESTABLISHED,A包序号=包序号,A->B确认包序号=确认包序号。记A包序号加数=0。
如图9所示,当前封包是一个从A服务器(地址:192.168.1.1,端口10000)发送到B服务器(地址:192.168.1.2,端口10001)的ACK包,不携带数据,则说明A服务器的10000端口状态已变成ESTABLISHED。此时第一表格中对应记录的B包序号=0,B包序号加数=1,报文中的ACK=1,符合B包序号+B包序号加数=ACK序号。更新第一表格记录为(加粗字段为变更字段):
表3-第一表格更新记录表之三
步骤3:若步骤2无记录,则在第一表格查找A地址=[目的地址,源地址]、B地址=[源地址,目的地址]、A端口=[目的端口,源端口]、B端口=[源端口,目的端口]的记录。
步骤4[对应图3步骤303]:若A端口状态=[ESTABLISHED,FIN_WAIT1]、B端口状态为[FIN_WAIT1,ESTABLISHED]的记录,则说明该封包是四次挥手的第2次。按照报文中的源IP和源端口,设置第一表格中对应的端口状态为CLOSE_WAIT。
如图10所示,当前封包是一个从A服务器(地址:192.168.1.1,端口10000)发送到B服务器(地址:192.168.1.2,端口10001)的ACK包,不携带数据,且第一表格对应记录A端口状态=ESTABLISHED,B端口状态=IN_WAIT1,说明A服务器的10000端口状态已变成CLOSE_WAIT,该封包是四次挥手的第2次。对应第一表格记录更新为(加粗字段为变更字段):
表4-第一表格更新记录表之四
步骤5[对应图3步骤304]:若A端口状态=[LAST_ACK,FIN_WAIT2]、B端口状态为[FIN_WAIT2,LAST_ACK],则说明该封包是四次挥手的第4次。按照报文中的源IP和源端口,设置第一表格中对应的端口状态为TIME_WAIT。
如图11所示,当前封包是一个从B服务器(地址:192.168.1.2,端口10001)发送到A服务器(地址:192.168.1.1,端口10000)的ACK包,不携带数据,且第一表格对应记录A端口状态=LAST_ACK,B端口状态=FIN_WAIT2,说明B服务器的10001端口状态已变成TIME_WAIT,该封包是四次挥手的第4次。更新第一表格记录为(加粗字段为变更字段):
表5-第一表格更新记录表之五
步骤6:若端口状态不是步骤4和步骤5的状态,则说明该包是普通应答包,应丢弃。如图12所示,当前封包是一个从B服务器(地址:192.168.1.2,端口10001)发送到A服务器(地址:192.168.1.1,端口10000)的ACK包,不携带数据,且第一表格对应记录双方端口状态均为ESTABLISHED,则该封包为普通应答包,不记到表中。
“PSH+ACK”包处理步骤如下(对应图1的步骤05):
该类包是数据传输包,捕获到该类包,说明双方端口已变为ESTABLISHED状态,需设置被动方端口状态,并需合并TCP分组、处理重传包和错误包。
步骤1[对应图4步骤401]:在第一表格按A地址=[目的地址,源地址]、B地址=[源地址,目的地址]、A端口=[目的端口,源端口]、B端口=[源端口,目的端口]、A端口状态=[ESTABLISHED,SYN_RECV,ESTABLISHED]、B端口状态=[SYN_RECV,ESTABLISHED,ESTABLISHED]的记录。若存在记录且若其中一方端口状态为SYN_RECV,则更新其状态=ESTABLISHED。
如图13所示,当前封包是一个从A服务器(地址:192.168.1.1,端口10000)发送到B服务器(地址:192.168.1.2,端口10001)的PSH+ACK包。则可以认为A和B之间的三次握手已完成。B服务器的10001端口状态也变成ESTABLISHED。更新第一表格记录为(加粗字段为变更字段):
表6-第一表格更新记录表之六
步骤2[对应图4步骤402]:按照RFC 793定义的校验算法校验报文中的校验和。若校验不过则为错误数据,应丢弃。若校验通过,则判断校验和是否在第二表格已存在,若存在则说明是重传数据,应丢弃;若不存在,则判断第一表格记录的当前数据传输方向,若值为空,则说明是首次传输的请求报文,登记类型=请求,当前报文传输方向=A->B(源地址是A)或B->A(源地址是B),并把报文中的包序号、上层数据、校验和登记到第二表格;若当前数据传输方向与第一表格记录的当前传输方向相同,则说明是TCP分片数据,继续把报文中的包序号、上层数据、校验和登记到第二表格。
举例而言,对于步骤1举例的封包,第一表格对应记录中B包序号=0,B包序号加数=1,报文中ACK=1,符合B包序号+B包序号加数=ACK。源地址为A,目的地址为B,第一表格对应记录的当前数据传输方向为空,更新第一表格记录为(加粗字段为变更字段):
表7-第一表格更新后的记录表之七
在第二表格新增记录为(加粗字段为变更字段):
表8-第二表格更新记录表之一
ID(FK) | 包序号(PK) | 上层数据长度 | 上层数据 | 校验和 |
1 | 1 | 7 | http:// | 16位校验和 |
若再收到2个PSH+ACK封包如下,其中第2个封包在第1个封包之前从A服务器发出,但因网络原因到达B服务器时出现乱序,如图14:
则第一表格记录保持不变,第二表格新增记录(加粗字段为变更字段):
表9-第二表格更新记录表之二
ID(FK) | 包序号(PK) | 上层数据长度 | 上层数据 | 校验和 |
1 | 1 | 7 | http:// | 16位校验和 |
1 | 12 | 10 | soopat.com | 16位校验和 |
1 | 8 | 4 | www. | 16位校验和 |
步骤3[对应图4步骤403]:若当前数据传输方向与第一表格记录的当前传输方向不同,则把第二表格与当前TCP会话对应的记录,按包序号排序,校验上一条记录的包序号+上层数据长度是否等于下一条记录的包序号。若第一表格记录的传输方向是A->B,则更新第一表格的A包序号=第二表格对应ID最后一条记录的包序号,A包序号加数=第二表格对应ID最后一条记录的上层数据长度,B->A确认包序号=A包序号+A包序号加数。把第二表格上层数据拼接在一起,作为请求/应答数据,记录到第三表格,并把数据从第二表格删除。同时把本次封包的包序号、上层数据、校验和登记到第二表格。同样地,若源地址是A,则设置第一表格的A包序号加数=数据字节数;否则若源地址是B,则设置第一表格的B包序号加数=数据字节数。
举例而言:如图15,当前封包是一个从B服务器(地址:192.168.1.2,端口10001)发送到A服务器(地址:192.168.1.1,端口10000)的PSH+ACK包,因和第一表格对应记录的传输方向不同,则对第二表格对应记录按包序号排序(加粗字段为变更字段):
表10-第二表格更新记录表之三
ID(FK) | 包序号(PK) | 上层数据长度 | 上层数据 | 校验和 |
1 | 1 | 7 | http:// | 16位校验和 |
1 | 8 | 4 | www. | 16位校验和 |
1 | 12 | 10 | soopat.com | 16位校验和 |
校验第1条记录的包序号+上层数据长度=8,等于第2条记录的包序号;第2条记录的包序号+上层数据长度=12,等于第3条记录的包序号。
第一表格记录更新为(加粗字段为变更字段):
表11-第一表格更新记录表之八
第二表格相同ID记录清除,并在第二表格新增记录(加粗字段为变更字段):
表12-第二表格更新记录表之四
ID(FK) | 包序号(PK) | 上层数据长度 | 上层数据 | 校验和 |
1 | 1 | 11 | <p>hello</p> | 16位校验和 |
第三表格新增记录(加粗字段为变更字段):
表13-第三表格更新记录表之一
ID(FK) | 操作序号(PK) | 类型 | 上层数据 |
1 | 1 | 请求 | <u>http://www.soopat.com</u> |
“RST+ACK”包处理步骤如下(对应图1的步骤03):
该类包是重置包,捕获到该类包,说明TCP会话重置,应丢弃对应会话的所有数据。在第一表格按照A地址=[目的地址,源地址]、B地址=[源地址,目的地址]、A端口=[目的端口,源端口]、B端口=[源端口,目的端口]查找记录,若存在则删除记录,并关联删除第二表格和第三表格记录。
举例而言,如图16,因A服务端进程异常,收到B服务器应答后,A服务器返回一个RST+ACK封包,则认为通讯已重置,删除第一表格、第二表格、第三表格对应记录。
“URG+ACK”包处理步骤如下(对应图1的步骤07):
该类包是紧急包,该类型包至少携带1字节紧急数据,处理方法同ACK的步骤1(即携带数据的ACK包)。
“FIN+ACK”包处理步骤如下(对应图1的步骤04):
该类包是TCP会话关闭包,捕获该类包,需要区分是四次挥手的第1次还是第3次交互。若是四次挥手的第1次,则说明源端口状态已变为FIN_WIAT1;若是四次挥手第2次,则说明源端口状态已变成LAST_ACK。上述两种情况均需设置主动方端口状态。
步骤1:在第一表格查找A地址=[目的地址,源地址]、B地址=[源地址,目的地址]、A端口=[目的端口,源端口]、B端口=[源端口,目的端口]的记录。
步骤2[对应图5步骤501]:若A端口状态=ESTABLISHED且B端口状态=ESTABLISHED,说明该包为四次挥手的第1次。若第二表格存在ID相同的记录,则同样需要把第二表格数据包序号排序后,合并到第三表格,并删除第二表格对应记录。若源端口是B,则检验报文中的确认序号是否等于A包序号+A包序号加数,若是则设置B端口状态=FIN_WAIT1,B包序号=包序号,B->A确认包序号=确认序号,B包序号加数=1;若原端口是A,则同样方式设置。
举例而言,如图17,当前封包是一个从B服务器(地址:192.168.1.2,端口10001)发送到A服务器(地址:192.168.1.1,端口10000)的FIN+ACK包,且第一表格对应记录的状态双方端口状态均为ESTABLISHED,则说明B服务器的端口状态已变成FIN_WAIT1。
第二表格对应记录按数据包序号排序合并(加粗字段为变更字段):
表14-第二表格更新记录表之五
ID(FK) | 包序号(PK) | 上层数据长度 | 上层数据 | 校验和 |
1 | 1 | 11 | <p>hello</p> | 16位校验和 |
第三表格新增记录(加粗字段为变更字段):
表15-第三表格更新记录表之二
ID(FK) | 操作序号(PK) | 类型 | 上层数据 |
1 | 1 | 请求 | <u>http://www.soopat.com</u> |
1 | 2 | 应答 | <p>hello</p> |
同时删除第二表格对应记录。
第一表格记录更新为(加粗字段为变更字段):
表16-第一表格更新记录表之八
步骤3[对应图5步骤502]:若A端口状态=[FIN_WAIT1,CLOSE_WAIT],B端口状态=[CLOSE_WAIT,FIN_WAIT1],若能查到说明该包为四次挥手第3次,各字段设置方式同四次挥手的第1次,区别是设置源端口状态=LAST_ACK,目的端口状态=FIN_WAIT2。
举例而言,如图18,当前封包是一个从A服务器(地址:192.168.1.1,端口10000)发送到B服务器(地址:192.168.1.2,端口10001)的FIN+ACK包,对应第一表格记录的A端口状态=CLOSE_WAIT,B端口状态=FIN_WAIT1,则说明该封包是四次挥手的第3次,更新第一表格记录为(加粗字段为变更字段):
表17-第一表格更新记录表之九
1.收尾处理:
1.1.因封包分析中设置的端口状态均为封包源端口状态,故捕获四次挥手第4次交互ACK
包后,目的端口状态尚未设置为CLOSED,需补设置:
对第一表格中端口对状态是TIME_WAIT、LAST_ACK的状态做补处理,把上述状态均置为CLOSED。
1.2.因封包捕获可能在TCP会话关闭前停止,因此捕获的TCP会话不完整,这些会话无
法从中提取完整应用层数据,应丢弃:
对第一表格中双方端口状态不是CLOSED的所有记录,关联清除第一表格、第二表格、第三表格数据。
举例而言,收到四次挥手的第4次ACK包后,第一表格记录中的端口状态应更新为(加粗字段为变更字段):
表18-第一表格更新记录表之十
2.应用层数据变形成测试数据:
最终第三表格为还原出的生产应用层数据。可使用变形程序,对其中涉及用户信息的敏感字段做变形处理,以便应用于测试环境。此处不再赘述。
举例而言,最终得到第三表格的记录,为每个TCP会话交互的应用层数据:
表19-第三表格更新记录表之五
ID(FK) | 操作序号(PK) | 类型 | 上层数据 |
1 | 1 | 请求 | <u>http://www.soopat.com</u> |
1 | 2 | 应答 | <p>hello</p> |
从上述实施例可以知晓,本发明提供的回归测试或者压力测试的生成数据的提取方法,将封包数据存放到数据库,按照TCP协议,可从TCP分片提取出完整应用层数据,同时避免Wireshark一次加载大文件引起的内存溢出。
基于相同的发明构思,本发明实施例还提供一种回归测试或者压力测试的生成数据的提取装置,如图19所示,包括:
抓包模块1,对回归测试或者压力测试产生的数据进行抓包,得到多个封包文件;所述回归测试或者压力测试数据产生的数据包括终端与交互***进行至少一次会话产生的应用层数据;
解析模块2,解析每个封包文件,得到所有会话对应的应用层数据包;
应用层数据确定模块3,基于会话协议的交互信息确定每个会话各自对应的应用层数据包,进而得到每个会话对应的应用层数据。
本发明提供的一种回归测试或者压力测试的生成数据的提取装置,通过对待提取数据进行抓包,得到多个封包文件;然后解析每个封包文件,得到解析的数据以及多个标志位上的参数;最后结合所述多个标志位从解析得到的数据中提取每个会话对应的应用层数据。相较于提取单个封包文件,避免了Wireshark一次加载大文件引起的内存溢出,同时可以通过标志位来锚定每个会话的起始和终点,保证每个会话应用层数据的完整性,可以提取出完整的应用层数据,避免因TCP层被分片导致不完整的问题。
在优选的实施例中,所述提取模块,包括:
类型确定单元,根据每个会话的标志位判断每个封包的类型;
应用层数据提取单元,根据每个封包的类型、每个封包类型下会话对应的双方地址、双方端口及双方端口状态,提取每个会话对应的应用层数据。
在优选的实施例中,所述抓包模块通过TcpDump抓包工具对待提取数据进行抓包。
在优选的实施例中,所述解析模块通过Wireshark解析每个封包文件。
从硬件层面来说,为了本发明提供一种用于实现所述回归测试或者压力测试的生成数据的提取方法中的全部或部分内容的电子设备的实施例,所述电子设备具体包含有如下内容:
处理器(processor)、存储器(memory)、通信接口(Communications Interface)和总线;其中,所述处理器、存储器、通信接口通过所述总线完成相互间的通信;所述通信接口用于实现服务器、装置、分布式消息中间件集群装置、各类数据库以及用户终端等相关设备之间的信息传输;该电子设备可以是台式计算机、平板电脑及移动终端等,本实施例不限于此。在本实施例中,该电子设备可以参照实施例中的回归测试或者压力测试的生成数据的提取方法的实施例,以及,回归测试或者压力测试的生成数据的提取方法装置的实施例进行实施,其内容被合并于此,重复之处不再赘述。
图21为本发明实施例的电子设备9600的***构成的示意框图。如图21所示,该电子设备9600可以包括中央处理器9100和存储器9140;存储器9140耦合到中央处理器9100。值得注意的是,该图21是示例性的;还可以使用其他类型的结构,来补充或代替该结构,以实现电信功能或其他功能。
一实施例中,回归测试或者压力测试的生成数据的提取方法功能可以被集成到中央处理器9100中。
在另一个实施方式中,回归测试或者压力测试的生成数据的提取方法装置可以与中央处理器9100分开配置,例如可以将回归测试或者压力测试的生成数据的提取方法配置为与中央处理器9100连接的芯片,通过中央处理器的控制来实现回归测试或者压力测试的生成数据的提取方法功能。
如图21所示,该电子设备9600还可以包括:通信模块9110、输入单元9120、音频处理器9130、显示器9160、电源9170。值得注意的是,电子设备9600也并不是必须要包括图21中所示的所有部件;此外,电子设备9600还可以包括图21中没有示出的部件,可以参考现有技术。
如图21所示,中央处理器9100有时也称为控制器或操作控件,可以包括微处理器或其他处理器装置和/或逻辑装置,该中央处理器9100接收输入并控制电子设备9600的各个部件的操作。
其中,存储器9140,例如可以是缓存器、闪存、硬驱、可移动介质、易失性存储器、非易失性存储器或其它合适装置中的一种或更多种。可储存上述与失败有关的信息,此外还可存储执行有关信息的程序。并且中央处理器9100可执行该存储器9140存储的该程序,以实现信息存储或处理等。
输入单元9120向中央处理器9100提供输入。该输入单元9120例如为按键或触摸输入装置。电源9170用于向电子设备9600提供电力。显示器9160用于进行图像和文字等显示对象的显示。该显示器例如可为LCD显示器,但并不限于此。
该存储器9140可以是固态存储器,例如,只读存储器(ROM)、随机存取存储器(RAM)、SIM卡等。还可以是这样的存储器,其即使在断电时也保存信息,可被选择性地擦除且设有更多数据,该存储器的示例有时被称为EPROM等。存储器9140还可以是某种其它类型的装置。存储器9140包括缓冲存储器9141(有时被称为缓冲器)。存储器9140可以包括应用/功能存储部9142,该应用/功能存储部9142用于存储应用程序和功能程序或用于通过中央处理器9100执行电子设备9600的操作的流程。
存储器9140还可以包括数据存储部9143,该数据存储部9143用于存储数据,例如联系人、数字数据、图片、声音和/或任何其他由电子设备使用的数据。存储器9140的驱动程序存储部9144可以包括电子设备的用于通信功能和/或用于执行电子设备的其他功能(如消息传送应用、通讯录应用等)的各种驱动程序。
通信模块9110即为经由天线9111发送和接收信号的发送机/接收机9110。通信模块(发送机/接收机)9110耦合到中央处理器9100,以提供输入信号和接收输出信号,这可以和常规移动通信终端的情况相同。
基于不同的通信技术,在同一电子设备中,可以设置有多个通信模块9110,如蜂窝网络模块、蓝牙模块和/或无线局域网模块等。通信模块(发送机/接收机)9110还经由音频处理器9130耦合到扬声器9131和麦克风9132,以经由扬声器9131提供音频输出,并接收来自麦克风9132的音频输入,从而实现通常的电信功能。音频处理器9130可以包括任何合适的缓冲器、解码器、放大器等。另外,音频处理器9130还耦合到中央处理器9100,从而使得可以通过麦克风9132能够在本机上录音,且使得可以通过扬声器9131来播放本机上存储的声音。
本领域内的技术人员应明白,本发明的实施例可提供为方法、装置、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(装置)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。
Claims (10)
1.一种回归测试或者压力测试的生成数据的提取方法,其特征在于,包括:
对回归测试或者压力测试产生的数据进行抓包,得到多个封包文件;所述回归测试或者压力测试数据产生的数据包括终端与交互***进行至少一次会话产生的应用层数据;
解析每个封包文件,得到所有会话对应的应用层数据包;
基于会话协议的交互信息确定每个会话各自对应的应用层数据包,进而得到每个会话对应的应用层数据。
2.如权利要求1所述的提取方法,其特征在于,所述交互信息包括:每个应用层数据包的包序号、确认包序号和封包类型,以及双方交互的地址信息;
所述基于会话协议的交互信息确定每个会话各自对应的应用层数据包,包括:
根据每个应用层数据包的封包类型以及包序号、确认包序号确定单次会话的起始应用层数据包和终点应用层数据包,以及
结合每个应用层数据包的抓包序号和封包类型,以及双方交互的地址信息、包序号和确认包序号,根据每个所述起始应用层数据包和所述终点应用层数据包,确定每个会话对应的所有应用层数据包,其中,每个会话对应的所有应用层数据包中的数据按照所述抓包序号的大小排序形成所述应用层数据。
3.如权利要求2所述的提取方法,其特征在于,所述基于会话协议的交互信息确定每个会话各自对应的应用层数据包,还包括:
根据每个应用层数据包的封包类型确定对应交互双方的端口状态;
所述结合每个应用层数据包的抓包序号和封包类型,以及双方交互的地址信息、包序号和确认包序号,根据每个所述起始应用层数据包和所述终点应用层数据包,确定每个会话对应的所有应用层数据包,包括:
结合每个应用层数据包的抓包序号和端口状态,以及双方交互的地址信息、包序号和确认包序号,根据每个所述起始应用层数据包和所述终点应用层数据包,确定每个会话对应的所有应用层数据包及对应的应用层数据包顺序。
4.如权利要求2或3所述的提取方法,其特征在于,所述基于会话协议的交互信息确定每个会话各自对应的应用层数据包,还包括:
根据每个应用层数据包的会话标志位上的特征值确定应用层数据包的封包类型。
5.如权利要求4所述的提取方法,其特征在于,所述会话标志位包括:SEQ标志位、LEN标志位、ACK标志位;所述特征值包括0和1。
6.如权利要求5所述的提取方法,其特征在于,所述封包类型包括:SYN、SYN+ACK、ACK、PSH+ACK、RST+ACK、FIN+ACK以及URG+ACK;
所述根据每个应用层数据包的封包类型确定对应交互双方的端口状态,包括:
若封包类型为SYN的应用层数据包,确定源端口状态为SYN_SENT;目的端口状态为空;
对于封包类型为SYN+ACK的应用层数据包,确定源端口状态为SYN_SENT,目的端口状态为SYN_RECV;
对于封包类型为ACK的应用层数据包,确定源端口状态为ESTABLISHED,目的端口状态为SYN_RECV;
对于封包类型为ACK的应用层数据包,区分该封包类型为ACK的应用层数据包的会话状态为携带数据、三次握手的第3次、四次挥手第2次、四次挥手第4次交互中的一个,若所述会话状态为三次握手的第3次,则确定源端口状态为ESTABLISHED,若所述会话状态为四次挥手第2次,则确定源端口状态为CLOSE_WAIT,若四次挥手第4次,则确定源端口状态为TIME_WAIT,目的端口状态为SYN_RECV;
对于封包类型为PSH+ACK的应用层数据包,确定交互双方端口为ESTABLISHED;
对于封包类型为FIN+ACK,区分该封包类型为ACK的应用层数据包的会话状态为四次挥手的第1次或者第3次交互,若为四次挥手的第1次,则源端口状态确定为FIN_WIAT1;若是四次挥手第2次,则源端口状态确定为LAST_ACK。
7.如权利要求5所述的提取方法,其特征在于,还包括:若在单次会话中存在一封包类型为RST+ACK的应用层数据包,丢弃对应会话的所有应用层数据。
8.一种回归测试或者压力测试的生成数据的提取装置,其特征在于,包括:
抓包模块,对回归测试或者压力测试产生的数据进行抓包,得到多个封包文件;所述回归测试或者压力测试数据产生的数据包括终端与交互***进行至少一次会话产生的应用层数据;
解析模块,解析每个封包文件,得到所有会话对应的应用层数据包;
应用层数据确定模块,基于会话协议的交互信息确定每个会话各自对应的应用层数据包,进而得到每个会话对应的应用层数据。
9.一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其特征在于,所述处理器执行所述计算机程序时实现权利要求1至4任一所述方法。
10.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质存储有执行权利要求1至4任一所述方法的计算机程序。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010821304.XA CN111949542B (zh) | 2020-08-14 | 2020-08-14 | 回归测试或者压力测试的生成数据的提取方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010821304.XA CN111949542B (zh) | 2020-08-14 | 2020-08-14 | 回归测试或者压力测试的生成数据的提取方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111949542A true CN111949542A (zh) | 2020-11-17 |
CN111949542B CN111949542B (zh) | 2023-09-12 |
Family
ID=73343001
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010821304.XA Active CN111949542B (zh) | 2020-08-14 | 2020-08-14 | 回归测试或者压力测试的生成数据的提取方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111949542B (zh) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109995740A (zh) * | 2018-01-02 | 2019-07-09 | 国家电网公司 | 基于深度协议分析的威胁检测方法 |
CN110505111A (zh) * | 2019-07-09 | 2019-11-26 | 杭州电子科技大学 | 基于流量重放的工控协议模糊测试方法 |
CN110839060A (zh) * | 2019-10-16 | 2020-02-25 | 武汉绿色网络信息服务有限责任公司 | 一种DPI场景中http多会话的文件还原方法和装置 |
-
2020
- 2020-08-14 CN CN202010821304.XA patent/CN111949542B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109995740A (zh) * | 2018-01-02 | 2019-07-09 | 国家电网公司 | 基于深度协议分析的威胁检测方法 |
CN110505111A (zh) * | 2019-07-09 | 2019-11-26 | 杭州电子科技大学 | 基于流量重放的工控协议模糊测试方法 |
CN110839060A (zh) * | 2019-10-16 | 2020-02-25 | 武汉绿色网络信息服务有限责任公司 | 一种DPI场景中http多会话的文件还原方法和装置 |
Also Published As
Publication number | Publication date |
---|---|
CN111949542B (zh) | 2023-09-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP7029471B2 (ja) | アップリンクデータ解凍、圧縮方法および装置 | |
US9015822B2 (en) | Automatic invocation of DTN bundle protocol | |
CN103647869B (zh) | 一种终端的配对方法、终端及*** | |
US8761197B2 (en) | Method and apparatus for mode transition, compression, and decompression in robust header compression | |
CN108234084A (zh) | 一种数据的收发方法、装置及设备 | |
US20070233892A1 (en) | System and method for performing information detection | |
CN111064755B (zh) | 一种数据保护方法、装置、计算机设备和存储介质 | |
CN109922049B (zh) | 基于区块链的验证装置及方法 | |
CN112838966A (zh) | 一种udp链路监控方法、***及电子设备 | |
CN103227777B (zh) | 一种防止dpd探测失败导致ipsec隧道震荡的方法 | |
EP3235210A1 (en) | Methods and first network node for managing a stream control transmission protocol association | |
CN112350850A (zh) | 日志文件的上报方法、装置、存储介质及电子设备 | |
CN113867732A (zh) | 一种报文信息处理方法、***以及存储介质 | |
CN107579792B (zh) | 多型号在轨卫星工程参数并行解析方法 | |
WO2021134418A1 (zh) | 一种数据校验方法及装置 | |
CN111949542B (zh) | 回归测试或者压力测试的生成数据的提取方法及装置 | |
CN115604052B (zh) | 车辆通讯交互方法、***及电子设备 | |
CN115348333A (zh) | 基于udp双端通信交互的数据传输方法、***及设备 | |
US20040001490A1 (en) | Method of verifying number of sessions of computer stack | |
CN111654884B (zh) | 一种数据处理方法及相关设备 | |
CN103825683A (zh) | 基于tcp重传机制的内核代理方法及装置 | |
WO2007010593A1 (ja) | Tcpセッションエミュレーション装置 | |
CN114050917A (zh) | 音频数据的处理方法、装置、终端、服务器及存储介质 | |
CN113438083A (zh) | 基于接口自动化测试的加验签方法及装置 | |
CN114979172B (zh) | 数据传输方法、装置、设备以及存储介质 |
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 |