A method, device and storage medium for matching HTTP data streams based on multiple rules

Abstract

The present application proposes a multi-rule HTTP data stream matching method, which first extracts a feature pattern string from the rules configured by the user, generates a finite automaton search graph from the feature pattern string using DFA, and then constructs a DPI search engine using the finite automaton search graph, and then determines the HTTP data stream from the input data stream, and then marks the HTTP feature field position information in the HTTP data stream, structures the HTTP feature field position information into HTTP expected hit position information, and then uses the marked HTTP feature field position information to obtain the HTTP header feature field information, submits the HTTP header feature field information to the DPI search engine for search, obtains the start and end positions of the matching feature, compares the start and end positions of the matching feature with the HTTP expected hit position information, and if they are both within the expected range, the data stream is hit, and then corresponding processing is performed according to the rules configured by the user. This reduces unnecessary search content and improves DPI search performance.

Description

Technical Field

[0001] The present application relates to the technical field of DPI data packet detection, and in particular to a multi-rule based HTTP data stream matching method, device and storage medium. Background Art

[0002] DPI (Deep Packet Inspection) equipment can detect and analyze the traffic and message content at key points of the network, and can filter and control the detected traffic according to pre-defined policies. It can complete the functions of refined business identification of the link, business traffic proportion statistics, business proportion shaping, application denial of service attacks, filtering of viruses and Trojans, and control of P2P abuse.

[0003] In the current DPI field, the performance of deep packet inspection is still the primary challenge. In order to improve DPI processing capabilities, the industry and academia generally adopt: 1. Rely on higher-performance servers and service clusters to accelerate DPI throughput; 2. Rely on better software algorithms to improve matching performance; 3. Rely on various multi-NPU built-in matching engines to accelerate. In short, although the research community and the industry are very concerned about deep packet inspection, the development of DPI technology still cannot catch up with the implementation requirements of related application fields.

[0004] According to current Internet data analysis statistics, data related to the HTTP protocol accounts for more than 50%, so the analysis of the HTTP protocol is of great significance. At the same time, DPI's deep analysis of the HTTP protocol will greatly affect DPI performance consumption and recognition capabilities.

[0005] At present, some HTTP data feature analysis methods have emerged in the DPI field. They mainly use HTTP protocol data feature recognition to divide the HTTP header into several pointer structures, analyze them independently and in parallel according to the structures, and scan the pointer structure (data unit) data to match it with the feature fingerprint library. If a feature fingerprint that matches the data can be found, the data unit is defined as a feature fingerprint. If the acquired feature fingerprint can uniquely indicate an actual application, it is a hit rule. If not, wait for the feature fingerprints of other data units in the data stream, and then merge to find out whether there is a combined rule feature; if so, the data stream is defined as the application shown by the combined feature. However, the above solution has obvious shortcomings in the processing of complex and multi-combination rules, because the combined rule processing adopts the method of waiting for the combined search of features of other data units in the data stream, which affects the DPI processing performance. Summary of the invention

[0006] In response to the above technical problems, the present application proposes a multi-rule based HTTP data stream matching method, device and storage medium.

[0007] In a first aspect, the present application proposes a multi-rule based HTTP data stream matching method, comprising the following steps:

[0008] S1: Extract feature pattern strings from the rules configured by the user, use DFA to generate a finite automaton search graph from the feature pattern strings, and then use the finite automaton search graph to build a DPI search engine;

[0009] S2: Determine the HTTP data stream from the input data stream;

[0010] S3: Mark the HTTP feature field position information in the HTTP data stream, and structure the HTTP feature field position information into HTTP expected hit position information;

[0011] S4: using the marked HTTP feature field position information to obtain HTTP header feature field information, submitting the HTTP header feature field information to the DPI search engine for search, and obtaining the start and end positions of the matching features;

[0012] S5: Compare the start and end positions of the matching feature with the HTTP expected hit position information. If they are both within the expected range, the data stream is hit, and then corresponding processing is performed according to the rules configured by the user.

[0013] Preferably, in S1, the finite automaton search graph includes a root node, a marked node, a normal node, and an arc from each node to another input node.

[0014] Preferably, S2 specifically includes: judging whether the input data stream is TCP data, and if so, parsing the application layer data of the data packet to judge whether there is an HTTP request method, and if so, marking it as an HTTP data stream.

[0015] Preferably, in the S3, the HTTP characteristic field location information includes the starting location information of Host, Url, Cookie, Content-type and user-agent.

[0016] In a second aspect, the present application further proposes a multi-rule based HTTP data stream matching device, the device comprising:

[0017] A rule processing module configured to extract a feature pattern string from a user-configured rule, generate a finite automaton search graph from the feature pattern string using DFA, and then construct a DPI search engine using the finite automaton search graph;

[0018] An HTTP data stream determination module configured to determine an HTTP data stream from an input data stream;

[0019] An HTTP parsing module is configured to mark HTTP characteristic field position information in an HTTP data stream, and structure the HTTP characteristic field position information into HTTP expected hit position information;

[0020] A DPI search module is configured to obtain HTTP header feature field information using the marked HTTP feature field position information, submit the HTTP header feature field information to a DPI search engine for search, and obtain the start and end positions of the matching features;

[0021] The data stream hit module is configured to compare the start and end positions of the matching feature with the HTTP expected hit position information. If both are within the expected range, the data stream is hit and then processed accordingly according to the rules configured by the user.

[0022] Preferably, the finite automaton search graph includes a root node, a marked node, a normal node, and an arc from each node to another input node.

[0023] Preferably, determining the HTTP data stream from the input data stream specifically includes: determining whether it is TCP data based on the input data stream, and if so, parsing the application layer data of the data packet to determine whether there is an HTTP request method, and if so, marking it as an HTTP data stream.

[0024] Preferably, the HTTP characteristic field location information includes the starting location information of Host, Url, Cookie, Content-type and user-agent.

[0025] In a third aspect, the present application further proposes an electronic device, comprising:

[0026] one or more processors;

[0027] A storage device for storing one or more programs;

[0028] When the one or more programs are executed by the one or more processors, the one or more processors implement any of the methods described above.

[0029] In a fourth aspect, the present application further proposes a computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements any of the methods described above.

[0030] The present application proposes a multi-rule HTTP data stream matching method, which first extracts a feature pattern string from the rules configured by the user, generates a finite automaton search graph from the feature pattern string using DFA, and then constructs a DPI search engine using the finite automaton search graph, and then determines the HTTP data stream from the input data stream, and then marks the HTTP feature field position information in the HTTP data stream, structures the HTTP feature field position information into HTTP expected hit position information, and then uses the marked HTTP feature field position information to obtain the HTTP header feature field information, submits the HTTP header feature field information to the DPI search engine for search, obtains the start and end positions of the matching feature, compares the start and end positions of the matching feature with the HTTP expected hit position information, and if they are both within the expected range, the data stream is hit, and then corresponding processing is performed according to the rules configured by the user. This reduces unnecessary search content and improves DPI search performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] The accompanying drawings are included to provide a further understanding of the embodiments and are incorporated into and constitute a part of this specification. The accompanying drawings illustrate the embodiments and are used together with the description to explain the principles of the present application. It will be easy to recognize other embodiments and many expected advantages of the embodiments because they become better understood by reference to the following detailed description. The elements of the drawings are not necessarily to scale with each other. The same reference numerals refer to corresponding similar parts.

[0032] Figure 1 This is a flowchart of a multi-rule based HTTP data stream matching method of the present application.

[0033] Figure 2 A schematic diagram of a specific embodiment of the multi-rule based HTTP data stream matching method that can be applied to the present application.

[0034] Figure 3 It is a schematic diagram of a finite automaton search graph in one embodiment of the present application.

[0035] Figure 4 It is a schematic diagram of the module structure of a multi-rule based HTTP data stream matching device in one embodiment of the present application.

[0036] Figure 5 It is a structural diagram of a computer system suitable for implementing an electronic device of an embodiment of the present application. DETAILED DESCRIPTION

[0037] The present application will be further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the relevant invention, rather than to limit the invention. It should also be noted that, for ease of description, only the parts related to the relevant invention are shown in the accompanying drawings.

[0038] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0039] Figure 1 A flowchart of a multi-rule HTTP data stream matching method of the present application is shown. Figure 2 A schematic diagram showing a specific embodiment of the multi-rule HTTP data stream matching method that can be applied to the present application is shown, with reference to Figure 1 and Figure 2 , the method specifically comprises the following steps:

[0040] S1: Extract feature pattern strings from the rules configured by the user, use DFA to generate a finite automaton search graph from the feature pattern strings, and then use the finite automaton search graph to build a DPI search engine;

[0041] The finite automaton search graph includes a root node, a labeled node, normal nodes, and an arc from each node to another node that is input.

[0042] In a specific example, the rules configured by the user may be as follows:

[0043] "rule match host ascii baidu.com action distribute port-group 2hit-stat user-id 1"

[0044] The above rule specifies that the Host field with "baidu.com" field hits the output to port group 2. (The port group is composed according to the output port configuration).

[0045] After receiving the rule, extract the rule features, that is, the pattern string to be matched. Each rule is allowed to have multiple features, such as: Host, Url, Cookie, Content-type, user-agent and other field information.

[0046] In a specific embodiment, a characteristic pattern string is extracted according to the rules configured by the user. The characteristic pattern string is used to determine a finite automaton search graph using DFA (Deterministic Finite Automaton). Figure 3As shown, this is the search graph generated by DFA for the pattern strings "reality", "realise", and "seven".

[0047] Reference Figure 3 , the DFA search graph includes:

[0048] (1) The root node (shown as a triangle in this example). The first packet in the stream starts the graph traversal at this node. (The first packet starts at the root node.) The root node is entered without any characters.

[0049] (2) A set of labeled nodes ({11,13,14} in this case, shown as rectangles). These correspond to nodes where the input string matches the pattern in the graph.

[0050] (3) A set of normal nodes, shown as ovals in this example. These nodes correspond to the states that the DFA passes through when searching for a match.

[0051] (4) A set of arcs (transitions) from each node to another node corresponding to a possible input (as indicated by arrows labeled with inputs).

[0052] For example, the process of matching the character "reality" is as follows:

[0053] Given an input string: sjrealityxx,, the DFA engine will start traversing the graph from node 0.

[0054] Note: The string sjrealityxx includes the string "reality".

[0055] Traverse the graph with the string "sjrealityxx":

[0056] 1)s-Start from node 0 and move to node 10.

[0057] 2) j - Return to node 0.

[0058] 3)r-Start from node 0 and move to node 1.

[0059] 4) e-Move from node 1 to node 2.

[0060] 5)a-Move from node 2 to node 3.

[0061] 6) l-Move from node 3 to node 4.

[0062] 7)i-Move from node 4 to node 5.

[0063] 8) t-Move from node 5 to node 6.

[0064] 9) y - Move from node 6 to node 7 (matching pattern "reality"). At this point record the input offset and continue processing.

[0065] S2: Determine the HTTP data stream from the input data stream;

[0066] The S2 specifically includes: judging whether the input data stream is TCP data, if so, parsing the data packet application layer data to judge whether there is an HTTP request method, and if so, marking it as HTTP data stream.

[0067] In a specific embodiment, it is determined whether the input data stream is TCP data. If so, the application layer data of the data packet is parsed. According to the RFC2616 standard, such as whether the L4 Payload header of the data packet has an HTTP request method, the data stream can be quickly marked as an HTTP stream.

[0068] S3: Mark the HTTP feature field position information in the HTTP data stream, and structure the HTTP feature field position information into HTTP expected hit position information;

[0069] The HTTP feature field location information includes the starting location information of Host, Url, Cookie, Content-type and user-agent.

[0070] In a specific embodiment, in the HTTP data packet header information, the Url field starts with relevant method characteristics, such as POST, GET and other characteristics, and ends with "HTTP / 1." as a mark. The Host field starts with "Host" and ends with "\r\n". Other fields such as Cookie, Content-type, user-agent and other fields are composed of three parts: domain name, colon (:) and domain value, and end with \r\n. The above features can be used to quickly mark the location information of each field, and structure this location information into HTTP expected hit information. The HTTP expected hit information corresponds to the offset of the starting position of the L4 Payload, as shown in the following table:

[0071] Fields meaning uHostStart Host field starting position uHostEnd Host field end position uUrlStart Url field starting position uUrlEnd End position of the Url field uCookieStart Cookie field start position uCookieEnd Cookie field end position uUserAgentStart UserAgent field start position uUserAgentEnd End position of UserAgent field uRefererStart Starting position of the Referer field uRefererEnd End position of the Referer field uContentTypeStart ContentType field starting position uContentTypeEnd ContentType field end position

[0072] S4: using the marked HTTP feature field position information to obtain HTTP header feature field information, submitting the HTTP header feature field information to the DPI search engine for search, and obtaining the start and end positions of the matching features;

[0073] In a specific embodiment, the position of each marked field is used (for example, the corresponding field content is extracted according to the starting and ending positions of Host and Url), the information of each field in the HTTP header is obtained, and submitted to the DPI search engine at one time for matching search processing. This step does not submit the complete information of the HTTP header for search, because step S3 has already parsed the positions of each HTTP field and marked them. Only the HTTP feature field needs to be searched, which reduces unnecessary search content and improves the DPI search performance. According to the results returned by the DPI search engine, the starting and ending positions of each matching feature can be obtained.

[0074] S5: Compare the start and end positions of the matching feature with the HTTP expected hit position information. If they are both within the expected range, the data stream is hit, and then corresponding processing is performed according to the rules configured by the user.

[0075] The rule hit judgment is to compare the start and end positions of the hit pattern string with the positions of the Host, Url, Cookie, Content-type, and user-agent tags. If they are within the range, the rule is judged to be hit.

[0076] The HTTP parsing module can structure the expected hit position information of each HTTP field. Using the feature matching position returned by the DPI search engine, each matching position is compared with the expected information. If they are all within the expected hit position, the data stream is hit, otherwise the data stream is not hit. Then forwarding or discarding actions are performed according to the rules configured by the user, such as:

[0077] "rule match host ascii baidu.com action distribute port-group 2hit-stat user-id 1"

[0078] The above rule specifies that the Host field with "baidu.com" field hits the output to port group 2. (The port group is composed according to the output port configuration).

[0079] Further references Figure 4 As an implementation of the above method, the present application provides an embodiment of a multi-rule HTTP data stream matching device. The system embodiment is similar to Figure 1 Corresponding to the method embodiment shown, the system can be specifically applied to various electronic devices.

[0080] refer to Figure 4 , a multi-rule based HTTP data stream matching device, comprising:

[0081] A rule processing module is configured to extract a feature pattern string from the rules configured by the user, generate a finite automaton search graph from the feature pattern string using DFA, and then construct a DPI search engine using the finite automaton search graph; the finite automaton search graph includes a root node, a marked node, a normal node, and an arc from each node to another input node.

[0082] The HTTP data stream judgment module is configured to judge the HTTP data stream from the input data stream, specifically including: judging whether it is TCP data according to the input data stream, if so, parsing the application layer data of the data packet to judge whether there is an HTTP request method, and if so, marking it as HTTP data stream.

[0083] The HTTP parsing module is configured to mark the HTTP feature field position information in the HTTP data stream and structure the HTTP feature field position information into HTTP expected hit position information; the HTTP feature field position information includes the starting position information of Host, Url, Cookie, Content-type and user-agent.

[0084] A DPI search module is configured to obtain HTTP header feature field information using the marked HTTP feature field position information, submit the HTTP header feature field information to a DPI search engine for search, and obtain the start and end positions of the matching features;

[0085] The data stream hit module is configured to compare the start and end positions of the matching feature with the HTTP expected hit position information. If both are within the expected range, the data stream is hit and then processed accordingly according to the rules configured by the user.

[0086] Reference below Figure 5 , which shows a schematic diagram of the structure of a computer system 100 suitable for implementing an electronic device of an embodiment of the present application. Figure 5 The electronic device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0087] like Figure 5 As shown, the computer system 100 includes a central processing unit (CPU) 101, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 102 or a program loaded from a storage part 108 into a random access memory (RAM) 103. In the RAM 103, various programs and data required for the operation of the system 100 are also stored. The CPU 101, the ROM 102, and the RAM 103 are connected to each other through a bus 104. An input / output (I / O) interface 105 is also connected to the bus 104.

[0088] The following components are connected to the I / O interface 105: an input section 106 including a keyboard, a mouse, etc.; an output section 107 including a liquid crystal display (LCD), etc. and a speaker, etc.; a storage section 108 including a hard disk, etc.; and a communication section 109 including a network interface card such as a LAN card, a modem, etc. The communication section 109 performs communication processing via a network such as the Internet. A drive 110 is also connected to the I / O interface 105 as needed. A removable medium 111, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 110 as needed, so that a computer program read therefrom is installed into the storage section 108 as needed.

[0089] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program contains program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication part 109, and / or installed from a removable medium 111. When the computer program is executed by a central processing unit (CPU) 101, the above-mentioned functions defined in the method of the present application are executed.

[0090] As another aspect, the present application also provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiment; or may exist independently without being assembled into the electronic device. The above computer-readable storage medium carries one or more programs, and when the above one or more programs are executed by the electronic device, the electronic device implements the following when executing. Figure 1 The method shown in .

[0091] It should be noted that the computer-readable storage medium described in the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer-readable signal medium may also be any computer-readable storage medium other than a computer-readable storage medium that can send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0092] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0093] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0094] The above describes the specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0095] In the description of the present application, it should be understood that the terms "upper", "lower", "inside", "outside", etc. indicate orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, which are only for the convenience of describing the present application and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present application. The wording 'comprising' does not exclude the presence of elements or steps not listed in the claims. The wording 'one' or 'an' preceding an element does not exclude the presence of a plurality of such elements. The simple fact that certain measures are recorded in mutually different dependent claims does not indicate that a combination of these measures cannot be used for improvement. Any reference symbols in the claims should not be interpreted as limiting the scope.

Claims

1. A multi-rule based HTTP data stream matching method, characterized in that: The method comprises the following steps: S1: Extract feature pattern strings from the rules configured by the user, use DFA to generate a finite automaton search graph from the feature pattern strings, and then use the finite automaton search graph to build a DPI search engine; S2: Determine the HTTP data stream from the input data stream; S3: marking the HTTP feature field position information in the HTTP data stream, and structuring the HTTP feature field position information into HTTP expected hit position information; S4: using the marked HTTP feature field position information to obtain HTTP header feature field information, submitting the HTTP header feature field information to the DPI search engine for search, and obtaining the start and end positions of the matching features; S5: Compare the start and end positions of the matching feature with the HTTP expected hit position information. If they are both within the expected range, the data stream is hit, and then corresponding processing is performed according to the rules configured by the user.

2. The method for matching HTTP data streams based on multiple rules according to claim 1, characterized in that: In the S1, the finite automaton search graph includes a root node, a marked node, a normal node, and an arc from each node to another input node.

3. The method for matching HTTP data streams based on multiple rules according to claim 1, characterized in that: The S2 specifically includes: judging whether the input data stream is TCP data, if so, parsing the data packet application layer data to judge whether there is an HTTP request method, and if so, marking it as HTTP data stream.

4. The method for matching HTTP data streams based on multiple rules according to claim 1, characterized in that: In the S3, the HTTP feature field location information includes the starting location information of Host, Url, Cookie, Content-type and user-agent.

5. A multi-rule based HTTP data stream matching device, characterized in that: The device comprises: A rule processing module configured to extract a feature pattern string from a user-configured rule, generate a finite automaton search graph from the feature pattern string using DFA, and then construct a DPI search engine using the finite automaton search graph; An HTTP data stream determination module configured to determine an HTTP data stream from an input data stream; An HTTP parsing module is configured to mark HTTP characteristic field position information in an HTTP data stream, and structure the HTTP characteristic field position information into HTTP expected hit position information; A DPI search module is configured to obtain HTTP header feature field information using the marked HTTP feature field position information, submit the HTTP header feature field information to a DPI search engine for search, and obtain the start and end positions of the matching features; The data stream hit module is configured to compare the start and end positions of the matching feature with the HTTP expected hit position information. If both are within the expected range, the data stream is hit and then processed accordingly according to the rules configured by the user.

6. The multi-rule based HTTP data stream matching device according to claim 5, characterized in that: The finite automaton search graph includes a root node, a labeled node, normal nodes, and an arc from each node to another node that is input.

7. The multi-rule based HTTP data stream matching device according to claim 5, characterized in that: Determining the HTTP data stream from the input data stream specifically includes: determining whether the input data stream is TCP data, if so, parsing the application layer data of the data packet to determine whether there is an HTTP request method, and if so, marking it as an HTTP data stream.

8. The multi-rule based HTTP data stream matching device according to claim 5, characterized in that: The HTTP feature field location information includes the starting location information of Host, Url, Cookie, Content-type and user-agent.

9. An electronic device, comprising: One or more processors: A storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 4.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 4 is implemented.

Images