CN111949542A - Method and device for extracting generated data of regression test or pressure test - Google Patents
Method and device for extracting generated data of regression test or pressure test 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
The method and the device for extracting the generated data of the regression test or the pressure test can be used in the technical field of information safety, and a plurality of package files are obtained by capturing the data to be extracted; then analyzing each package file to obtain analyzed data and parameters on a plurality of flag bits; and finally, extracting the application layer data corresponding to each session from the analyzed data by combining the plurality of zone bits. Compared with the method for extracting a single package file, the method avoids memory overflow caused by once loading of a large file by Wireshark, can anchor the start point and the end point of each session through the zone bit, ensures the integrity of application layer data of each session, can extract complete application layer data, and avoids the problem of incompleteness caused by the fact that a TCP layer is fragmented.
Description
Technical Field
The invention relates to the technical field of data extraction, in particular to a method and a device for extracting generated data of a regression test or a pressure test.
Background
This section is intended to provide a background or context to the embodiments of the invention that are recited in the claims. The description herein is not admitted to be prior art by inclusion in this section.
One of the current regression testing/pressure testing data generation methods is to capture a network packet in a production environment by using a Tcpdump and store the network packet into a packet file (single), analyze the packet file by using a Wireshark script (tshark, pyshark, etc.), extract application layer data from a single TCP packet, and use the application layer data as testing data after deformation.
The above method has 3 problems:
first, when the application layer data exceeds the MSS (maximum message size, generally 1460 bytes) of TCP, the application layer data is fragmented at the TCP layer, and the application layer data extracted from a single TCP packet is not necessarily complete data.
Second, for a scenario with a large transaction amount and a long capture time, the number of captured single package files may reach G. The Wireshark script reads the whole packet file into the memory and then analyzes the file, so that the data extraction of the large file is limited by the machine memory; when the file exceeds the memory limit, Wireshark will automatically exit. This problem has been documented in the Wireshark official network (https:// wiki. wirereshark. org/Knownwegs/OutOfmemory), which presents solutions to increasing physical and virtual memory, but these approaches are limited by the hardware and software of the device.
Third, the second problem can be addressed by limiting the size of the single package file captured by Tcpdump, but there is a similar problem to the first one: if there is a TCP segment, different segments of the same TCP session may exist in different packet files, and the extracted application layer data is still not necessarily complete data.
Disclosure of Invention
In order to solve at least one of the above problems, embodiments of the present invention provide a method and an apparatus for extracting generated data in a regression test or a pressure test, where data is captured and packaged into a plurality of small packaged files, and then extraction of application layer data is implemented by using a flag bit, so that complete application layer data can be extracted and obtained.
In one aspect of the present invention, a method for extracting data generated by a regression test or a stress test includes:
capturing packets of data generated by regression testing or pressure testing to obtain a plurality of packet files; the data generated by the regression test or the pressure test data comprises application layer data generated by at least one session between the terminal and the interactive system;
analyzing each packet file to obtain application layer data packets corresponding to all sessions;
and determining the application layer data packet corresponding to each session based on the interactive information of the session protocol, thereby obtaining the application layer data corresponding to each session.
In some embodiments, the interaction information comprises: the packet sequence number, the confirmation packet sequence number and the packet type of each application layer data packet, and address information of interaction of the two parties;
the determining of the application layer packet corresponding to each session based on the session protocol interaction information includes:
determining a starting application layer data packet and a destination application layer data packet of a single session according to the packet type, the packet sequence number and the acknowledgement packet sequence number of each application layer data packet, and
and determining all application layer data packets corresponding to each session according to the starting application layer data packet and the end application layer data packet by combining the packet capturing sequence number and the packet type of each application layer data packet and the address information, the packet sequence number and the confirmation packet sequence number interacted between the two parties, wherein the data in all the application layer data packets corresponding to each session are sequenced according to the size of the packet capturing sequence number to form the application layer data.
In some embodiments, the determining, based on the interaction information of the session protocol, application layer packets corresponding to each session further includes:
determining the port states of the two corresponding interactive parties according to the packet type of each application layer data packet;
determining all application layer data packets corresponding to each session according to each starting application layer data packet and each ending application layer data packet by combining the packet capturing sequence number and the packet type of each application layer data packet and address information, packet sequence number and confirmation packet sequence number interacted between the two parties, wherein the determining comprises the following steps:
and determining all application layer data packets corresponding to each session and the corresponding sequence of the application layer data packets according to each starting application layer data packet and each ending application layer data packet by combining the packet capturing sequence number and the port state of each application layer data packet and the address information, the packet sequence number and the confirmation packet sequence number interacted between the two parties.
In some embodiments, the determining, based on the interaction information of the session protocol, application layer packets corresponding to each session further includes:
and determining the packet type of each application layer packet according to the characteristic value on the session flag bit of each application layer packet.
In some embodiments, the session flag includes: SEQ flag bit, LEN flag bit and ACK flag bit; the characteristic values include 0 and 1.
In some embodiments, the packet types include: SYN, SYN + ACK, PSH + ACK, RST + ACK, FIN + ACK, and URG + ACK;
the determining the port states of the two corresponding interaction parties according to the packet type of each application layer packet includes:
if the packet type is an application layer packet of SYN, determining that the state of the source port is SYN _ SENT; the destination port state is null;
for an application layer data packet with a packet type of SYN + ACK, determining that the state of a source port is SYN _ SENT and the state of a destination port is SYN _ RECV;
for an application layer data packet with the packet type of ACK, determining that the source port state is ESTABLISHED and the destination port state is SYN _ RECV;
for an application layer packet with an ACK packet type, distinguishing that the session state of the application layer packet with the ACK packet type is one of interaction of carrying data, 3 rd TIME of three-way handshake, 2 nd TIME of four-way waving and 4 th TIME of four-way waving, if the session state is 3 rd TIME of three-way handshake, determining that the source port state is ESTABLISHED, if the session state is 2 nd TIME of four-way waving, determining that the source port state is CLOSE _ WAIT, and if the session state is 4 th TIME of four-way waving, determining that the source port state is TIME _ WAIT and the destination port state is SYN _ RECV;
for an application layer data packet with a packet type of PSH + ACK, determining that the ports of the two interactive parties are ESTABLISHED;
for the packet type of FIN + ACK, distinguishing that the session state of the application layer packet with the packet type of ACK is the 1 st or 3 rd interaction of four handlings, if the session state is the 1 st of the four handlings, determining the source port state as FIN _ WIAT 1; if it is 2 nd waving of hands four times, the source port status is determined to be LAST _ ACK.
In certain embodiments, further comprising: if an application layer data packet with the packet type RST + ACK exists in a single session, all the application layer data packets of the corresponding session are discarded.
Another aspect of the present invention provides an apparatus for extracting data generated by a regression test or a stress test, including:
the packet capturing module is used for capturing packets of data to be extracted to obtain a plurality of packet files; the data to be extracted comprises application layer data generated by at least one session between the terminal and the interactive system;
the analysis module analyzes each package file to obtain analyzed data and a plurality of zone bits, wherein the zone bits correspond to each package type one to one;
and the extraction module is used for extracting the application layer data corresponding to each session from the analyzed data by combining the plurality of zone bits.
In a preferred embodiment, the extraction module includes:
the type determining unit judges the type of each packet according to the flag bit of each session;
and the application layer data extraction unit extracts the application layer data corresponding to each session according to the type of each packet, the addresses of the two parties corresponding to the session under each packet type, the ports of the two parties and the states of the ports of the two parties.
In a preferred embodiment, the packet capture module captures the data to be extracted through a TcpLock capture tool.
In a preferred embodiment, the parsing module parses each package file through Wireshark.
A further aspect of the present invention provides a computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the method of any one of the first aspect when executing the computer program.
In a further aspect, the present invention provides a computer readable storage medium storing a computer program for executing the method of any one of the first aspect.
The invention has the following beneficial effects:
in summary, according to the method and the device for extracting generated data of the regression test or the pressure test provided by the present invention, a plurality of packet files are obtained by performing packet capturing on the data to be extracted; then analyzing each package file to obtain analyzed data and parameters on a plurality of flag bits; and finally, extracting the application layer data corresponding to each session from the analyzed data by combining the plurality of zone bits. Compared with the method for extracting a single package file, the method avoids memory overflow caused by once loading of a large file by Wireshark, can anchor the start point and the end point of each session through the zone bit, ensures the integrity of application layer data of each session, can extract complete application layer data, and avoids the problem of incompleteness caused by the fact that a TCP layer is fragmented.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts. In the drawings:
fig. 1 is a schematic diagram of various packet processing steps provided in the embodiment of the present invention.
Fig. 2 is a diagram illustrating a SYN + ACK packet processing procedure according to an embodiment of the invention.
Fig. 3 is a diagram illustrating an ACK packet processing procedure according to an embodiment of the invention.
Fig. 4 is a diagram illustrating a PSH + ACK packet processing procedure according to an embodiment of the invention.
Fig. 5 is a schematic diagram illustrating a FIN + ACK packet processing procedure according to an embodiment of the invention.
Fig. 6 is a schematic flow chart of a method for extracting generated data of a regression test or a pressure test according to an embodiment of the present invention.
Fig. 7 is one of session scenarios of a server a and a server B provided in the embodiment of the present invention.
Fig. 8 is a second schematic view of a session scenario between the server a and the server B according to the embodiment of the present invention.
Fig. 9 is a third schematic view of a session scenario between a server a and a server B according to the embodiment of the present invention.
Fig. 10 is a fourth schematic view of a session scenario between a server a and a server B according to an embodiment of the present invention.
Fig. 11 is a fifth schematic view of a session scenario between a server a and a server B according to an embodiment of the present invention.
Fig. 12 is a sixth schematic view of a session scenario between the server a and the server B according to an embodiment of the present invention.
Fig. 13 is a seventh schematic view of a session scenario between a server a and a server B according to an embodiment of the present invention.
Fig. 14 is an eighth schematic view of a session scenario between a server a and a server B according to an embodiment of the present invention.
Fig. 15 is a ninth view illustrating a session scenario between a server a and a server B according to an embodiment of the present invention.
Fig. 16 is a ten-fold schematic view of a session scenario between a server a and a server B according to an embodiment of the present invention.
Fig. 17 is an eleventh schematic view illustrating a session scenario between a server a and a server B according to an embodiment of the present invention.
Fig. 18 is a twelve schematic views of a session scenario between a server a and a server B according to an embodiment of the present invention.
Fig. 19 is a schematic structural diagram of an apparatus for extracting data generated by a regression test or a pressure test according to an embodiment of the present invention.
Fig. 20 is a schematic diagram of a TCP packet message according to an embodiment of the present invention.
Fig. 21 is a schematic diagram of a computer device suitable for implementing the method for extracting the generated data of the regression test or the stress test in the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and the described embodiments are only a part of the embodiments of the present invention, but not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
The principles and spirit of the present invention are explained in detail below with reference to several representative embodiments of the invention.
Although the present invention provides the method operation steps or apparatus structures as shown in the following embodiments or figures, more or less operation steps or module units may be included in the method or apparatus based on conventional or non-inventive labor. In the case of steps or structures which do not logically have the necessary cause and effect relationship, the execution order of the steps or the block structure of the apparatus is not limited to the execution order or the block structure shown in the embodiment or the drawings of the present invention. The described methods or modular structures, when applied in an actual device or end product, may be executed sequentially or in parallel according to embodiments or the methods or modular structures shown in the figures.
It should be noted that the present invention may be used in the technical field of information security, and may also be used in other technical fields, and the present invention is not limited thereto.
Fig. 6 shows an extraction method of generated data of a regression test or a stress test in an embodiment of the present invention, including:
s1: capturing packets of data generated by regression testing or pressure testing to obtain a plurality of packet files; the data generated by the regression test or the pressure test data comprises application layer data generated by at least one session between the terminal and the interactive system;
s2: analyzing each packet file to obtain application layer data packets corresponding to all sessions;
s3: and determining the application layer data packet corresponding to each session based on the interactive information of the session protocol, thereby obtaining the application layer data corresponding to each session.
The invention provides a regression test or pressure test generated data extraction method, which comprises the steps of carrying out packet capturing on data to be extracted to obtain a plurality of packet files; then analyzing each package file to obtain analyzed data and parameters on a plurality of flag bits; and finally, extracting the application layer data corresponding to each session from the analyzed data by combining the plurality of zone bits. Compared with the method for extracting a single package file, the method avoids memory overflow caused by once loading of a large file by Wireshark, can anchor the start point and the end point of each session through the zone bit, ensures the integrity of application layer data of each session, can extract complete application layer data, and avoids the problem of incompleteness caused by the fact that a TCP layer is fragmented.
In some embodiments, the interaction information comprises: the packet sequence number, the confirmation packet sequence number and the packet type of each application layer data packet, and address information of interaction of the two parties;
the step S3 specifically includes:
s31: determining a starting application layer data packet and a destination application layer data packet of a single session according to the packet type, the packet sequence number and the acknowledgement packet sequence number of each application layer data packet, and
s32: and determining all application layer data packets corresponding to each session according to the starting application layer data packet and the end application layer data packet by combining the packet capturing sequence number and the packet type of each application layer data packet and the address information, the packet sequence number and the confirmation packet sequence number interacted between the two parties, wherein the data in all the application layer data packets corresponding to each session are sequenced according to the size of the packet capturing sequence number to form the application layer data.
Further, step S3 further includes:
s33: determining the port states of the two corresponding interactive parties according to the packet type of each application layer data packet;
s34: determining all application layer data packets corresponding to each session according to each starting application layer data packet and each ending application layer data packet by combining the packet capturing sequence number and the packet type of each application layer data packet and address information, packet sequence number and confirmation packet sequence number interacted between the two parties, wherein the determining comprises the following steps:
s35: and determining all application layer data packets corresponding to each session and the corresponding sequence of the application layer data packets according to each starting application layer data packet and each ending application layer data packet by combining the packet capturing sequence number and the port state of each application layer data packet and the address information, the packet sequence number and the confirmation packet sequence number interacted between the two parties.
Different from the prior art, the prior art directly loads a single packet file formed by packet capturing of data, and the problem recorded by the background art of the invention can be caused when the file is too large.
Further, in some embodiments, step S3 of the present invention specifically includes:
s36: determining the packet type of each application layer data packet according to the characteristic value on the session zone bit of each application layer data packet;
specifically, the packet types can be distinguished by flag bits in the packet, and the format of the TCP header is shown in fig. 20, where URG, ACK, PSH, RST, SYN, and FIN are flag bits used for distinguishing the packet types. The specific meanings are as follows:
URG: and (4) emergency signs. The flag is rarely used and is set by the sender, which indicates that the 16-bit urgent pointer is valid. The urgent pointer is used to mark an offset of urgent data in the data. The emergency data can be placed in the same TCP message with the normal data or can be placed separately. Only 1 byte is supported in the Java language urgent data length. The TCP at the sender side preferentially delivers the message with the URG. TCP on the Java language receiver side delivers the URG message and the non-URG message to an application layer, and the application layer cannot distinguish the data of the URG message from the data of the non-URG message. The URG flag is used with ACK.
And ACK: a confirmation flag: and after receiving the message of the sender, the receiver sends the message to the confirmation message of the sender.
PSH: pushing a mark: indicating that the receiver should deliver the message to the application layer as soon as possible after receiving the message, rather than waiting in a buffer.
RST: resetting the flag: for resetting connections that have errors due to a host crash or other reason, or for rejecting illegal segments and rejecting connection requests.
SYN: synchronization flag: the first two of the three-way handshakes used to establish the connection.
FIN: end mark: first and third swings to close the connection.
S32: and extracting the application layer data corresponding to each session according to the type of each packet, the addresses of the two parties corresponding to the session under each packet type, the ports of the two parties and the states of the ports of the two parties.
In step S32, the application layer data corresponding to each session may be extracted based on the packets of different types and the addresses, ports, and port states corresponding to each session.
In some embodiments, the packet types are classified by TCP flag bits into SYN, SYN + ACK, PSH + ACK, RST + ACK, URG + ACK, FIN + ACK.
In some embodiments, the session flag includes: SEQ flag bit, LEN flag bit and ACK flag bit; the characteristic values include 0 and 1.
For each packet type, the corresponding processing method is different, for example, the packet type includes: SYN, SYN + ACK, PSH + ACK, RST + ACK, FIN + ACK, and URG + ACK;
the determining the port states of the two corresponding interaction parties according to the packet type of each application layer packet includes:
if the packet type is an application layer packet of SYN, determining that the state of the source port is SYN _ SENT; the destination port state is null;
for an application layer data packet with a packet type of SYN + ACK, determining that the state of a source port is SYN _ SENT and the state of a destination port is SYN _ RECV;
for an application layer data packet with the packet type of ACK, determining that the source port state is ESTABLISHED and the destination port state is SYN _ RECV;
for an application layer packet with an ACK packet type, distinguishing that the session state of the application layer packet with the ACK packet type is one of interaction of carrying data, 3 rd TIME of three-way handshake, 2 nd TIME of four-way waving and 4 th TIME of four-way waving, if the session state is 3 rd TIME of three-way handshake, determining that the source port state is ESTABLISHED, if the session state is 2 nd TIME of four-way waving, determining that the source port state is CLOSE _ WAIT, and if the session state is 4 th TIME of four-way waving, determining that the source port state is TIME _ WAIT and the destination port state is SYN _ RECV;
for an application layer data packet with a packet type of PSH + ACK, determining that the ports of the two interactive parties are ESTABLISHED;
for the packet type of FIN + ACK, distinguishing that the session state of the application layer packet with the packet type of ACK is the 1 st or 3 rd interaction of four handlings, if the session state is the 1 st of the four handlings, determining the source port state as FIN _ WIAT 1; if it is 2 nd waving of hands four times, the source port status is determined to be LAST _ ACK.
The following describes the processing of each packet one by one:
the "SYN" packet processing steps are as follows (corresponding to step 01 of fig. 1):
this type of packet is the 1 st of a three-way handshake, capturing this type of packet indicates that the source port state has become SYN _ SENT. And newly creating a record in the first table, recording a source address to an address A, a destination address to an address B, a source port to an port A, a destination port to a port B, and a packet sequence number to an A packet sequence number, recording the state of the port A as SYN _ SENT, and recording the number of the added port A as 1.
As shown in fig. 7, if the current packet is a SYN packet SENT from the a server (address: 192.168.1.1, port 10000) to the B server (address: 192.168.1.2, port 10001), it indicates that the 10000 port status of the a server has become SYN _ send, and a record can be created in the first table (bold field is change field):
TABLE 1-first Table updates one of the record tables
The "SYN + ACK" packet processing steps are as follows (corresponding to step 02 of fig. 1):
this type of packet is the 2 nd of a three-way handshake, capturing this type of packet indicates that the source port state has become SYN RECV.
Corresponding to step 101 in fig. 2, in the first table, according to the lookup record of the a address being the destination address, the B address being the source address, the a port being the destination port, the B port being the source port, and the a port state being SYN _ SENT, if there is, it is checked whether the acknowledgment sequence number in the message is equal to the a packet sequence number + the a packet sequence number, if yes, the B port state is updated to SYN _ RECV, the B packet sequence number being the packet sequence number, B- > a acknowledgment packet sequence number being the acknowledgment sequence number, and the B packet sequence number being 1.
As shown in fig. 8, the current packet is a SYN + ACK packet sent from the B server (address: 192.168.1.2, port 10001) to the a server (address: 192.168.1.1, port 10000), which indicates that the port status of 10001 of the B server has become SYN RECV. At this time, the a packet number recorded in the first table is 0, the addend of the a packet number is 1, the ACK in the message is 1, and the a packet number + the addend of the a packet number is ACK. Update the first table record as (bold field is change field):
TABLE 2 first Table update record Table two
The "ACK" packet processing steps are as follows (corresponding to step 06 of fig. 1):
capturing the packet needs to distinguish the 3 rd, 2 nd and 4 th hand-waving interactions of the 3 rd and four hand-waving interactions carrying data and three-way handshake. If the handshake is 3 rd time of the three times, the state of the source port is changed into ESTABLISHED; if the hand waving takes 2 nd time for four times, the state of the source port is changed into CLOSE _ WAIT; if the source port is swung four TIMEs 4 th TIME, it indicates that the source port status has changed to TIME _ WAIT. In all three cases, the source port state recorded in the first table needs to be set.
Step 1[ corresponding to step 301 of FIG. 3 ]: if the data length of the upper layer of the packet is not 0, the processing steps are the same as PSH + ACK.
Step 2[ corresponding to step 302 of FIG. 3 ]: if step 1 does not match, the first table is searched for records of a address being the source address, a address being the destination address, a port being the source port, a port being the destination port, a port state being SYN _ SENT, and a port state being SYN _ RECV, and if the records exist, the 3 rd time of the three-way handshake is indicated. Checking whether the sequence number in the message is equal to the sum of the sequence number of the B packet and the sequence number of the B packet, if so, updating the state of the A port to be equal to the ESTABLISHED, the sequence number of the A packet to be equal to the sequence number of the A packet, and the sequence number of the A- > B acknowledgement packet to be equal to the sequence number of the acknowledgement packet. And recording the number of the A packet as 0.
As shown in FIG. 9, the current packet is an ACK packet sent from the A server (address: 192.168.1.1, port 10000) to the B server (address: 192.168.1.2, port 10001), and does not carry data, which indicates that the 10000 port status of the A server has become ESTABLISHED. At this time, the corresponding record in the first table has a B packet sequence number of 0, an addend of the B packet sequence number of 1, an ACK in the message of 1, and a B packet sequence number + B packet sequence number of ACK. Update the first table record as (bold field is change field):
TABLE 3 first Table update record table III
And step 3: if no record is found in step 2, the first table is searched for records with a ═ destination address, source address, B-address ═ source address, destination address, a ═ destination port, source port, and B ═ source port, destination port.
Step 4[ corresponding to step 303 of FIG. 3 ]: if the record with the a port status of [ ESTABLISHED _ WAIT1] and the B port status of [ ESTABLISHED _ WAIT1, ESTABLISHED ], the packet is the 2 nd of the four hand swings. And setting the corresponding port state in the first table as CLOSE _ WAIT according to the source IP and the source port in the message.
As shown IN fig. 10, the current packet is an ACK packet sent from the a server (address: 192.168.1.1, port 10000) to the B server (address: 192.168.1.2, port 10001), which does not carry data, and the first table records the a port status ═ ESTABLISHED and the B port status ═ IN _ WAIT1, which indicates that the 10000 port status of the a server has become CLOSE _ WAIT, and the packet is 2 nd time of four hands waving. The corresponding first table record is updated to (bold field is change field):
TABLE 4 first Table update record Table IV
Step 5[ corresponding to step 304 of FIG. 3 ]: if the a port status is [ LAST _ ACK, FIN _ WAIT2] and the B port status is [ FIN _ WAIT2, LAST _ ACK ], the packet is the 4 th time of the four swing. And setting the corresponding port state in the first table as TIME _ WAIT according to the source IP and the source port in the message.
As shown in fig. 11, the current packet is an ACK packet sent from the B server (address: 192.168.1.2, port 10001) to the a server (address: 192.168.1.1, port 10000), which does not carry data, and the first table records the port state of a _ ACK and the port state of B _ WAIT2, which indicates that the port state of 10001 of the B server has changed to TIME _ WAIT, and the packet is the 4 th TIME of four hands waving. Update the first table record as (bold field is change field):
TABLE 5 first Table update record Table five
Step 6: if the port state is not the state of step 4 or step 5, it indicates that the packet is a normal response packet and should be discarded. As shown in fig. 12, the current packet is an ACK packet sent from the B server (address: 192.168.1.2, port 10001) to the a server (address: 192.168.1.1, port 10000), and does not carry data, and the first table correspondingly records that the port statuses of both sides are ESTABLISHED, so that the packet is a normal response packet and is not recorded in the table.
The "PSH + ACK" packet processing procedure is as follows (corresponding to step 05 of fig. 1):
the packet is a data transmission packet, and the packet is captured to indicate that the ports of the two parties have changed into the ESTABLISHED state, the state of the port of the passive party needs to be set, and a TCP packet needs to be combined, and a retransmission packet and an error packet need to be processed.
Step 1[ corresponding to step 401 of FIG. 4 ]: in the first table, the record is recorded according to a [ destination address, source address ], B address, destination address ], a port, destination port, B port, source port, destination port, a port state, and B port state. If there is a record and if one of the port states is SYN _ RECV, its state is updated to ESTABLISHED.
As shown in FIG. 13, the current packet is a PSH + ACK packet sent from the A server (address: 192.168.1.1, port 10000) to the B server (address: 192.168.1.2, port 10001). Then it can be assumed that three handshakes between a and B have been completed. The 10001 port state of the B-server also becomes ESTABLISHED. Update the first table record as (bold field is change field):
TABLE 6 sixth Table for updating the record table
Step 2[ corresponding to step 402 of FIG. 4 ]: the checksum in the message is checked according to the checking algorithm defined in RFC 793. If the data is not verified, the data is error data and should be discarded. If the check is passed, judging whether the check sum exists in the second table, if so, indicating that the data is retransmitted and should be discarded; if the current data transmission direction is not the same as the first data transmission direction, judging the current data transmission direction recorded in the first table, if the value is null, indicating that the current data transmission direction is the first-time transmission request message, and registering the type of the registration is the request, and the current message transmission direction is A- > B (the source address is A) or B- > A (the source address is B), and registering the packet sequence number, the upper layer data and the checksum in the message to the second table; if the current data transmission direction is the same as the current transmission direction recorded in the first table, the data is the TCP fragment data, and the packet sequence number, the upper layer data and the checksum in the message are continuously registered in the second table.
For example, for the packet exemplified in step 1, the first table corresponds to the record where the sequence number of the B packet is 0, the addend of the sequence number of the B packet is 1, the packet ACK is 1, and the sequence number of the B packet + the addend of the sequence number of the B packet is ACK. The source address is A, the destination address is B, the current data transmission direction of the record corresponding to the first table is null, and the record of the first table is updated to be (the bold field is a change field):
TABLE 7 seventh Table of the first Table updated record Table
Newly adding records in the second table as (the bold field is a change field):
TABLE 8-second Table updates one of the record tables
ID(FK) | Bag number (PK) | Upper layer data length | Upper | Checksum | |
1 | 1 | 7 | http:// | 16 bit checksum |
If 2 PSH + ACK packets are received again, wherein the 2 nd packet is sent from the a server before the 1 st packet, but occurs out of order when arriving at the B server due to network reasons, as shown in fig. 14:
the record of the first table is kept unchanged, and the newly added record (the bold field is the change field) of the second table:
TABLE 9 second Table update record Table two
ID(FK) | Bag number (PK) | Upper layer data length | Upper | Checksum | |
1 | 1 | 7 | http:// | 16 bit checksum | |
1 | 12 | 10 | soopat.com | 16 |
|
1 | 8 | 4 | www. | 16 bit checksum |
Step 3[ corresponding to step 403 in FIG. 4 ]: if the current data transmission direction is different from the current transmission direction recorded by the first table, sorting the records corresponding to the second table and the current TCP session according to the packet sequence numbers, and checking whether the packet sequence number of the previous record plus the length of the upper layer data is equal to the packet sequence number of the next record. If the transmission direction recorded by the first table is a- > B, updating the sequence number of the packet a in the first table to be the sequence number of the last record of the corresponding ID in the second table, the addend of the sequence number of the packet a to be the length of the upper layer data recorded by the last record of the corresponding ID in the second table, and confirming that the sequence number of the packet B to be a sequence number of the packet a + the sequence number of the packet a. And splicing the upper layer data of the second table together to be used as request/response data, recording the request/response data into a third table, and deleting the data from the second table. And simultaneously registering the packet sequence number, the upper layer data and the checksum of the packet to a second table. Similarly, if the source address is a, setting the addend of the packet sequence number a of the first table to be the number of data bytes; otherwise, if the source address is B, setting the B packet sequence number in the first table as the number of data bytes.
For example: as shown in fig. 15, the current packet is a PSH + ACK packet sent from the B server (address: 192.168.1.2, port 10001) to the a server (address: 192.168.1.1, port 10000), and since the transmission direction of the record corresponding to the first table is different, the records corresponding to the second table are sorted by packet sequence number (the bold field is the change field):
TABLE 10-second Table update record table III
ID(FK) | Bag number (PK) | Upper layer data length | Upper | Checksum | |
1 | 1 | 7 | http:// | 16 |
|
1 | 8 | 4 | www. | 16 bit checksum | |
1 | 12 | 10 | soopat.com | 16 bit checksum |
Checking that the packet sequence number + the upper layer data length of the 1 st record is 8 and is equal to the packet sequence number of the 2 nd record; the packet sequence number + upper layer data length of the 2 nd record is 12, which is equal to the packet sequence number of the 3 rd record.
The first table record is updated to (bold field is change field):
TABLE 11-first Table updates eight of the record tables
And (3) clearing the same ID records in the second table, and adding new records in the second table (the thickened field is a change field):
TABLE 12-fourth of the second table update record table
ID(FK) | Bag number (PK) | Upper layer data length | Upper | Checksum | |
1 | 1 | 11 | <p>hello</p> | 16 bit checksum |
Newly adding a record to the third table (the bold field is a change field):
table 13-one of the third table update record tables
ID(FK) | Operating number (PK) | Type (B) | |
1 | 1 | Request for | http://www.soopat.com |
The "RST + ACK" packet processing steps are as follows (corresponding to step 03 of fig. 1):
the packet is a reset packet, and the packet is captured, which indicates that the TCP session is reset, and all data of the corresponding session should be discarded. And searching records in the first table according to the A address ═ destination address, source address, B address ═ source address, destination address, A port ═ destination port, source port and B port ═ source port and destination port, deleting the records if the records exist, and associating and deleting the second table and the third table records.
For example, as shown in fig. 16, due to the abnormal process of the a server, after receiving the response from the B server, the a server returns an RST + ACK packet, and then the communication is considered to be reset, and the corresponding records of the first table, the second table, and the third table are deleted.
The "URG + ACK" packet processing procedure is as follows (corresponding to step 07 of fig. 1):
the type packet is an emergency packet, the type packet carries at least 1 byte of emergency data, and the processing method is the same as that in step 1 of the ACK (namely, the ACK packet carrying the data).
The "FIN + ACK" packet processing steps are as follows (corresponding to step 04 of fig. 1):
this type of packet is a TCP session close packet, and capturing this type of packet requires distinguishing between the 1 st and 3 rd interactions of four wave motions. If the swing is 1 st of the four swings, the state of the source port is changed to FIN _ WIAT 1; if swing 2 nd time four times, it indicates that the source port status has become LAST _ ACK. Both of these situations require setting the master port state.
Step 1: the first table is searched for records of a ═ destination address, source address, B address ═ source address, destination address, a ═ destination port, source port, and B port ═ source port, destination port.
Step 2[ corresponding to step 501 of FIG. 5 ]: if the a port state is ESTABLISHED and the B port state is ESTABLISHED, the packet is identified as 1 st of the four hand swings. If the second table has records with the same ID, the data packet sequence numbers of the second table are also required to be sequenced, merged into a third table, and the record corresponding to the second table is deleted. If the source port is B, checking whether the confirmation sequence number in the message is equal to the addend of the A packet sequence number and the A packet sequence number, if so, setting the state of the B port as FIN _ WAIT1, the B packet sequence number as a packet sequence number, B- > A confirmation packet sequence number as a confirmation sequence number, and the addend of the B packet sequence number as 1; if the original port is a, the same is set.
For example, as shown in FIG. 17, the current packet is a FIN + ACK packet sent from the B server (address: 192.168.1.2, port 10001) to the A server (address: 192.168.1.1, port 10000), and the port status of both sides is the ESTABLISHED, which is recorded in the first table, indicating that the port status of the B server has become FIN _ WAIT 1.
The corresponding records of the second table are sorted and merged according to the sequence number of the data packet (the bold field is a change field):
TABLE 14-fifth of the second Table update record Table
ID(FK) | Bag number (PK) | Upper layer data length | Upper | Checksum | |
1 | 1 | 11 | <p>hello</p> | 16 bit checksum |
Newly adding a record to the third table (the bold field is a change field):
table 15-second table of third table update record
ID(FK) | Operating number (PK) | Type (B) | |
1 | 1 | Request for | http://www.soopat.com |
1 | 2 | Answering | <p>hello</p> |
And simultaneously deleting the corresponding record of the second table.
The first table record is updated to (bold field is change field):
TABLE 16-first Table updates eight of the record tables
Step 3[ corresponding to step 502 of FIG. 5 ]: if the a port state is [ FIN _ WAIT1, CLOSE _ WAIT ], the B port state is [ CLOSE _ WAIT, FIN _ WAIT1], and if the 3 rd time of the four swing of the packet can be found, the setting of each field is the 1 st time of the four swings, the difference is that the source port state is set as LAST _ ACK, and the destination port state is set as FIN _ WAIT 2.
For example, as shown in fig. 18, the current packet is a FIN + ACK packet sent from the a server (address: 192.168.1.1, port 10000) to the B server (address: 192.168.1.2, port 10001), and the a port state of the corresponding first table record is CLOSE _ WAIT and the B port state is FIN _ WAIT1, which indicates that the packet is 3 rd time of four hands waving, and the first table record is updated (the bold field is the change field):
TABLE 17-nine of the first table update record table
1. And (4) ending treatment:
1.1. since the port states set in the packet analysis are all the packet source port states, the 4 th interactive ACK of the four waving hands is captured
After the packet, the state of the destination port is not set to be CLOSED, and needs to be set in a complementary way:
and (4) performing complementary processing on the states of the port pair in the first table, wherein the states are TIME _ WAIT and LAST _ ACK, and setting the states to be CLOSED.
1.2. Since packet capture may stop before the TCP session closes, the captured TCP session is incomplete and none of these sessions
The method extracts complete application layer data from the data, and discards the data:
and for all records of which the states of the two ports in the first table are not CLOSED, the first table, the second table and the third table are cleared in an associated mode.
For example, after receiving the 4 th ACK packet of four hands waving, the port status in the first table record should be updated to (bold field is change field):
table 18-first table updating record table ten
2. Transforming the application layer data into test data:
the final third table is the reduced production application layer data. Sensitive fields in which user information is involved may be morphed using a morphing program for application to a test environment. And will not be described in detail herein.
For example, a record of a third table is finally obtained, for each TCP session interaction application layer data:
table 19-fifth table of the third table update record table
ID(FK) | Operating number (PK) | Type (B) | |
1 | 1 | Request for | http://www.soopat.com |
1 | 2 | Answering | <p>hello</p> |
It can be known from the above embodiments that the method for extracting generated data in a regression test or a pressure test provided by the present invention stores packet data in a database, and according to a TCP protocol, can extract complete application layer data from a TCP segment, and simultaneously avoid memory overflow caused by once loading a large file by Wireshark.
Based on the same inventive concept, an embodiment of the present invention further provides an apparatus for extracting generated data of a regression test or a pressure test, as shown in fig. 19, including:
the packet capturing module 1 is used for capturing packets of data generated by regression testing or pressure testing to obtain a plurality of packet files; the data generated by the regression test or the pressure test data comprises application layer data generated by at least one session between the terminal and the interactive system;
the analysis module 2 analyzes each packet file to obtain application layer data packets corresponding to all sessions;
and the application layer data determining module 3 determines the application layer data packet corresponding to each session based on the interactive information of the session protocol, so as to obtain the application layer data corresponding to each session.
The invention provides a regression test or pressure test generated data extraction device, which is used for obtaining a plurality of package files by capturing packages of data to be extracted; then analyzing each package file to obtain analyzed data and parameters on a plurality of flag bits; and finally, extracting the application layer data corresponding to each session from the analyzed data by combining the plurality of zone bits. Compared with the method for extracting a single package file, the method avoids memory overflow caused by once loading of a large file by Wireshark, can anchor the start point and the end point of each session through the zone bit, ensures the integrity of application layer data of each session, can extract complete application layer data, and avoids the problem of incompleteness caused by the fact that a TCP layer is fragmented.
In a preferred embodiment, the extraction module includes:
the type determining unit judges the type of each packet according to the flag bit of each session;
and the application layer data extraction unit extracts the application layer data corresponding to each session according to the type of each packet, the addresses of the two parties corresponding to the session under each packet type, the ports of the two parties and the states of the ports of the two parties.
In a preferred embodiment, the packet capture module captures the data to be extracted through a TcpLock capture tool.
In a preferred embodiment, the parsing module parses each package file through Wireshark.
From a hardware level, for the embodiment of the electronic device for implementing all or part of the content in the method for extracting the generated data of the regression test or the stress test, the electronic device specifically includes the following contents:
a processor (processor), a memory (memory), a communication Interface (Communications Interface), and a bus; the processor, the memory and the communication interface complete mutual communication through the bus; the communication interface is used for realizing information transmission among related equipment such as a server, a device, a distributed message middleware cluster device, various databases, a user terminal and the like; the electronic device may be a desktop computer, a tablet computer, a mobile terminal, and the like, but the embodiment is not limited thereto. In this embodiment, the electronic device may refer to an embodiment of a method for extracting generated data of a regression test or a pressure test and an embodiment of a device for extracting generated data of a regression test or a pressure test in the embodiments, and the contents thereof are incorporated herein, and repeated details are not repeated.
Fig. 21 is a schematic block diagram of a system configuration of an electronic device 9600 according to an embodiment of the present invention. As shown in fig. 21, the electronic device 9600 can include a central processor 9100 and a memory 9140; the memory 9140 is coupled to the central processor 9100. Notably, this fig. 21 is exemplary; other types of structures may also be used in addition to or in place of the structure to implement telecommunications or other functions.
In one embodiment, the functions of the regression test or the pressure test for the extraction method of the generated data may be integrated into the central processor 9100.
In another embodiment, the device for extracting the generated data of the regression test or the stress test may be configured separately from the central processor 9100, for example, the device may be configured as a chip connected to the central processor 9100, and the function of the method for extracting the generated data of the regression test or the stress test is realized by the control of the central processor.
As shown in fig. 21, the electronic device 9600 may further include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is noted that the electronic device 9600 also does not necessarily include all of the components shown in fig. 21; in addition, the electronic device 9600 may further include components not shown in fig. 21, which can be referred to in the related art.
As shown in fig. 21, a central processor 9100, sometimes referred to as a controller or operational control, can include a microprocessor or other processor device and/or logic device, which central processor 9100 receives input and controls the operation of the various components of the electronic device 9600.
The memory 9140 can be, for example, one or more of a buffer, a flash memory, a hard drive, a removable media, a volatile memory, a non-volatile memory, or other suitable device. The information relating to the failure may be stored, and a program for executing the information may be stored. And the central processing unit 9100 can execute the program stored in the memory 9140 to realize information storage or processing, or the like.
The input unit 9120 provides input to the central processor 9100. The input unit 9120 is, for example, a key or a touch input device. Power supply 9170 is used to provide power to electronic device 9600. The display 9160 is used for displaying display objects such as images and characters. The display may be, for example, an LCD display, but is not limited thereto.
The memory 9140 can be a solid state memory, e.g., Read Only Memory (ROM), Random Access Memory (RAM), a SIM card, or the like. There may also be a memory that holds information even when power is off, can be selectively erased, and is provided with more data, an example of which is sometimes called an EPROM or the like. The memory 9140 could also be some other type of device. Memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 may include an application/function storage portion 9142, the application/function storage portion 9142 being used for storing application programs and function programs or for executing a flow of operations of the electronic device 9600 by the central processor 9100.
The memory 9140 can also include a data store 9143, the data store 9143 being used to store data, such as contacts, digital data, pictures, sounds, and/or any other data used by an electronic device. The driver storage portion 9144 of the memory 9140 may include various drivers for the electronic device for communication functions and/or for performing other functions of the electronic device (e.g., messaging applications, contact book applications, etc.).
The communication module 9110 is a transmitter/receiver 9110 that transmits and receives signals via an antenna 9111. The communication module (transmitter/receiver) 9110 is coupled to the central processor 9100 to provide input signals and receive output signals, which may be the same as in the case of a conventional mobile communication terminal.
Based on different communication technologies, a plurality of communication modules 9110, such as a cellular network module, a bluetooth module, and/or a wireless local area network module, may be provided in the same electronic device. The communication module (transmitter/receiver) 9110 is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130 to provide audio output via the speaker 9131 and receive audio input from the microphone 9132, thereby implementing ordinary telecommunications functions. The audio processor 9130 may include any suitable buffers, decoders, amplifiers and so forth. In addition, the audio processor 9130 is also coupled to the central processor 9100, thereby enabling recording locally through the microphone 9132 and enabling locally stored sounds to be played through the speaker 9131.
As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, apparatus, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (devices), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
The principle and the implementation mode of the invention are explained by applying specific embodiments in the invention, and the description of the embodiments is only used for helping to understand the method and the core idea of the invention; meanwhile, for a person skilled in the art, according to the idea of the present invention, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present invention.
Claims (10)
1. A method for extracting data generated by a regression test or a stress test, comprising:
capturing packets of data generated by regression testing or pressure testing to obtain a plurality of packet files; the data generated by the regression test or the pressure test data comprises application layer data generated by at least one session between the terminal and the interactive system;
analyzing each packet file to obtain application layer data packets corresponding to all sessions;
and determining the application layer data packet corresponding to each session based on the interactive information of the session protocol, thereby obtaining the application layer data corresponding to each session.
2. The extraction method of claim 1, wherein the interaction information comprises: the packet sequence number, the confirmation packet sequence number and the packet type of each application layer data packet, and address information of interaction of the two parties;
the determining of the application layer packet corresponding to each session based on the session protocol interaction information includes:
determining a starting application layer data packet and a destination application layer data packet of a single session according to the packet type, the packet sequence number and the acknowledgement packet sequence number of each application layer data packet, and
and determining all application layer data packets corresponding to each session according to the starting application layer data packet and the end application layer data packet by combining the packet capturing sequence number and the packet type of each application layer data packet and the address information, the packet sequence number and the confirmation packet sequence number interacted between the two parties, wherein the data in all the application layer data packets corresponding to each session are sequenced according to the size of the packet capturing sequence number to form the application layer data.
3. The extraction method according to claim 2, wherein the session protocol-based interaction information determines the application layer packet corresponding to each session, and further comprises:
determining the port states of the two corresponding interactive parties according to the packet type of each application layer data packet;
determining all application layer data packets corresponding to each session according to each starting application layer data packet and each ending application layer data packet by combining the packet capturing sequence number and the packet type of each application layer data packet and address information, packet sequence number and confirmation packet sequence number interacted between the two parties, wherein the determining comprises the following steps:
and determining all application layer data packets corresponding to each session and the corresponding sequence of the application layer data packets according to each starting application layer data packet and each ending application layer data packet by combining the packet capturing sequence number and the port state of each application layer data packet and the address information, the packet sequence number and the confirmation packet sequence number interacted between the two parties.
4. The extraction method according to claim 2 or 3, wherein the determining of the application layer packet corresponding to each session based on the session protocol interaction information further comprises:
and determining the packet type of each application layer packet according to the characteristic value on the session flag bit of each application layer packet.
5. The extraction method of claim 4, wherein the session flag comprises: SEQ flag bit, LEN flag bit and ACK flag bit; the characteristic values include 0 and 1.
6. The extraction method of claim 5, wherein the packet type comprises: SYN, SYN + ACK, PSH + ACK, RST + ACK, FIN + ACK, and URG + ACK;
the determining the port states of the two corresponding interaction parties according to the packet type of each application layer packet includes:
if the packet type is an application layer packet of SYN, determining that the state of the source port is SYN _ SENT; the destination port state is null;
for an application layer data packet with a packet type of SYN + ACK, determining that the state of a source port is SYN _ SENT and the state of a destination port is SYN _ RECV;
for an application layer data packet with the packet type of ACK, determining that the source port state is ESTABLISHED and the destination port state is SYN _ RECV;
for an application layer packet with an ACK packet type, distinguishing that the session state of the application layer packet with the ACK packet type is one of interaction of carrying data, 3 rd TIME of three-way handshake, 2 nd TIME of four-way waving and 4 th TIME of four-way waving, if the session state is 3 rd TIME of three-way handshake, determining that the source port state is ESTABLISHED, if the session state is 2 nd TIME of four-way waving, determining that the source port state is CLOSE _ WAIT, and if the session state is 4 th TIME of four-way waving, determining that the source port state is TIME _ WAIT and the destination port state is SYN _ RECV;
for an application layer data packet with a packet type of PSH + ACK, determining that the ports of the two interactive parties are ESTABLISHED;
for the packet type of FIN + ACK, distinguishing that the session state of the application layer packet with the packet type of ACK is the 1 st or 3 rd interaction of four handlings, if the session state is the 1 st of the four handlings, determining the source port state as FIN _ WIAT 1; if it is 2 nd waving of hands four times, the source port status is determined to be LAST _ ACK.
7. The extraction method of claim 5, further comprising: if an application layer data packet with the packet type RST + ACK exists in a single session, all the application layer data packets of the corresponding session are discarded.
8. An apparatus for extracting data generated by a regression test or a stress test, comprising:
the packet capturing module is used for capturing packets of data generated by regression testing or pressure testing to obtain a plurality of packet files; the data generated by the regression test or the pressure test data comprises application layer data generated by at least one session between the terminal and the interactive system;
the analysis module analyzes each packet file to obtain application layer data packets corresponding to all the sessions;
and the application layer data determining module is used for determining the application layer data packet corresponding to each session based on the interactive information of the session protocol so as to obtain the application layer data corresponding to each session.
9. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any one of claims 1 to 4 when executing the computer program.
10. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program for executing the method of any one of claims 1 to 4.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010821304.XA CN111949542B (en) | 2020-08-14 | 2020-08-14 | Extraction method and device for generated data of regression test or pressure test |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010821304.XA CN111949542B (en) | 2020-08-14 | 2020-08-14 | Extraction method and device for generated data of regression test or pressure test |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111949542A true CN111949542A (en) | 2020-11-17 |
CN111949542B CN111949542B (en) | 2023-09-12 |
Family
ID=73343001
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010821304.XA Active CN111949542B (en) | 2020-08-14 | 2020-08-14 | Extraction method and device for generated data of regression test or pressure test |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111949542B (en) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109995740A (en) * | 2018-01-02 | 2019-07-09 | 国家电网公司 | Threat detection method based on depth protocal analysis |
CN110505111A (en) * | 2019-07-09 | 2019-11-26 | 杭州电子科技大学 | The industry control agreement fuzz testing method reset based on flow |
CN110839060A (en) * | 2019-10-16 | 2020-02-25 | 武汉绿色网络信息服务有限责任公司 | HTTP multi-session file restoration method and device in DPI scene |
-
2020
- 2020-08-14 CN CN202010821304.XA patent/CN111949542B/en active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109995740A (en) * | 2018-01-02 | 2019-07-09 | 国家电网公司 | Threat detection method based on depth protocal analysis |
CN110505111A (en) * | 2019-07-09 | 2019-11-26 | 杭州电子科技大学 | The industry control agreement fuzz testing method reset based on flow |
CN110839060A (en) * | 2019-10-16 | 2020-02-25 | 武汉绿色网络信息服务有限责任公司 | HTTP multi-session file restoration method and device in DPI scene |
Also Published As
Publication number | Publication date |
---|---|
CN111949542B (en) | 2023-09-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP7029471B2 (en) | Uplink data decompression, compression method and equipment | |
US11765079B2 (en) | Computational accelerator for storage operations | |
CN103647869B (en) | A kind of matching method of terminal, terminal and system | |
US20100125901A1 (en) | Automatic invocation of dtn bundle protocol | |
CN106330483B (en) | Information acquisition method, client device and server device | |
US8761197B2 (en) | Method and apparatus for mode transition, compression, and decompression in robust header compression | |
CN109257138B (en) | Data transmission control method and related equipment | |
CN111064755B (en) | Data protection method and device, computer equipment and storage medium | |
CN101621437A (en) | A kind of communication system, add load control and method for loading software | |
CN112838966A (en) | UDP link monitoring method and system and electronic equipment | |
CN109922049B (en) | Verification device and method based on block chain | |
CN113867732A (en) | Message information processing method, system and storage medium | |
CN112350850A (en) | Log file reporting method and device, storage medium and electronic equipment | |
CN111385068B (en) | Data transmission method, device, electronic equipment and communication system | |
WO2021134418A1 (en) | Data checking method and apparatus | |
CN114270928A (en) | Abnormity recovery method, abnormity recovery device and mobile terminal | |
CN111949542B (en) | Extraction method and device for generated data of regression test or pressure test | |
CN108460044B (en) | Data processing method and device | |
CN107431965B (en) | Method and device for realizing Transmission Control Protocol (TCP) transmission | |
US20040001490A1 (en) | Method of verifying number of sessions of computer stack | |
CN103825683A (en) | Kernel proxy method and device based on TCP (transmission control protocol) retransmission mechanism | |
CN115348333A (en) | Data transmission method, system and equipment based on UDP (user Datagram protocol) double-end communication interaction | |
CN115604052A (en) | Vehicle communication interaction method and system and electronic equipment | |
CN115333782A (en) | Data transmission method, data reception method, storage medium, and computer device | |
CN114979172B (en) | Data transmission method, device, equipment and storage medium |
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 |