Network traffic application identification system and method based on kernel

Abstract

After the implementation complexity, the maintenance cost, the kernel load, the network throughput, the recognition rate and the like are comprehensively considered, the kernel-based network flow application recognition method is provided, and the kernel-based network flow application recognition method is suitable for network equipment (products) developed based on a kernel. The method comprises two parts: initialization and message application identification, wherein the message application identification part is completed by mutual configuration of a message acquisition module and an application identification engine. Wherein the message acquisition module runs in the form of a kernel module, and provides message content, metadata and stream information for the application identification engine through nfquery. The application identification engine runs in a user mode program mode, obtains message content (and metadata and stream information related to the message) needing to be identified through nfquery, carries out application identification on the message, and updates an identification result to a kernel nfconnecrack through netlink, and the kernel nfconnecrack comprises a kernel nfconnecrack, a kernel nfconnecrack, a kernel nfconnecrack, a kernel nfconnecrack, a kernel nfconnecrack, a kernel nfconnecrack, a kernel nfconnecrack, a kernel nfconnecrack and a kernel nfconnecrack.

Description

Technical Field

[0001] The present invention relates to the field of network communication, and in particular to a kernel-based network flow application identification system and method. Background Art

[0002] Network traffic identification methods include: port identification, deep packet inspection (DPI), deep flow inspection (DFI), machine learning, etc. At present, port identification, deep packet inspection (DPI) and deep flow inspection (DFI) are mainly used in production environments. Among them, deep packet inspection (DPI) is the main identification method. Port identification and deep flow inspection (DFI) are used as auxiliary identification methods due to the problems of low recognition rate and misidentification. The deep packet inspection method loads application identification rules and uses multi-mode matching to detect packets. A large number of rules will cause the cost of deep packet inspection to be very high (matching the rules with the payload of each packet). At present, some network devices (products) are still developed based on the Linux kernel. If a complete DPI engine is implemented in the kernel, the cost of engine development and maintenance is very high, and a large number of rules matching the payload of each packet will also increase the load on the kernel and reduce the throughput of network devices. Summary of the invention

[0003] The purpose of the present invention is to propose a kernel-based network traffic application identification system and method. After comprehensively considering the implementation complexity, maintenance cost, kernel load, network throughput, identification rate, etc., the system and method proposed by the present invention are suitable for network devices developed based on the kernel.

[0004] The invention includes a kernel-based network traffic application identification system and method. The specific contents of the system and method are as follows: A kernel-based network traffic application identification system, the system includes an initialization module, a message collection module and an application identification engine: The initialization module is used to initialize the resources required to complete the message application identification; The message collection module runs in the form of a kernel module and provides message content, metadata and flow information to the application identification engine through nfqueue; The application identification engine runs as a user-mode program, obtains the message content to be identified through nfqueue, performs application identification on the message, and updates the identification result to the kernel nf_conntrack through netlink; The message collection module and the application identification engine cooperate with each other to complete message application identification.

[0005] Furthermore, the resources required to complete the message application identification include: the HOOK function of the netfilter framework, the kernel message collection and sending rules, the nfqueue and netlink used to transmit data between the kernel and the user state, the application identification engine, and the application identification rules.

[0006] Furthermore, the specific processing flow of the initialization module is as follows: (1) Load the kernel message collection module; (2) Initialize the HOOK function of the netfilter framework, kernel message collection and sending rules, nfqueue and netlink; (3) Start the application identification engine; (4) Initialize the application identification engine and application identification rules.

[0007] Furthermore, the message collection module and the application identification engine cooperate with each other to complete the message application identification. The specific process is as follows: (1) The message arrives at the INPUT, OUTPUT, and FORWARD HOOK points of the netfilter framework; (2) The message collection module sends the message content, metadata, and flow information to the application identification engine through nfqueue; (3) The application identification engine completes the application identification of the message; (4) The application identification engine updates the identification results to the kernel nf_conntrack.

[0008] Furthermore, the detailed steps of the message application identification process are as follows: Step 1: Find the application of the flow to which the packet belongs, that is, the markid in nf_conntrack. If it has been identified, obtain the markid in nf_conntrack and execute step 14. Otherwise, execute step 2. Step 2: Get the message count of the flow to which the message belongs, that is, the number of messages that have been processed by the application identification engine. If the message count is greater than the set threshold, use the highest protocol that can be identified currently as the APPID of the message and execute step 13; otherwise, execute step 3. Step 3, parsing the layer 2 or 3 protocol of the message; Step 4: Search for the message collection strategy. If no corresponding collection strategy is matched, use the highest protocol that can be identified as the APPID of the message and execute step 13. Otherwise, execute step 5. Step 5: Send the message content, metadata and flow information to nfqueue; Step 6: Determine the type of the fourth layer protocol of the message. If it is not TCP / UDP, use the basic protocol parsed in step 3 as the APPID of the message and execute step 12. Otherwise, execute step 7. Step 7: Perform port identification. If the port receiving the message is a standard port, directly use the application corresponding to the port as the APPID of the message and execute step 12; otherwise, execute step 8. Step 8: Application layer protocol analysis. If the analysis result is HTTP protocol, execute step 9; if the analysis result is HTTPS protocol, execute step 10; if the analysis result is other protocols, execute step 11; Step 9: Parse and extract the Host, User-Agent, and set-cookie fields in the HTTP Request message and match them with the predetermined application identification rules to identify the application to which the message belongs, obtain the APPID of the message, and execute step 12; Step 10: Parse and extract the Server Name and RelativeDistinguishedName fields in the HTTPS TLS message and match them with the predetermined application identification rules to identify the application to which the message belongs, obtain the APPID of the message, and execute step 12; Step 11: Use the predetermined application identification rule to match the entire message payload, identify the application to which the message belongs, obtain the APPID of the message, and execute step 12; Step 12: Send the APPID of the message to the kernel via netlink; Step 13: Update the APPID of the message to the markid in nf_conntrack; Step 14: Use the markid in nf_conntrack to update the markid in the skb message.

[0009] Furthermore, the specific steps of step 9 are as follows: Step 1: Parse the HTTP request line and request header in the HTTP Request message; The steps are: extracting Method and URI from the HTTP request line and matching them with the predetermined application identification rules; Step 3: Determine whether the application to which the message belongs is identified. If the application to which the message belongs is identified, execute step 6; otherwise, execute step 4. Step 4: Get the Host, User-Agent, and set-cookie fields from the HTTP request header and match them with the predetermined application identification rules to identify the application to which the message belongs; Step 5, determine whether the application to which the message belongs is identified, if the application to which the message belongs is not identified, the APPID of the output message is 0; Step 6: Output the APPID of the message.

[0010] Furthermore, the specific steps of step 10 are as follows: Step 1: Parse the Handshake Client Hello and Handshake Certificate in the TLS message; Step 2: Extract the Server Name field from the Handshake Client Hello, and then perform multi-pattern matching on it; Step 3: Determine whether the application to which the message belongs is identified. If the application to which the message belongs is identified, execute step 6; otherwise, execute step 4; Step 4: Extract the RelativeDistinguishedName field from the Handshake Certificate and match it with the predetermined application identification rule to identify the application to which the message belongs; Step 5: Determine whether the application to which the message belongs is identified. If the application to which the message belongs is not identified, output APPID as 0; Step 6. Output the APPID of the message.

[0011] A kernel-based network traffic application identification method comprises the following steps: 1. The message arrives at the INPUT, OUTPUT and FORWARD HOOK points of the netfilter framework; 2. The message collection module sends the message content, metadata and flow information to the application identification engine through nfqueue; 3. The application identification engine completes the application identification of the message; 4. The application identification engine updates the identification results to the kernel nf_conntrack.

[0012] Furthermore, the method specifically comprises the following steps: Step 1: Find the application of the flow to which the packet belongs, that is, the markid in nf_conntrack. If it has been identified, obtain the markid in nf_conntrack and execute step 14. Otherwise, execute step 2. Step 2: Get the message count of the flow to which the message belongs, that is, the number of messages that have been processed by the application identification engine. If the message count is greater than the threshold, which is 10 by default and can be set to a different value during initialization, the highest protocol that can be identified currently is used as the APPID of the message, and execute step 13; otherwise, execute step 3. Step 3: parse the layer 2 and layer 3 protocols of the message; Step 4: Find the message collection policy. The default is all. You can configure different policies as needed during initialization. For example, filter messages based on IP, port, and protocol. If the collection policy is not matched, use the highest protocol that can be identified as the APPID of the message and execute step 13. Otherwise, execute step 5. Step 5: Send the message content, metadata and flow information to nfqueue; Step 6: Determine the type of the fourth layer protocol of the message. If it is not TCP / UDP, use the resolved basic protocol as the APPID of the message and execute step 12; otherwise, execute step 7. Step 7: Identify the port. If it is a standard port, directly use the application corresponding to the port as the APPID of the message and execute step 12. Otherwise, execute step 8. Step 8: Application layer protocol analysis. Different protocols execute different steps. HTTP protocol executes step 9, HTTPS protocol executes step 10, and others execute step 11. Step 9, parse and extract the HTTP Request message Host, User-Agent and set-cookie fields and match them with the predetermined application identification rules to identify the application to which the message belongs; Step 10: Parse and extract the Server Name and RelativeDistinguishedName fields in the HTTPS TLS message and match them with the predetermined application identification rules to identify the application to which the message belongs; Step 11: Use the predetermined application identification rules to match the entire message payload and identify the application to which the message belongs; Step 12: Send the identified message APPID to the kernel via netlink; Step 13: Update the identified message APPID to the markid in nf_conntrack; Step 14: Use the markid in nf_conntrack to update the markid in the skb message.

[0013] Use the netfilter framework to obtain kernel messages and use the flow table maintained by nf_conntrack to reduce the difficulty of development and maintenance and reduce kernel modification and impact; The user-mode application identification engine obtains (a small number of messages) messages from nfqueue and performs application identification, offloading the complex application identification function to the user-mode program. The kernel only needs to implement simple message parsing, filtering and sending to nfqueue, which reduces the difficulty of implementation, facilitates development and debugging, and reduces the risk of system PANIC caused by large-scale modifications to the kernel.

[0014] Using the markid and packet count in the flow table, the application identification results are returned in advance, reducing the number of messages that need to be sent to the application identification engine for processing and improving performance; The application identification engine promptly updates the APPID of the message to the kernel flow table (nf_conntrack's markid) and the message (skb's markid) through netlink, which can reduce the number of messages that need to be sent to the application identification engine for processing, and can provide the application identification results to other functions (modules), such as application-based traffic statistics, application-based ACL, application-based rate limit, and application-based load balancing. Prioritize port identification to reduce the number of message processing in subsequent modules and improve performance; For HTTP messages, only HTTP Request messages are processed. Only HTTP request lines and HTTP request headers need to be parsed, some fields (Host, User-Agent, set-cookie, etc.) extracted, and then multi-pattern matching is performed on them. This reduces the cost of HTTP message packaging, decompression, and parsing, thus improving performance. For HTTPS messages, only TLS messages are processed, and only Handshake Client Hello and HandshakeCertificate need to be parsed to extract some fields (Server Name and RelativeDistinguishedName), and then multi-pattern matching is performed on them to reduce the number of multi-pattern matching messages and payload length, thereby improving performance; Only a small number of messages (unrecognized) require multi-pattern matching of the complete message. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 It is the initialization process.

[0016] Figure 2 This is the processing flow of the message collection module (ko) and the application identification engine.

[0017] Figure 3 This is the message application identification processing flow.

[0018] Figure 4 This is the processing flow of the HTTP protocol identification module.

[0019] Figure 5 This is the processing flow of the HTTPS protocol identification module. DETAILED DESCRIPTION

[0020] The present invention consists of two parts: initialization and message application identification, wherein the message application identification part is completed by mutual configuration of a message collection module (kernel ko) and an application identification engine (user state).

[0021] The initialization part is mainly used to initialize the resources required to complete the message application identification, such as the HOOK function of the netfilter framework, the kernel message collection and sending rules, the nfqueue and netlink used to transmit data between the kernel and the user state (message content, metadata, flow information and APPID), the application identification engine, the application identification rules, etc. Initialization process: first load the kernel message collection module; then initialize the netfilter HOOK, message collection rules, nfqueue and netlink; start the application identification engine again; finally initialize the application identification engine and application identification rules. The detailed initialization process is as follows: Figure 1 shown.

[0022] The message application identification part mainly completes the acquisition and application identification of messages, and updates the identification results to nf_conntrack. The message application identification part consists of a message collection module (ko) and an application identification engine (user state). The message collection module runs as a kernel module, and provides message content, metadata, and flow information to the application identification engine through nfqueue. The application identification engine runs as a user-state program, obtains the message content to be identified (as well as message-related metadata and flow information) through nfqueue, performs application identification on the message, and updates the identification results to the kernel nf_conntrack through netlink. The message collection module and the application identification engine cooperate with each other to complete the application identification of the message. The processing flow is as follows: Figure 2 As shown in the figure, first, the message arrives at the INPUT, OUTPUT and FORWARD HOOK points of the netfilter framework; secondly, the message collection module sends the message content, metadata and flow information that needs to be sent to the application identification engine to the application identification engine through nfqueue; then the application identification engine completes the application identification of the message, and finally the application identification engine updates the identification result to the kernel nf_conntrack.

[0023] The following is a corresponding explanation of the special terms involved in the present invention: netfilter: A general, abstract framework that provides a complete set of hook function management mechanisms, based on which packet filtering, network address translation (NAT), and protocol-based connection tracking can be implemented; nf_conntrack: The connection tracking mechanism in the kernel, used to track the status and related information of network connections; nfqueue: A scheme for exchanging messages between kernel and user states. It can be used to send kernel messages to user states through queues for use by user state programs. Netlink: A special inter-process communication (IPC) used to implement communication between user processes and kernel processes. It is also the most commonly used interface for network applications to communicate with the kernel. APPID: An integer value, each value represents an application (such as Baidu, Tencent, Taobao, QQ, etc.). Because the program is more efficient in processing numbers, but the application name is more user-friendly, there should be a mapping table for the recognition function to indicate the APPID corresponding to different applications. The program uses APPID for processing, and the corresponding application name is used for user display. The APPID corresponding to different applications can be any value, but it must be globally unique; skb: Used to represent a message in the kernel.

[0024] The detailed message application identification process is as follows: Figure 3 Detailed steps: Find the application of the flow to which the packet belongs (markid in nf_conntrack). If it has been identified, obtain the markid in nf_conntrack and go to step 14. Otherwise, go to step 2. Get the packet count of the flow to which the packet belongs (indicates the number of packets processed by the application identification engine). If the packet count is greater than the threshold (the default value is 10, and a different value can be set during initialization), use the highest protocol that can be identified as the APPID of the packet and execute step 13. Otherwise, execute step 3. Parse messages (layer 2 / 3 protocols); Search for the message collection policy (the default is all, and different policies can be configured as needed during initialization, such as filtering messages based on IP, port, or protocol). If the collection policy is not matched, use the highest protocol that can be identified as the APPID of the message and execute step 13. Otherwise, execute step 6. Send the message content, metadata and flow information to nfqueue; Determine the Layer 4 protocol type of the message. If it is not TCP / UDP, use the parsed basic protocol (ARP / RARP / ICMP / RIP / IP, etc.) as the APPID of the message and execute step 12. Otherwise, execute step; Perform port identification. If it is a standard port (except 80 / 443 / 8080 / 8443, etc.), directly use the application corresponding to the port as the APPID of the message and execute step 12. Otherwise, execute step 8. Application layer protocol analysis: different protocols execute different steps. HTTP protocol executes step 9, HTTPS protocol executes step 10, and others execute step 11. Parse HTTP Request messages, extract some fields (Host, User-Agent, set-cookie, etc.) for multi-pattern matching, and identify the application to which the message belongs; Parse HTTPS (TLS) messages, extract some fields (Server Name and RelativeDistinguishedName) for multi-pattern matching, and identify the application to which the message belongs; Use application identification rules to perform multi-pattern matching on the entire message payload to identify the application to which the message belongs; Send the identified message APPID to the kernel through netlink; Update the identified message APPID to nf_conntrack (markid); 14. Use the markid in nf_conntrack to update the markid in the skb (message).

[0025] The processing flow of the HTTP protocol identification module is as follows Figure 4 As shown, the detailed steps are: HTTP protocol parsing, only parsing the HTTP request line and request header in the HTTP Request message; Extract some fields (Method and URI) from the HTTP request line and then perform multi-pattern matching on them; Determine whether the application to which the message belongs is identified, if the application to which the message belongs is identified, execute step 6; Extract some fields (Host, User-Agent, set-cookie, etc.) from the HTTP request header and then perform multi-pattern matching on them; Determine whether the application to which the message belongs is identified. If the application to which the message belongs is not identified, output APPID as 0 and end; Output the APPID of the application identified by the message.

[0026] The processing flow of the HTTPS protocol identification module is as follows: Figure 5 As shown, the detailed steps are: HTTPS (TLS) protocol parsing, only parsing Handshake Client Hello and HandshakeCertificate in TLS messages; Extract the Server Name field from the Handshake Client Hello and then perform multi-pattern matching on it. Determine whether the application to which the message belongs is identified, if the application to which the message belongs is identified, execute step 6; Extract the RelativeDistinguishedName field from the Handshake Certificate and then perform multi-pattern matching on it. Determine whether the application to which the message belongs is identified. If the application to which the message belongs is not identified, output APPID as 0 and end; Output the APPID of the application identified by the message.

[0027] Based on the same technical solution, the present invention also discloses a computer-readable storage medium storing one or more programs, wherein the one or more programs include instructions, which, when executed by a computing device, enable the computing device to execute the above-mentioned kernel-based network traffic application identification system and method.

[0028] Based on the same technical solution, the present invention also discloses a computing device, including one or more processors, one or more memories and one or more programs, wherein the one or more programs are stored in the one or more memories and are configured to be executed by the one or more processors, and the one or more programs include a method for executing the above-mentioned kernel-based network traffic application identification system and method.

[0029] It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0030] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0031] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0032] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

Claims

1. A kernel-based network traffic application identification system, characterized in that: The system includes an initialization module, a message collection module and an application identification engine: The initialization module is used to initialize the resources required to complete the message application identification; The message collection module runs in the form of a kernel module and provides message content, metadata and flow information to the application identification engine through nfqueue; The application identification engine runs as a user-mode program, obtains the message content to be identified through nfqueue, performs application identification on the message, and updates the identification result to the kernel nf_conntrack through netlink; The message collection module and the application identification engine cooperate with each other to complete message application identification.

2. The system according to claim 1, characterized in that The resources required to complete the message application identification include: the HOOK function of the netfilter framework, the kernel message collection and sending rules, the nfqueue and netlink used to transmit data between the kernel and the user state, the application identification engine, and the application identification rules.

3. The system according to claim 1, characterized in that The specific processing flow of the initialization module is as follows: (3.1) Load the kernel message collection module; (3.2) Initialize the HOOK function of the netfilter framework, kernel message collection and sending rules, nfqueue and netlink; (3.3) Start the application identification engine; (3.4) Initialize the application identification engine and application identification rules.

4. The system according to claim 1, characterized in that The message collection module and the application identification engine cooperate with each other to complete the message application identification. The specific process is as follows: (4.1) The message arrives at the INPUT, OUTPUT and FORWARD HOOK points of the netfilter framework; (4.2) The message collection module sends the message content, metadata and flow information to the application identification engine through nfqueue; (4.3) The application identification engine completes the application identification of the message; (4.4) The application identification engine updates the identification results to the kernel nf_conntrack.

5. The system according to claim 4, characterized in that , the detailed steps of the message application identification process are as follows: Step 1: Find the application of the flow to which the packet belongs, that is, the markid in nf_conntrack. If it has been identified, obtain the markid in nf_conntrack and execute step 14. Otherwise, execute step 2. Step 2: Get the message count of the flow to which the message belongs, that is, the number of messages that have been processed by the application identification engine. If the message count is greater than the set threshold, use the highest protocol that can be identified currently as the APPID of the message and execute step 13; otherwise, execute step 3. Step 3, parsing the second or third layer protocol of the message; Step 4: Search for the message collection strategy. If no corresponding collection strategy is matched, use the highest protocol that can be identified as the APPID of the message and execute step 13. Otherwise, execute step 5. Step 5: Send the message content, metadata and flow information to nfqueue; Step 6: Determine the fourth layer protocol type of the message. If it is not TCP / UDP, use the basic protocol parsed in step 3 as the APPID of the message and execute step 12. Otherwise, execute step 7. Step 7: Perform port identification. If the port receiving the message is a standard port, directly use the application corresponding to the port as the APPID of the message and execute step 12; otherwise, execute step 8. Step 8: Application layer protocol analysis. If the analysis result is HTTP protocol, execute step 9; if the analysis result is HTTPS protocol, execute step 10; if the analysis result is other protocols, execute step 11; Step 9: Parse and extract the Host, User-Agent, and set-cookie fields in the HTTP Request message and match them with the predetermined application identification rules to identify the application to which the message belongs, obtain the APPID of the message, and execute step 12; Step 10: Parse and extract the Server Name and RelativeDistinguishedName fields in the HTTPS TLS message and match them with the predetermined application identification rules to identify the application to which the message belongs, obtain the APPID of the message, and execute step 12; Step 11: Use the predetermined application identification rule to match the entire message payload, identify the application to which the message belongs, obtain the APPID of the message, and execute step 12; Step 12: Send the APPID of the message to the kernel via netlink; Step 13: Update the APPID of the message to the markid in nf_conntrack; Step 14: Use the markid in nf_conntrack to update the markid in the skb message.

6. The system according to claim 5, characterized in that , the specific steps of step 9 are as follows: Step 1: Parse the HTTP request line and request header in the HTTP Request message; Step 2: Extract the Method and URI from the HTTP request line and match them with the predetermined application identification rules to identify the application to which the message belongs; Step 3: Determine whether the application to which the message belongs is identified. If the application to which the message belongs is identified, execute step 6; otherwise, execute step 4; Step 4: Get the Host, User-Agent, and set-cookie fields from the HTTP request header and match them with the predetermined application identification rules to identify the application to which the message belongs; Step 5, determine whether the application to which the message belongs is identified, if the application to which the message belongs is not identified, the APPID of the output message is 0; Step 6: Output the APPID of the message.

7. The system according to claim 5, characterized in that , the specific steps of step 10 are as follows: Step 1: Parse the Handshake Client Hello and Handshake Certificate in the TLS message; Step 2: Extract the Server Name field from the Handshake Client Hello, and then perform multi-pattern matching on it; Step 3: Determine whether the application to which the message belongs is identified. If the application to which the message belongs is identified, execute step 6; otherwise, execute step 4; Step 4: Extract the RelativeDistinguishedName field from the Handshake Certificate and match it with the predetermined application identification rule to identify the application to which the message belongs; Step 5: Determine whether the application to which the message belongs is identified. If the application to which the message belongs is not identified, output APPID as 0; Step 6: Output the APPID of the message.

8. A kernel-based network traffic application identification method, characterized in that: The following steps are involved: (8.1) The message arrives at the INPUT, OUTPUT and FORWARD HOOK points of the netfilter framework; (8.2) The message collection module sends the message content, metadata and flow information to the application identification engine through nfqueue; (8.3) The application identification engine completes the application identification of the message; (8.4) The application identification engine updates the identification results to the kernel nf_conntrack.

9. The method according to claim 8, characterized in that Steps (8.2) to (8.4) specifically include: Step 1: Find the application of the flow to which the packet belongs, that is, the markid in nf_conntrack. If it has been identified, obtain the markid in nf_conntrack and execute step 14. Otherwise, execute step 2. Step 2: Get the message count of the flow to which the message belongs, that is, the number of messages that have been processed by the application identification engine. If the message count is greater than the set threshold, use the highest protocol that can be identified currently as the APPID of the message and execute step 13; otherwise, execute step 3. Step 3, parsing the second or third layer protocol of the message; Step 4: Search for the message collection strategy. If no corresponding collection strategy is matched, use the highest protocol that can be identified as the APPID of the message and execute step 13. Otherwise, execute step 5. Step 5: Send the message content, metadata and flow information to nfqueue; Step 6: Determine the fourth layer protocol type of the message. If it is not TCP / UDP, use the basic protocol parsed in step 3 as the APPID of the message and execute step 12. Otherwise, execute step 7. Step 7: Perform port identification. If the port receiving the message is a standard port, directly use the application corresponding to the port as the APPID of the message and execute step 12; otherwise, execute step 8. Step 8: Application layer protocol analysis. If the analysis result is HTTP protocol, execute step 9; if the analysis result is HTTPS protocol, execute step 10; if the analysis result is other protocols, execute step 11; Step 9: Parse and extract the Host, User-Agent, and set-cookie fields in the HTTP Request message and match them with the predetermined application identification rules to identify the application to which the message belongs, obtain the APPID of the message, and execute step 12; Step 10: Parse and extract the Server Name and RelativeDistinguishedName fields in the HTTPS TLS message and match them with the predetermined application identification rules to identify the application to which the message belongs, obtain the APPID of the message, and execute step 12; Step 11: Use the predetermined application identification rule to match the entire message payload, identify the application to which the message belongs, obtain the APPID of the message, and execute step 12; Step 12: Send the APPID of the message to the kernel via netlink; Step 13: Update the APPID of the message to the markid in nf_conntrack; Step 14: Use the markid in nf_conntrack to update the markid in the skb message.

10. An electronic device, characterized in that: The method comprises one or more processors, one or more memories and one or more programs, wherein the one or more programs are stored in the one or more memories and are configured to be executed by the one or more processors, and the one or more programs include instructions for executing the method as described in any one of claims 8 to 9.

Images