Packet distribution method, network device and storage medium
By diversion processing based on message type and port number in the AF_XDP environment, the resource conflict problem when the AF_XDP user state protocol stack and the Linux kernel protocol stack share the network interface in the virtual machine or container scenario is solved, and stability and performance are improved.
Patent Information
- Application Number
- PCT/CN2024/073243
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-06-26
- Filing Date
- 2024-01-19
- Publication Date
- 2025-01-02
AI Technical Summary
In virtual machine or container scenarios, when the AF_XDP user state protocol stack and the Linux kernel protocol stack share a network interface, it may lead to resource conflicts and errors, affecting the user experience.
By obtaining the protocol type and target port number of network messages, it is decided to pass them to the user-state protocol stack or Linux kernel protocol stack for processing, avoiding port number conflicts and realizing message diversion.
It effectively avoids resource conflicts, improves the stability and processing performance of message shunts, and ensures that the two protocol stacks can work normally without conflict.
Smart Images

Figure CN2024073243_02012025_PF_FP_ABST
Abstract
Description
Message diversion method, network device and storage medium
[0001] Cross-references
[0002] This application claims priority to the Chinese patent application filed with the China Patent Office on June 26, 2023, with application number 202310764821.1 and application name “Message Diversion Method, Network Device and Storage Medium”. The entire contents of the application are incorporated by reference into this application. Technical Field
[0003] The present application relates to the field of communication technology, and in particular to a message diversion method, a network device, and a storage medium. Background Art
[0004] AF_XDP (Address Family eXpress Data Path) is an address family added to the Linux kernel starting with version 4.18. It provides high-performance data processing via AF_XDP sockets (XSK). Applications can therefore receive and send messages through the user-mode protocol stack, without having to call the traditional Linux kernel protocol stack.
[0005] However, when using virtual machines or containers, there is often only one network interface. If a user-mode protocol stack based on the Address Family eXpress Data Path (AF_XDP) and a Linux kernel protocol stack are used in this scenario, the two protocol stacks need to share the same network interface. Since the two protocol stacks share the same network interface, applications may actively establish UDP (User Datagram Protocol) or TCP (Transmission Control Protocol) connections on the two protocol stacks respectively. The local port numbers allocated by the two protocol stacks may conflict, resulting in resource conflicts and errors, and a poor user experience.
[0006] Summary of the Invention
[0007] The main purpose of the embodiments of the present application is to provide a message diversion method, network device and storage medium, aiming to solve the resource conflict problem faced when the user-mode protocol stack based on AF_XDP and the Linux kernel protocol stack share the network interface.
[0008] In a first aspect, an embodiment of the present application provides a message diversion method, the method comprising: obtaining a protocol type corresponding to a network message; if the protocol type is a first preset protocol type, obtaining a target port number corresponding to the network message; if the target port number belongs to a preset port number group, passing the network message to a corresponding user-mode protocol stack so that the user-mode protocol stack processes the network message; if the target port number does not belong to the preset port number group, passing the network message to a Linux kernel protocol stack so that the Linux kernel protocol stack processes the network message.
[0009] In a second aspect, an embodiment of the present application provides a network device, comprising: a processor, a memory, a computer program stored on the memory and executable by the processor, and a data bus for realizing connection and communication between the processor and the memory, wherein when the computer program is executed by the processor, the steps of the message diversion method as described above are implemented.
[0010] In a third aspect, an embodiment of the present application provides a storage medium for computer-readable storage, wherein the storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the steps of the message diversion method as described above. BRIEF DESCRIPTION OF THE DRAWINGS
[0011] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the description of the embodiments. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.
[0012] FIG1 is an exemplary block diagram of a structure using an XDP program to split two protocol stacks according to an embodiment of the present application;
[0013] FIG2 is an exemplary block diagram of the structure of a message diversion system based on AF_XDP provided in an embodiment of the present application;
[0014] FIG3 is a flow chart of a message diversion method provided in an embodiment of the present application;
[0015] FIG4 is a flowchart illustrating the steps of preparing an operating environment for an AF_XDP-based message diversion system according to an embodiment of the present application;
[0016] FIG5 is a flowchart illustrating the steps of allocating a local port number for a UDP / TCP connection by a user-mode protocol stack according to an embodiment of the present application;
[0017] FIG6 is a flowchart illustrating the steps of recording the port number of a UDP / TCP listening service in a user-mode protocol stack according to an embodiment of the present application;
[0018] FIG7 is a flow chart showing the working steps of a message diversion method provided in an embodiment of the present application;
[0019] FIG8 is a schematic block diagram of a message diversion device provided in an embodiment of the present application;
[0020] FIG9 is a schematic block diagram of the structure of a network device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0021] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.
[0022] The flowcharts shown in the accompanying drawings are for illustrative purposes only and do not necessarily include all contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps may be decomposed, combined, or partially merged, so the actual execution order may vary depending on the actual situation.
[0023] It should be understood that the terms used in this specification are only for the purpose of describing specific embodiments and are not intended to limit the present application. As used in this specification and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms unless the context clearly indicates otherwise.
[0024] The basic principle of AF_XDP is as follows: an application creates an AF_XDP socket (XSK), requests and registers a user-space memory area (UMEM), and constructs a receive queue (RX ring) and a transmit queue (TX ring) within this memory area. Simultaneously, the user develops an eXpress Data Path (XDP) program and uses the Extended Berkerly Packet Filter (eBPF) mechanism to inject the XDP program into the kernel. This XDP program determines whether packets received from the underlying layer should be redirected to the user-space memory area. The application reads packets from the XSK receive queue, completing network packet reception. The application places outgoing packets into the XSK transmit queue, completing network packet transmission. This allows the application to complete packet reception and transmission within the user-space protocol stack, eliminating the need to invoke the traditional Linux kernel protocol stack. In contrast, the Linux kernel's protocol stack has a lengthy packet processing flow, and the CPU frequently switches between kernel and user mode as packets are passed between the kernel protocol stack and the application, incurring significant CPU overhead.
[0025] Using AF_XDP sockets can improve the performance of network message processing. However, network messages sent and received through AF_XDP sockets are complete Ethernet messages, containing protocol message headers from multiple protocol layers, such as Ethernet headers, IP headers, UDP / TCP headers, and so on. Applications need to perform message parsing and processing at each protocol layer, which is usually performed by the protocol stack. Therefore, existing protocol stack code libraries (such as FreeBSD's protocol stack code library) are ported to user space, becoming user-mode protocol stacks, and are modified to replace their underlying data transmission and reception interfaces with AF_XDP socket operations. Upper-layer applications call the user-mode socket interface provided by the user-mode protocol stack to send and receive messages, rather than directly operating the underlying AF_XDP socket.
[0026] As shown in Figure 1, in a virtual machine or container scenario, there is often only one network interface. If both a user-mode protocol stack based on AF_XDP and a Linux kernel protocol stack are used in this scenario, the XDP program needs to determine which network packets are forwarded to the AF_XDP socket and which are still processed by the Linux kernel protocol stack. In particular, both protocol stacks may use UDP or TCP protocols, so they cannot be simply distinguished based on protocol type. Multiple programs may exist in the system, actively establishing UDP or TCP connections on each protocol stack, and the local port numbers independently allocated by the two protocol stacks may conflict. In addition, both protocol stacks may send ARP (Address Resolution Protocol) requests. Therefore, the system must ensure that both protocol stacks can obtain address resolution results.
[0027] Embodiments of the present application provide a message diversion method, network device, and storage medium. The method can be applied to a network device or a message diversion system based on AF_XDP, where the network device may be, but is not limited to, a server, a base station, or an operation and maintenance device. This method enables the AF_XDP-based user-mode protocol stack and the traditional Linux kernel protocol stack to share a network interface without resource conflicts, thereby avoiding resource conflicts and error reporting, and improving the stability of message diversion.
[0028] For example, as shown in Figure 2, the packet diversion method is applied to a packet diversion system based on AF_XDP. The packet diversion system includes a control program, an XDP program running in the Linux kernel, a Linux kernel protocol stack, a user-mode protocol stack, and an application.
[0029] The control program prepares the operating environment for other components of the message diversion system and is responsible for injecting the XDP program and setting system parameters and program configuration parameters. The XDP program is responsible for executing the diversion of received messages. The AF_XDP-based user-mode protocol stack provides applications with a user-mode socket interface for them to call when sending and receiving messages. This user-mode protocol stack enables upper-layer applications to send and receive messages in user mode, avoiding the frequent kernel-mode and user-mode switching required by the Linux kernel protocol stack when sending and receiving messages, thereby improving processing performance.
[0030] Applications use the user-mode socket interface provided by the user-mode protocol stack to send and receive messages, replacing the traditional Linux kernel protocol stack. Of course, applications can also use the Linux kernel protocol stack simultaneously, that is, support both protocol stacks simultaneously, using the user-mode protocol stack on some UDP / TCP connections and the Linux kernel protocol stack on other UDP / TCP connections.
[0031] Please refer to Figure 3, which is a flow chart of a message diversion method provided in an embodiment of the present application. This message diversion method can enable the user-mode protocol stack based on AF_XDP and the traditional Linux kernel protocol stack to share the network interface without resource conflicts, thereby avoiding the problem of error reporting due to resource conflicts and improving the stability of message diversion.
[0032] As shown in FIG3 , the message diversion method may include S101 to S104 .
[0033] S101: Obtain the protocol type corresponding to the network message.
[0034] The network message may be a message received by a network interface, and may specifically include an ARP message, a TCP message, a UDP message, etc. The protocol type corresponding to the network message may include a first preset protocol type and a second preset protocol type, etc., wherein the first preset protocol type may be a TCP / UDP protocol type, and the second preset protocol type may be an ARP protocol type.
[0035] Specifically, a network message is obtained from a network interface, and message information of the network message is parsed to determine the protocol type of the network message.
[0036] In some embodiments, after obtaining the protocol type corresponding to the network message, if the protocol type is a second preset protocol type, the target field information of the network message is obtained, and the ARP message type corresponding to the network message is determined based on the target field information; if the ARP message type corresponding to the network message is an ARP response type, the network message is redirected to the corresponding AF_XDP socket, so that the corresponding user-mode protocol stack receives the network message from the AF_XDP socket and processes the network message.
[0037] The target field information may be the op field in the message information. The op field may have multiple values: 1 indicates an ARP request; 2 indicates an ARP response; 3 indicates a RARP (Reverse Address Resolution Protocol) request; 4 indicates a RARP response, etc. The ARP message type may include an ARP response type, an ARP request type, a RARP request type, and a RARP response type.
[0038] Specifically, after determining that the protocol type corresponding to the network message is the ARP protocol type, if the ARP message type corresponding to the network message is not the ARP response type, the network message is passed to the Linux kernel protocol stack, so that the Linux kernel protocol stack processes the network message.
[0039] In some embodiments, the user-mode protocol stack updates its corresponding address resolution protocol table and calls the Linux kernel interface to update the corresponding address resolution protocol table in the Linux kernel protocol stack, thereby ensuring that both the user-mode protocol stack and the Linux kernel protocol stack can obtain the result of address resolution.
[0040] Specifically, after receiving the ARP response message, the user-mode protocol stack based on the AF_XDP socket updates its own ARP table based on the ARP response message, and calls the Linux kernel interface at the same time to update the ARP table of the Linux kernel protocol stack based on the ARP response message.
[0041] In some embodiments, after acquiring a network packet, if the protocol type is neither the first preset protocol type nor the second preset protocol type, the network packet is passed to the Linux kernel protocol stack so that the Linux kernel protocol stack processes the network packet. Thus, when the protocol type of the network packet is other types, the network packet can be accurately passed to the Linux kernel protocol stack so that the Linux kernel protocol stack processes the network packet.
[0042] Exemplarily, the network message is parsed to obtain the protocol type of the network message. If the protocol type is not a TCP / UDP protocol type and is not an ARP protocol type, for example, it is a NETBEUI (NetBIOS Extend User Interface) protocol type and an IPX / SPX (Internetwork Packet Exchange / Sequences Packet Exchange) protocol type, the network message is passed to the Linux kernel protocol stack so that the Linux kernel protocol stack processes the network message.
[0043] S102: If the protocol type is the first preset protocol type, obtain a target port number corresponding to the network message.
[0044] The first preset protocol type may be a TCP / UDP protocol type, and the target port number may be a destination port number of the network message.
[0045] Specifically, if it is determined that the protocol type of the network message is the first preset protocol type, the network message may be parsed to obtain a destination port number corresponding to the network message.
[0046] Exemplarily, if it is determined that the protocol type of the network message is the first preset protocol type, the field information corresponding to the destination port number in the network message can be obtained and parsed to obtain that the destination port number corresponding to the network message can be 12433.
[0047] In some embodiments, after obtaining the destination port number corresponding to the network message, it is determined whether the destination port number is a preset port number and whether the destination port number is within a preset port range; if the destination port number is the preset port number or is within the preset port range, it is determined that the destination port number belongs to the preset port number group; if the destination port number is not the preset port number and is not within the preset port range, it is determined that the destination port number does not belong to the preset port number group. In this way, it is possible to accurately determine whether the destination port number belongs to the preset port number group, thereby determining that the network message is assigned to the corresponding protocol stack for processing.
[0048] The preset port number may be a port number pre-configured by the user, or a port number pre-assigned for a UDP protocol type or a TCP protocol type. The preset port range may be a port number range pre-configured by the user, indicating that the port numbers within the range are the port numbers that need to be processed by the user-mode protocol stack.
[0049] For example, if the target port number is 12345, the preset port numbers include 41300 and 54500, and the preset port range is 10000-30000; at this time, it can be determined that the target port number is within the preset port range, and it can be determined that the target port number belongs to the preset port number group.
[0050] For example, if the target port number is 32345, the preset port numbers include 32345, 41300 and 54500, and the preset port range is 10000-30000; at this time, it can be determined that the target port number is the preset port number, and it can be determined that the target port number belongs to the preset port number group.
[0051] For example, if the target port number is 32345, the preset port numbers include 41300 and 54500, and the preset port range is 10000-30000; at this time, it can be determined that the target port number is not the preset port number and the target port number is not within the preset port range, then it can be determined that the target port number does not belong to the preset port number group.
[0052] S103: If the target port number belongs to the preset port number group, the network message is transferred to the corresponding user-mode protocol stack so that the user-mode protocol stack processes the network message.
[0053] Among them, the port number in the preset port number group can be a preset port number that needs to be processed by the user mode protocol stack, and the port number outside the preset port number group can be a preset port number that needs to be processed by the Linux kernel protocol stack.
[0054] In some embodiments, network packets are redirected to corresponding sockets so that the corresponding user-mode protocol stack receives the network packets from the AF_XDP socket and processes the network packets. This allows applications to send and receive packets in the user-mode protocol stack, avoiding the frequent kernel-mode and user-mode switching required by the Linux kernel protocol stack when sending and receiving packets, thereby improving processing performance.
[0055] Among them, using the XDP program to process the received message is a function of the Linux eBPF technology. The processing result types returned by the XDP program can include: XDP_ABORTED, XDP_DROP, XDP_PASS, XDP_TX, XDP_REDIRECT, etc.
[0056] For example, if the user-mode protocol stack receives a network packet from an AF_XDP socket and processes it, the returned processing result type is XDP_REDIERCT. Specifically, the bpf_redirect_map() interface can be called to determine whether to redirect the packet to the relevant AF_XDP socket based on the BPF map of type BPF_MAP_TYPE_XSKMAP.
[0057] S104: If the target port number does not belong to the preset port number group, the network message is passed to the Linux kernel protocol stack, so that the Linux kernel protocol stack processes the network message.
[0058] Exemplarily, if the Linux kernel protocol stack receives a network message and processes the network message, the returned processing result type is XDP_PASS, so that the Linux kernel protocol stack processes the network message.
[0059] As shown in Figures 2 and 4, Figure 4 is a flowchart illustrating the steps of a control program for preparing an operating environment for an AF_XDP-based message diversion system according to an embodiment of the present application. Specifically, the workflow of the control program for preparing an operating environment for an AF_XDP-based message diversion system will be described in conjunction with Figures 2 and 4, specifically including steps S201-S204.
[0060] S201. Set the local port range parameter in the Linux kernel parameters.
[0061] The control program sets the local port range parameters in the Linux kernel parameters so that they do not overlap with the local port range used by the user-mode protocol stack based on AF_XDP sockets. The Linux kernel parameters referred to here are generally stored in the / proc / sys / net / ipv4 / ip_local_port_range file in the Linux system. For example, setting the contents of this file to "20000 39999" means that the minimum local port number is 20000 and the maximum is 39999.
[0062] S202. Inject the XDP program into the Linux kernel.
[0063] Specifically, in order to enable the user-mode protocol stack based on the AF_XDP socket to receive messages, the control program is responsible for injecting the XDP program into the Linux kernel, and the XDP program diverts the network messages received by the network interface.
[0064] S203. Write the local port range used by the user-mode protocol stack into the BPF map.
[0065] The control program needs to write the local port range used by the user-mode protocol stack into the BPF map for use by the XDP program. The local port range used by the user-mode protocol stack does not overlap with the port range in the Linux kernel protocol stack. For example, if the local port range parameter of the user-mode protocol stack (i.e., the preset port range) is set to "40000 60000", the local port number allocated by the user-mode protocol stack will be as low as 40000 and as high as 60000.
[0066] S204: Setting local port range parameters for the user mode protocol stack when it is started.
[0067] Specifically, the control program sets a local port range parameter for the user-mode protocol stack based on the AF_XDP socket when it is started, and the parameter value is the same as that set in step 203. Accordingly, the user-mode protocol stack based on the AF_XDP socket supports the setting of this parameter.
[0068] It should be noted that part or all of the control program work may also be executed by the application or the user-mode protocol stack based on the AF_XDP socket itself when it is started, that is, they are coupled together.
[0069] In some embodiments, before determining whether the target port number is the preset port number, if the first preset protocol type is a UDP protocol type, the preset port number is determined from the listening service port number information corresponding to the UDP protocol type; if the first preset protocol type is a TCP protocol type, the preset port number is determined from the listening service port number information corresponding to the TCP protocol type. In this way, the preset port number can be accurately determined.
[0070] Specifically, you can first determine the specific protocol type of the network message. If the first preset protocol type is the UDP protocol type, obtain the listening service port number information corresponding to the UDP protocol type, and parse the preset port number from the listening service port number information; if the first preset protocol type is the TCP protocol type, obtain the listening service port number information corresponding to the TCP protocol type, and determine the preset port number from the listening service port number information corresponding to the TCP protocol type.
[0071] As shown in FIG5 , FIG5 is a flow chart of the working steps of allocating a local port number for a UDP / TCP connection by a user-mode protocol stack provided in an embodiment of the present application, specifically including S301 - S305 .
[0072] S301: The application program calls the user-mode protocol stack to initiate the establishment of a UDP or TCP connection.
[0073] Specifically, the application actively initiates the establishment of a UDP or TCP connection using a user-mode socket interface provided by a user-mode protocol stack based on the AF_XDP socket. That is, the application is the client of the UDP or TCP connection.
[0074] S302: The user-mode protocol stack allocates a local port number for the UDP / TCP connection.
[0075] The user-mode protocol stack based on the AF_XDP socket allocates a local port number for the UDP or TCP connection, and the value of the local port number does not exceed the local port range parameter configured by the control program.
[0076] S303: The application uses the user-mode socket interface provided by the user-mode protocol stack based on the AF_XDP socket to send and receive data.
[0077] S304: The application deletes the UDP or TCP connection using the user-mode socket interface provided by the user-mode protocol stack based on the AF_XDP socket.
[0078] S305: The user-mode protocol stack based on the AF_XDP socket reclaims the port number of the UDP / TCP connection.
[0079] As shown in FIG6 , FIG6 is a flowchart of the working steps of a user-mode protocol stack recording the port number of a UDP / TCP listening service provided by an embodiment of the present application, specifically including S401 - S405 .
[0080] S401: The application calls the user-mode protocol stack to establish a UDP or TCP listening service.
[0081] Specifically, when an application uses a user-mode socket interface provided by a user-mode protocol stack based on an AF_XDP socket to establish a UDP or TCP listening service, the application is the server end of the UDP or TCP connection.
[0082] S402: The user-mode protocol stack uses the BPF map to record the UDP / TCP listening port number (i.e., the preset port number).
[0083] Specifically, the user-mode protocol stack based on the AF_XDP socket records the listening service port number information using a BPF map for use by the XDP program.
[0084] The BPF maps are recorded as "User-mode protocol stack UDP listening port BPF map" and "User-mode protocol stack TCP listening port BPF map." These maps can also be combined into a single BPF map. It should be noted that these operations can also be performed within the application.
[0085] S403: The application uses the user-mode socket interface to accept client requests and send and receive data.
[0086] S404: The application program calls the user-mode protocol stack to stop the UDP or TCP listening service.
[0087] S405: The user-mode protocol stack based on the AF_XDP socket deletes the UDP / TCP listening port number of the listening service port from the BPF map.
[0088] It should be noted that in order to avoid conflicts, when the Linux kernel-mode protocol stack is used in the system to establish a UDP or TCP listening service, its service port number cannot be within the local port range of the user-mode protocol stack based on the AF_XDP socket. This is avoided during port number planning.
[0089] As shown in Figure 7, Figure 7 is a flowchart of the working steps of a message diversion method provided by an embodiment of the present application. Specifically, the following describes the working process of the message diversion method provided by an embodiment of the present application in conjunction with Figure 7, including:
[0090] S501: The XDP program receives a message and parses the protocol type of the message.
[0091] S502: Determine whether the protocol type is the ARP protocol type.
[0092] If yes, jump to S503; if no, jump to S505.
[0093] S503: Determine whether the ARP message type is an ARP response type.
[0094] If yes, jump to S504; if no, jump to S509.
[0095] S504: The XDP program redirects the message to the corresponding AF_XDF socket.
[0096] S505: Determine whether the protocol type is UDP / TCP protocol type.
[0097] If yes, jump to S506; if no, jump to S509.
[0098] S506: The XDP program parses the target port number corresponding to the network message.
[0099] S507: Whether it is a user mode protocol stack listening service port.
[0100] If yes, jump to S510; if no, jump to S508.
[0101] S508: Is it within the local port range of the user mode protocol stack?
[0102] If yes, jump to S510; if no, jump to S509.
[0103] S509: The XDP program sends the message to the Linux kernel protocol stack for processing.
[0104] S510 : The XDP program redirects the message to the corresponding AF_XDF socket.
[0105] It should be noted that the embodiments of the present application do not limit the actual code implementation of the XDP program. In actual coding, the execution order of the XDP program can be adjusted, more other functions can be implemented, and it can also cooperate with other eBPF programs for execution.
[0106] Please refer to FIG8 , which is a schematic block diagram of a message diversion device provided in an embodiment of the present application. The message diversion device can be configured in a server to execute the aforementioned message diversion method.
[0107] As shown in FIG8 , the message diversion device 600 includes: a protocol type determination module 601 , a port number acquisition module 602 , a first message processing module 603 , and a second message processing module 604 .
[0108] The protocol type determination module 601 is used to obtain the protocol type corresponding to the network message.
[0109] The port number acquisition module 602 is configured to acquire a target port number corresponding to the network message if the protocol type is a first preset protocol type.
[0110] The first message processing module 603 is configured to transfer the network message to a corresponding user-mode protocol stack if the target port number belongs to a preset port number group, so that the user-mode protocol stack processes the network message.
[0111] The second message processing module 604 is configured to transfer the network message to the Linux kernel protocol stack if the target port number does not belong to the preset port number group, so that the Linux kernel protocol stack processes the network message.
[0112] The port number group identification module 605 is used to determine whether the target port number is the preset port number and whether the target port number is within the preset port range; if the target port number is the preset port number or the target port number is within the preset port range, it is determined that the target port number belongs to the preset port number group; if the target port number is not the preset port number and the target port number is not within the preset port range, it is determined that the target port number does not belong to the preset port number group.
[0113] The port number group identification module 605 is also used to determine the preset port number from the listening service port number information corresponding to the UDP protocol type if the first preset protocol type is the UDP protocol type; if the first preset protocol type is the TCP protocol type, determine the preset port number from the listening service port number information corresponding to the TCP protocol type.
[0114] The first message processing module 603 is further configured to redirect the network message to a corresponding socket, so that the corresponding user-mode protocol stack receives the network message from the AF_XDP socket and processes the network message.
[0115] The third message processing module 606 is used to obtain the target field information of the network message if the protocol type is the second preset protocol type, and determine the ARP message type corresponding to the network message based on the target field information; if the ARP message type corresponding to the network message is an ARP response type, redirect the network message to the corresponding AF_XDP socket, so that the corresponding user-mode protocol stack receives the network message from the AF_XDP socket and processes the network message.
[0116] The third message processing module 606, the user mode protocol stack is further used to update its corresponding address resolution protocol table, and call the Linux kernel interface to update the corresponding address resolution protocol table in the Linux kernel protocol stack.
[0117] The third message processing module 606 is further configured to, if the ARP message type corresponding to the network message is not an ARP response type, pass the network message to the Linux kernel protocol stack so that the Linux kernel protocol stack processes the network message.
[0118] The fourth message processing module 607 is configured to transfer the network message to the Linux kernel protocol stack if the protocol type is neither the first preset protocol type nor the second preset protocol type, so that the Linux kernel protocol stack processes the network message.
[0119] It should be noted that those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described devices and modules and units can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.
[0120] The methods and apparatus of the present application can be used in a wide variety of general-purpose or specialized computing system environments or configurations, such as personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer network devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above.
[0121] Please refer to FIG9 , which is a schematic block diagram of the structure of a network device provided in an embodiment of the present application.
[0122] As shown in FIG9 , a network device 700 may include a processor 701 and a memory 702 . The processor 701 and the memory 702 are connected via a bus 703 , such as an I 2 C (Inter-Integrated Circuit) bus.
[0123] In an exemplary embodiment, processor 701 can be used to provide computing and control capabilities to support the operation of the entire network device. Processor 701 can be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.
[0124] Specifically, the memory 702 may be a Flash chip, a read-only memory (ROM) disk, an optical disk, a USB flash drive, or a mobile hard disk.
[0125] Those skilled in the art will understand that the structure shown in Figure 9 is merely a block diagram of a partial structure related to the embodiment of the present application, and does not constitute a limitation on the network device to which the embodiment of the present application is applied. The specific server may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.
[0126] The processor 701 is configured to run a computer program stored in the memory and implement any one of the message diversion methods provided in the embodiments of the present application when executing the computer program.
[0127] In one embodiment, the processor 701 is used to run a computer program stored in a memory, and implement the following steps when executing the computer program: obtaining a protocol type corresponding to a network message; if the protocol type is a first preset protocol type, obtaining a target port number corresponding to the network message; if the target port number belongs to a preset port number group, passing the network message to a corresponding user-mode protocol stack so that the user-mode protocol stack processes the network message; if the target port number does not belong to the preset port number group, passing the network message to a Linux kernel protocol stack so that the Linux kernel protocol stack processes the network message.
[0128] In one embodiment, the preset port number group includes a preset port number and a preset port range; after obtaining the target port number corresponding to the network message, the processor 701 is used to: determine whether the target port number is the preset port number, and determine whether the target port number is within the preset port range; if the target port number is the preset port number or the target port number is within the preset port range, determine that the target port number belongs to the preset port number group; if the target port number is not the preset port number and the target port number is not within the preset port range, determine that the target port number does not belong to the preset port number group.
[0129] In one embodiment, the first preset protocol type is a UDP protocol type or a TCP protocol type. Before determining whether the target port number is the preset port number, the processor 701 is used to implement: if the first preset protocol type is a UDP protocol type, then determine the preset port number from the listening service port number information corresponding to the UDP protocol type; if the first preset protocol type is a TCP protocol type, then determine the preset port number from the listening service port number information corresponding to the TCP protocol type.
[0130] In one embodiment, when the processor 701 passes the network message to the corresponding user-mode protocol stack so that the user-mode protocol stack processes the network message, it is used to implement: redirecting the network message to the corresponding socket so that the corresponding user-mode protocol stack receives the network message from the AF_XDP socket and processes the network message.
[0131] In one embodiment, after obtaining the protocol type corresponding to the network message, the processor 701 is used to implement: if the protocol type is a second preset protocol type, obtain the target field information of the network message, and determine the ARP message type corresponding to the network message based on the target field information; if the ARP message type corresponding to the network message is an ARP response type, redirect the network message to the corresponding AF_XDP socket, so that the corresponding user-mode protocol stack receives the network message from the AF_XDP socket and processes the network message.
[0132] In one embodiment, when the processor 701 implements the user-mode protocol stack receiving the network message from the AF_XDP socket and processing the network message, it is used to implement: the user-mode protocol stack updates its corresponding address resolution protocol table, and calls the Linux kernel interface to update the corresponding address resolution protocol table in the Linux kernel protocol stack.
[0133] In one embodiment, after determining the ARP message type corresponding to the network message according to the target field information, the processor 701 is used to implement: if the ARP message type corresponding to the network message is not an ARP response type, the network message is passed to the Linux kernel protocol stack so that the Linux kernel protocol stack processes the network message.
[0134] In one embodiment, after obtaining the network message, the processor 701 is used to implement: if the protocol type is not the first preset protocol type and is not the second preset protocol type, the network message is passed to the Linux kernel protocol stack so that the Linux kernel protocol stack processes the network message.
[0135] It should be noted that those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the network device described above can refer to the corresponding process in the aforementioned message diversion method embodiment, and will not be repeated here.
[0136] An embodiment of the present application also provides a storage medium for computer-readable storage, wherein the storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the steps of any message diversion method provided in the description of the embodiment of the present application.
[0137] The storage medium may be an internal storage unit of the network device described in the aforementioned embodiment, such as a hard disk or memory of the network device. The storage medium may also be an external storage device of the network device, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the network device.
[0138] It will be appreciated by those skilled in the art that all or some of the steps, systems, and functional modules / units in the methods disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. In a hardware embodiment, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed by several physical components in cooperation. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or temporary medium). As is well known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable, and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc-read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, it is well known to those skilled in the art that communication media generally embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.
[0139] It should be understood that the term "and / or" used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, including these combinations. It should be noted that, in this article, the terms "include", "comprise" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or system that includes a series of elements includes not only those elements, but also includes other elements that are not explicitly listed, or also includes elements that are inherent to such process, method, article or system. In the absence of further restrictions, an element defined by the sentence "including a..." does not exclude the presence of other identical elements in the process, method, article or system that includes the element.
[0140] The serial numbers of the embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments. The above are only specific embodiments of the present application, but the scope of protection of the present application is not limited thereto. Any person skilled in the art can easily think of various equivalent modifications or replacements within the technical scope disclosed in the present application, and these modifications or replacements should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application shall be based on the scope of protection of the claims.
Claims
1. A message diversion method, the method comprising: Get the protocol type corresponding to the network message; If the protocol type is the first preset protocol type, obtaining a target port number corresponding to the network message; If the target port number belongs to the preset port number group, the network message is transmitted to the corresponding user state protocol stack so that the user state protocol stack processes the network message; If the target port number does not belong to the preset port number group, the network message is transferred to the Linux kernel protocol stack so that the Linux kernel protocol stack processes the network message.
2. The method according to claim 1, wherein: The preset port number group includes a preset port number and a preset port range; after obtaining the target port number corresponding to the network message, the method further includes: Determine whether the target port number is the preset port number, and determine whether the target port number is within the preset port range; If the target port number is the preset port number or the target port number is within the preset port range, determining that the target port number belongs to the preset port number group; If the target port number is not the preset port number and the target port number is not within the preset port range, it is determined that the target port number does not belong to the preset port number group.
3. The method according to claim 2, wherein: The first preset protocol type is a UDP protocol type or a TCP protocol type, and before determining whether the target port number is the preset port number, the method further includes: If the first preset protocol type is a UDP protocol type, determining the preset port number from the listening service port number information corresponding to the UDP protocol type; If the first preset protocol type is a TCP protocol type, the preset port number is determined from the listening service port number information corresponding to the TCP protocol type.
4. The method according to claim 1 or 2, wherein: The delivering the network message to the corresponding user-mode protocol stack so that the user-mode protocol stack processes the network message includes: The network message is redirected to the corresponding socket, so that the corresponding user-mode protocol stack receives the network message from the AF_XDP socket and processes the network message.
5. The method according to claim 1, wherein: After obtaining the protocol type corresponding to the network message, the method further includes: If the protocol type is the second preset protocol type, obtaining target field information of the network message, and determining the ARP message type corresponding to the network message according to the target field information; If the ARP message type corresponding to the network message is an ARP response type, the network message is redirected to the corresponding AF_XDP socket, so that the corresponding user-mode protocol stack receives the network message from the AF_XDP socket and processes the network message.
6. The method according to claim 5, wherein: The user mode protocol stack receives the network message from the AF_XDP socket and processes the network message, including: The user mode protocol stack updates its corresponding address resolution protocol table, and calls the Linux kernel interface to update the corresponding address resolution protocol table in the Linux kernel protocol stack.
7. The method according to claim 5, wherein: After determining the ARP message type corresponding to the network message according to the target field information, the method further includes: If the ARP message type corresponding to the network message is not an ARP response type, the network message is transferred to the Linux kernel protocol stack so that the Linux kernel protocol stack processes the network message.
8. The method according to claim 1, wherein: After obtaining the network message, the method further includes: If the protocol type is neither the first preset protocol type nor the second preset protocol type, the network message is transferred to the Linux kernel protocol stack so that the Linux kernel protocol stack processes the network message.
9. A network device, comprising: A processor, a memory, a computer program stored in the memory and executable by the processor, and a data bus for realizing connection and communication between the processor and the memory, wherein when the computer program is executed by the processor, the reporting method according to any one of claims 1 to 8 is realized. Steps of text diversion method.
10. A storage medium for computer-readable storage, wherein the storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the steps of the message diversion method according to any one of claims 1 to 8.
Citation Information
Patent Citations
Method and devices for processing data messages
CN109547580A
Message distribution method, device and system based on user state protocol stack
CN110278161A
Method and device for realizing high-performance DNS service, computer equipment and storage medium
CN114401245A
Data processing method and device, nonvolatile storage medium and computer equipment
CN115665057A
Method and apparatus for processing data packet
US20220078120A1
Cited By
Data transmission method and system based on fast network protocol stack
CN120075318A
Unidirectional isolation optical shutter equipment and data transfer method thereof
CN120090853A
Health check method, device and equipment based on user mode protocol stack and storage medium
CN120474954A
Method and apparatus for simultaneously supporting bridge forwarding and proxy forwarding in transparent mode
CN120880803A
