WO2022267815A1 - 数据包过滤方法和装置、电子设备、和计算机可读存储介质 - Google Patents

数据包过滤方法和装置、电子设备、和计算机可读存储介质 Download PDF

Info

Publication number
WO2022267815A1
WO2022267815A1 PCT/CN2022/095438 CN2022095438W WO2022267815A1 WO 2022267815 A1 WO2022267815 A1 WO 2022267815A1 CN 2022095438 W CN2022095438 W CN 2022095438W WO 2022267815 A1 WO2022267815 A1 WO 2022267815A1
Authority
WO
WIPO (PCT)
Prior art keywords
data packet
tipc
ebpf
program
data
Prior art date
Application number
PCT/CN2022/095438
Other languages
English (en)
French (fr)
Inventor
郭天
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2022267815A1 publication Critical patent/WO2022267815A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2483—Traffic characterised by specific attributes, e.g. priority or QoS involving identification of individual flows
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0263—Rule management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • the embodiments of the present application relate to the technical field of the Internet, and in particular to a data packet filtering method and device, electronic equipment, and a computer-readable storage medium.
  • Transparent Inter-process Communication (TIPC, Transparent Inter-process Communication) protocol is a network communication protocol for inter-process communication. Originally developed by Ericsson for inter-application communication within telecom clusters. Later, it was gradually open sourced and incorporated into the kernels of operating systems such as Linux and VxWorks, enabling developers to create fast and reliable communication channels between multiple applications without considering the physical location of the applications in the cluster environment.
  • the embodiment of the present application provides a data packet filtering method, including:
  • the loaded extended Berkeley packet filter (eBPF, extended Berkeley Packet Filter) program recognizes that the data packet that the kernel needs to transmit is a transparent inter-process communication (TIPC, Transparent Inter-process Communication) data packet, through the The eBPF program matches the data packet with a preset filtering rule to obtain a matching result; and
  • TIPC transparent Inter-process Communication
  • the data packet is determined to be filtered according to the matching result by the eBPF program.
  • an electronic device including:
  • a memory where at least one computer program is stored on the memory, and when the at least one computer program is executed by the at least one processor, the above data packet filtering method is implemented.
  • an embodiment of the present application provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the foregoing data packet filtering method is implemented.
  • the embodiment of the present application provides a data packet filtering device, including:
  • the matching module is configured to match the data packet with the pre-set Match the filter rules to get the matching result
  • a processing module configured to determine to filter the data packet according to the matching result through the eBPF program.
  • FIG. 1 is a schematic diagram of an underlying bearer mode supported by a transparent inter-process communication (TIPC) protocol in the related art;
  • TIPC transparent inter-process communication
  • Fig. 2 is the flowchart of the packet filtering method provided by the embodiment of the present application.
  • Fig. 3 is the structural representation of the data packet that the extended Berkeley Packet Filter (eBPF) program reads from the memory buffer under the situation that the underlying bearer mode of TIPC is the Ethernet bearer mode provided by the embodiment of the application;
  • eBPF extended Berkeley Packet Filter
  • Fig. 4 is provided in the embodiment of the present application under the situation that the underlying bearer mode of TIPC is User Datagram Protocol (UDP) bearer mode, the structural representation of the data packet of Internet protocol version 4 (IPV4) agreement;
  • UDP User Datagram Protocol
  • IPV4 Internet protocol version 4
  • FIG. 5 is a schematic structural diagram of a data packet of the sixth edition of the Internet Protocol (IPV6) protocol provided by the embodiment of the present application when the underlying bearer mode of TIPC is a UDP bearer mode;
  • IPV6 Internet Protocol
  • FIG. 6 is a schematic structural diagram of a TIPC data packet of a payload type provided by an embodiment of the present application.
  • FIG. 7 is a schematic structural diagram of a TIPC data packet of an internal control type provided by an embodiment of the present application.
  • FIG. 8 is a block diagram of a data packet filtering device provided by an embodiment of the present application.
  • FIG. 9 is a schematic diagram of an implementation manner of a data packet filtering device provided in an embodiment of the present application.
  • FIG. 10 is a schematic diagram of deployment of a data packet filtering device provided by an embodiment of the present application.
  • FIG. 11 is a schematic diagram of a deployment of a data packet filtering device provided by an embodiment of the present application.
  • FIG. 12 is a schematic diagram of a deployment of a data packet filtering device provided by an embodiment of the present application.
  • FIG. 13 is a flow chart of the work and processing of the management module in the data packet filtering device provided by the embodiment of the present application.
  • FIG. 14 is a flow chart of the working process of the eBPF program module in the data packet filtering device provided by the embodiment of the present application.
  • TIPC Transparent Inter-process Communication
  • Each service has its own address (the service is located not by socket but by address);
  • Service status tracking applications can subscribe to service status, and can receive notifications when the service address is bound or unbound to the underlying socket and other status changes);
  • IPC Inter-Process Communication
  • Cluster topology state tracking (applications can subscribe to topology state change messages, and will receive notifications when new nodes are added or lost in the cluster);
  • Node link status tracking the application can subscribe to the node link status change message, and will receive a notification when the link between nodes is connected or disconnected);
  • the cluster can automatically discover new nodes
  • a cluster with a scale of 1,000 nodes can detect node abnormalities with a second-level response speed
  • FIG. 1 is a schematic diagram of an underlying bearer mode supported by the TIPC protocol in the related art.
  • the TIPC protocol currently mainly supports two underlying bearers: Ethernet (Ethernet) bearer mode and User Datagram Protocol (UDP, User Datagram Protocol) bearer mode.
  • Ethernet belongs to layer 2 (that is, the transmission link layer in Figure 1, that is, Media Access Control (MAC, Media Access Control) ) layer
  • UDP belongs to layer 4 (that is, the transport layer in Figure 1, that is, the UDP layer).
  • TIPC can work directly on layer 2 without relying on layer 3 and layer 4 protocols (ie, Internet Protocol (IP, Internet Protocol) and Transmission Control Protocol (TCP, Transmission Control Protocol)/UDP). Better performance can also be obtained under this configuration. However, for compatibility reasons, in some scenarios, it may still be necessary to use the functions provided by layer 3 and layer 4 (such as Internet Protocol Security (IPSec, Internet Protocol Security), routing, etc.), so TIPC also supports running at the UDP layer above. When using the UDP layer as the underlying bearer, the communication parties need to configure the UDP port number used by the TIPC traffic.
  • IP Internet Protocol
  • TCP Transmission Control Protocol
  • UDP Transmission Control Protocol
  • TIPC lies in its simple and flat service addressing method and excellent transmission delay performance.
  • the official performance test shows that, in the scenario of using the Ethernet bearer mode, compared with TCP, TIPC can reduce the inter-node communication delay by nearly 33%, the intra-node small message communication delay by nearly 66%, and the large message communication time. Delay was reduced by nearly 87%. Due to the above-mentioned advantages of TIPC, it is widely used in carrier-class services that have high requirements on transmission reliability and transmission delay.
  • TIPC In the early design of TIPC, it was mainly aimed at the telecom cluster scenario of the internal private network, without much consideration for security-related content. However, with the increasingly severe network security environment, higher security requirements are put forward for any network communication plane in the system.
  • TIPC currently does not have any built-in data transmission encryption function, but this function can be implemented indirectly through the underlying protocol it depends on (MACSec, Media Access Control Security) or IPSec, corresponding to the configuration of layer 2 and layer 4 respectively scenarios); and the inspection and filtering of data packets (that is, commonly known as firewalls), is still insufficient at present: many current mainstream Linux firewall systems rely on the iptable subsystem in the kernel to achieve traffic filtering, but iptables cannot recognize and Filter TIPC protocol traffic, so the current mainstream firewall systems attempt to filter TIPC traffic through service addresses or other protocol fields, which is difficult to achieve.
  • FIG. 2 is a flowchart of a data packet filtering method provided by an embodiment of the present application.
  • the embodiment of the present application provides a data packet filtering method, including steps S200 and S201.
  • Step 200 in the case that the loaded extended Berkeley Packet Filter (eBPF, extended Berkeley Packet Filter) program identifies the data packet as a TIPC data packet, match the data packet with the preset filtering rules through the eBPF program to obtain a match result.
  • eBPF extended Berkeley Packet Filter
  • the kernel may be the kernel of a device that executes the data packet filtering method of the embodiment of the present application.
  • the kernel can also be the kernel of the dedicated hardware of the device implementing the data packet filtering method of the embodiment of the present application, where the dedicated hardware can be a computing card with a USB interface, an intelligent network card, and a dedicated firewall hardware platform.
  • the device implementing the data packet filtering method of the embodiment of the present application may be any device, such as a service node, or a dedicated network processing device, such as a switch, a router, and the like.
  • the initial goal of the birth of eBPF mentioned in the embodiment of this application is to implement a brand new packet filter to replace iptable, but the subsequent evolution has expanded the functions of eBPF, and now eBPF is essentially a
  • users can write functional codes under specified restrictions, and these functional codes can be loaded into the kernel for execution after compilation.
  • the kernel will check the type, semantics, and other legality of the eBPF program to ensure that the eBPF program does not have defects that may cause hangs or crashes.
  • the kernel will also perform some other protection measures to prevent the eBPF program from crashing. In terms of performance, since the eBPF program runs in the kernel state, it does not need to interact frequently with the user plane program. Theoretically, the performance of the eBPF program is equivalent to that of the traditional kernel module.
  • eBPF supports a variety of program types. Different types of eBPF programs are suitable for different purposes.
  • the program types for network traffic processing are traffic control (TC, Traffic Control) or fast data path (XDP, eXpress Data Path).
  • TC traffic control
  • XDP fast data path
  • the TC-type eBPF program can directly intercept the processing entry and exit of the Linux kernel for network data packets. Before the kernel receives or sends the data packets, the TC-type eBPF program can directly access the most original network data packet cache. After the data packet is processed (such as analysis, modification, statistics, etc.), it is handed over to the kernel to complete other processing.
  • the working principle of the XDP-type eBPF program is similar to that of the TC-type eBPF program, except that the kernel has specially optimized the path of the XDP-type eBPF program, making the XDP-type eBPF program process data packets more efficiently, but currently XDP-type eBPF programs can only process incoming packets, that is, packets received by the kernel.
  • the kernel when the kernel has data packets to transmit, the kernel will call the loaded eBPF program, and pass the memory buffer address of the data packet to be transmitted to the eBPF program, and the eBPF program can The address reads the packet to be transmitted by the kernel from the memory buffer.
  • transmitting includes at least one of: sending, receiving.
  • the flow of the data packet filtering method ends.
  • identifying whether the data packet is a transparent inter-process communication TIPC data packet through the eBPF program includes:
  • the eBPF program is used to identify whether the data packet is a TIPC data packet according to the information characterizing the underlying bearer mode of the TIPC.
  • the information representing the underlying carrying mode of TIPC may be included in the eBPF program when generating the eBPF program, that is, the information representing the underlying carrying mode of TIPC is embedded in the global code template when generating the eBPF program In the data area, then call the compilation tool (such as clang) to compile and output the eBPF program according to the code template.
  • the eBPF program can directly obtain the information representing the underlying carrying mode of TIPC in the code.
  • This method is used to represent the information representing the underlying carrying mode of TIPC
  • This method does not require memory allocation or system calls, so it is more efficient at runtime; it can also be an eBPF program
  • the information representing the underlying carrying mode of TIPC is passed to the eBPF program through the communication mechanism between eBPF and the user plane.
  • the eBPF program needs to read the underlying carrying mode representing TIPC through system calls or auxiliary functions of the bpf library information, this method does not need to regenerate a new eBPF program when the information representing the underlying bearer mode of TIPC changes, it only needs to pass the new underlying bearer mode of TIPC to the eBPF program, but this method requires Memory allocation and system calls are executed, so the runtime is less efficient.
  • clang is a C/C++ language compiler, and currently the compiler supports outputting eBPF program bytecodes.
  • the communication mechanism between eBPF and the user plane may be any achievable communication mechanism, for example, the data transmission may be realized through the bpf_map object.
  • identifying whether the data packet is a TIPC data packet according to the information characterizing the underlying bearer mode of the TIPC through the eBPF program includes:
  • the frame type is obtained by parsing the Ethernet frame header of the data packet through the eBPF program.
  • the eBPF program judges whether the data packet is a TIPC data packet according to the frame type.
  • the information representing the underlying bearer mode of TIPC is the information representing the bearer mode of Ethernet, it means that the TIPC protocol is above the Ethernet protocol, and there is no other protocol in the middle.
  • the eBPF program The structure of the data packet read from the memory buffer is shown in Figure 3, including an Ethernet frame header and a payload, and the Ethernet frame header includes: a destination MAC address, a source MAC address, and a frame type. The eBPF program needs to offset the data buffer pointer by 12 bytes, and then read 2 bytes to obtain the frame type.
  • the frame type corresponding to the TIPC protocol is 0x88CA. Therefore, if the frame type obtained by the eBPF program is 0x88CA, it means that the payload part is TIPC data; if the frame obtained by the eBPF program If the type is not 0x88CA, it means that the payload part is not TIPC data.
  • identifying the data packet as a TIPC data packet according to the information characterizing the underlying bearer mode of the TIPC through the eBPF program includes:
  • the UDP port number is obtained by parsing the Ethernet frame header, IP header and UDP header of the data packet in sequence through the eBPF program;
  • the information representing the underlying bearer mode of TIPC is the information representing the UDP bearer mode, it means that there are IP protocol and UDP protocol above the Ethernet protocol, and then the TIPC protocol .
  • the IP protocol is divided into the fourth version of the Internet Protocol (IPV4, Internet Protocol Version 4) protocol and the sixth version of the Internet Protocol (IPV6, Internet Protocol Version 6) protocol, the frame type of the Ethernet frame corresponding to the IPV4 protocol is 0x0800, and the IPV6 protocol
  • the frame type of the corresponding Ethernet frame is 0x86DD, and the data packet of the IP protocol can be identified according to the frame type of IPV4 and the frame type of IPV6; there is also a load type indication in the IP protocol header, as shown in Figure 4 and Figure 5, the UDP protocol
  • the payload type of the UDP protocol is 0x11.
  • the data packet of the UDP protocol can be identified from the data packet of the IP protocol; the UDP protocol header includes the source port number and the destination port number. According to the source port number in the UDP protocol header and the destination port number can determine whether the payload part in the UDP data packet is TIPC data. That is to say, the UDP port number described above includes a source port number and a destination port number.
  • judging whether the load part in the UDP packet is TIPC data according to the source port number and the destination port number in the UDP protocol header includes:
  • the payload part in the UDP data packet is TIPC data, that is to say, the data packet described above is a TIPC data packet;
  • the payload part in the UDP data packet is not TIPC data, that is to say, the data packet described above is not a TIPC data packet.
  • the UDP port number used by TIPC may be included in the eBPF program when the eBPF program is generated, that is, the UDP port number used by TIPC is embedded in the global data area of the code template when the eBPF program is generated, Then call the compilation tool (such as clang) to compile and output the eBPF program according to the code template.
  • the eBPF program can directly access the UDP port number used by TIPC in the code. In this way, it needs to be regenerated when the UDP port number used by TIPC changes.
  • a new eBPF program, and reload the newly generated eBPF program into the kernel does not require memory allocation or system calls, so it is more efficient at runtime; it can also be after the eBPF program is loaded into the kernel, through
  • the communication mechanism between eBPF and the user plane passes the UDP port number used by TIPC to the eBPF program.
  • the eBPF program needs to read the UDP port number used by TIPC through system calls or auxiliary functions of the bpf library. This method is implemented in TIPC When the UDP port number used changes, there is no need to regenerate a new eBPF program. It is only necessary to pass the new UDP port number used by TIPC to the eBPF program. However, this method requires memory allocation and execution of system calls. So the runtime is less efficient.
  • the process of eBPF program identifying TIPC data packets is as follows:
  • the eBPF program offsets the data buffer pointer by 12 bytes, and then reads 2 bytes to obtain the frame type. If the frame type obtained by the eBPF program is 0x0800, it means that the payload part is IPV4 data; if the frame type obtained by the eBPF program is 0x86DD, it means that the payload part is IPV6 data.
  • the eBPF program will offset the data cache pointer by 9 bytes and then read 1 byte to obtain the payload type. If the eBPF program obtains If the payload type is 0x11, the eBPF program shifts the data cache pointer by 2 bytes and reads 4 bytes to obtain the source port number and destination port number of the UDP protocol.
  • the source port number and destination port number obtained by the eBPF program If the port number is within the UDP port number used by TIPC, it means that the payload part is TIPC data; if the source port number or destination port number obtained by the eBPF program is not in the UDP port number used by TIPC, it means that the payload part is not TIPC data .
  • the eBPF program will offset the data buffer pointer by 39 bytes and then read 1 byte to obtain the payload type. If the eBPF program obtains If the payload type is 0x11, the eBPF program can read 4 more bytes to obtain the source port number and destination port number of the UDP protocol. If the source port number and destination port number obtained by the eBPF program are both in the UDP port number used by TIPC If the source port number or destination port number obtained by the eBPF program is not within the UDP port number used by TIPC, it means that the payload part is not TIPC data.
  • matching the data packets with preset filtering rules through the eBPF program to obtain matching results includes:
  • the feature information is matched with the filtering rules through the eBPF program to obtain the matching result.
  • TIPC has 8 kinds of data packets of payload types and 9 kinds of data packets of internal control types, and the data packets of payload types share the same protocol header format, as shown in Figure 6, the internal control Packets of type also share the same protocol header format, as shown in Figure 7.
  • the TIPC protocol provides four addressing methods: port number, port name, port name sequence, and network address. Any addressing method can accurately locate one or more communication terminals in the TIPC cluster network.
  • the purpose category (User) and subtype information (MType) of the data packet can be obtained from the first two words (Word) of the protocol header. According to the purpose category and subtype information, it can be determined that a TIPC data packet is a data packet of the payload type. It is still a data packet of the internal control type, and then judges which addressing mode the TIPC data packet uses.
  • a word contains 4 bytes.
  • the feature information may be at least one of the source service address, the destination service address, and the like.
  • the service address (source service address or destination service address) may be at least one of port number, port name, port name range, network address, node number, and the like.
  • the characteristic information obtained by parsing the TIPC protocol header of the data packet through the eBPF program includes:
  • the filtering rules may be included in the eBPF program when the eBPF program is generated, that is, the filtering rules are embedded in the global data area of the code template when the eBPF program is generated, and then the eBPF program is generated according to the code template.
  • the eBPF program The filtering rules can be directly accessed in the code.
  • the communication mechanism between eBPF and the user plane may be any achievable communication mechanism, for example, data transmission may be realized through the bpf_map object.
  • the bpf_map object used to transfer the information representing the underlying bearer mode of TIPC and the bpf_map object used to transfer the filtering rules may be the same object or different objects, and the filtering rules may also be It can be passed by two or more bpf_map objects, and the data passed by each bpf_map object can be preset.
  • Step 201 determine to filter the data packet according to the matching result through the eBPF program.
  • determining by the eBPF program to filter the data packet according to the matching result includes at least one of the following:
  • the data packet matching the filtering rules means that the data packet matches any filtering rule
  • the data packet not matching the filtering rules means that the data packet does not match all the filtering rules.
  • the data packet matches the filter rule, that is, the feature information matches the filter rule, and the data packet does not match the filter rule, that is, the feature information does not match the filter rule.
  • blocking the data packet means that the kernel is not allowed to perform any subsequent processing on the data packet, and the eBPF program can notify the kernel to discard the data packet; releasing the data packet means allowing the kernel to subsequently process the data packet.
  • the eBPF program can notify the kernel to process the packet.
  • the packet filtering method also includes:
  • the configuration data includes filtering rules
  • the configuration data further includes at least one of the following: information characterizing the underlying bearer mode of the TIPC, and the UDP port number used by the TIPC.
  • the generated eBPF program includes configuration data.
  • the packet filtering method also includes:
  • the eBPF program upon receiving the firewall activation instruction, is loaded into the kernel.
  • the packet filtering method also includes:
  • the packet filtering method also includes:
  • the running status data of the eBPF program is read through the communication mechanism between eBPF and the user plane, and the read running status data of the eBPF program is displayed.
  • the communication mechanism between eBPF and the user plane can be any achievable communication mechanism, such as realizing data transfer through the bpf_map object, that is, the eBPF program needs to pass the system call or the bpf library Auxiliary function to write running status data to bpf_map object.
  • the operating status data includes at least one of the following:
  • the number of times the filter rule is triggered the number of times it is blocked, the number of times it is released, and the number of filtered data packets, etc.
  • the packet filtering method also includes:
  • the eBPF program When a stop command is received, the eBPF program is unloaded from the kernel and terminates its own operation.
  • the packet filtering method also includes:
  • a new eBPF program is generated according to the new configuration data;
  • the new configuration data includes: new filtering rules;
  • the new configuration data further includes: new information characterizing the underlying bearer mode of the TIPC.
  • the new eBPF program includes new filtering rules and new information representing the underlying bearer mode of the TIPC.
  • the packet filtering method also includes:
  • a new eBPF program is generated according to new configuration data. If the current firewall is activated, reload the new eBPF program into the kernel.
  • the data packet filtering method provided by this application realizes the identification and filtering of TIPC data packets through the eBPF program loaded in the kernel, does not require custom kernel code patches, and is insensitive to kernel version changes.
  • an electronic device including:
  • a memory at least one computer program is stored on the memory, and when the at least one computer program is executed by the at least one processor, the above data packet filtering method is realized.
  • a processor is a device with data processing capabilities, including but not limited to a central processing unit (CPU), etc.; a memory is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.) , Read Only Memory (ROM), Electric Erasable Programmable Read Only Memory (EEPROM), and Flash Memory (FLASH).
  • RAM random access memory
  • ROM Read Only Memory
  • EEPROM Electric Erasable Programmable Read Only Memory
  • FLASH Flash Memory
  • the processor and the memory are connected to each other through a bus, and further connected to other components of the computing device.
  • an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the foregoing data packet filtering method is implemented.
  • FIG. 8 is a block diagram of a data packet filtering device provided by an embodiment of the present application.
  • the embodiment of the present application provides a data packet filtering device, including a matching module 801 and a processing module 802 .
  • the matching module 801 is configured to match the data packet with the preset filtering rules through the eBPF program to obtain a matching result when the loaded eBPF program identifies that the data packet to be transmitted by the kernel is a TIPC data packet.
  • the processing module 802 is configured to determine to filter the data packet according to the matching result through the eBPF program.
  • the data packet filtering apparatus further includes a generating module 803 and a loading module 804 .
  • the generating module 803 is configured to generate an eBPF program according to preset configuration data before the kernel has data packets to be transmitted; the configuration data includes filtering rules.
  • the loading module 804 is configured to load the eBPF program into the kernel.
  • the generating module 803 is also configured to generate a new eBPF program according to new configuration data after the eBPF program is loaded into the kernel and before the kernel has data packets to transmit; the new configuration data includes new filtering rule;
  • the loading module 804 is also configured to reload new eBPF programs into the kernel.
  • the configuration data further includes at least one of the following: information characterizing the underlying bearer mode of the TIPC, and the UDP port number used by the TIPC.
  • the matching module 801 is specifically configured to implement the loaded eBPF program to identify the data packet that the kernel needs to transmit as a transparent inter-process communication TIPC data packet in the following manner:
  • the eBPF program identifies the data packet as a TIPC data packet according to the information characterizing the underlying bearer mode of the TIPC.
  • the matching module 801 is specifically configured to identify the data packet as a TIPC data packet through the eBPF program according to the information representing the underlying bearer mode of the TIPC in the following manner:
  • the frame type is obtained by parsing the Ethernet frame header of the data packet through the eBPF program.
  • the eBPF program determines that the data packet is a TIPC data packet according to the frame type.
  • the matching module 801 is specifically configured to identify the data packet as a TIPC data packet through the eBPF program according to the information representing the underlying bearer mode of the TIPC in the following manner:
  • the UDP port number is obtained by parsing the Ethernet frame header, the Internet Protocol IP header and the UDP header of the data packet in sequence through the eBPF program;
  • the eBPF program determines that the data packet is a TIPC data packet according to the UDP port number.
  • the matching module 801 is specifically configured to use the following method to match the data packet with the preset filtering rules through the eBPF program to obtain the matching result:
  • the feature information is matched with the filtering rules through the eBPF program to obtain the matching result.
  • the processing module 802 is specifically configured to use at least one of the following methods to filter the data packets determined by the eBPF program according to the matching result:
  • the core is a core of dedicated hardware.
  • the data packet filtering device provided by this application can be set on a service node, or on a dedicated network processing device.
  • the specific implementation process of the above data packet filtering device is the same as the specific implementation process of the aforementioned data packet filtering method, and will not be repeated here.
  • FIG. 9 is a schematic diagram of an implementation manner of a data packet filtering device provided in an embodiment of the present application.
  • the data packet filtering device includes an eBPF program module 901 and a management module 902 .
  • the eBPF program module 901 runs in the kernel state and is configured to identify and filter data packets that the kernel needs to transmit. Specifically, in the case of identifying the data packet as a TIPC data packet, matching the data packet with a preset filtering rule to obtain a matching result; and configuring to filter the data packet according to the matching result through an eBPF program.
  • the management module 902 runs on the user plane and is configured to configure the filtering rules of the eBPF program module 901 and the underlying bearer mode of the TIPC.
  • the management module 902 may include a user interaction interface.
  • the management module 402 may receive the filtering rules input by the user and the underlying bearing mode of TIPC through the user interaction interface, or receive the eBPF program module 901 input by the user through the user interaction interface, and convert the eBPF program module 901 to Loaded into the kernel for direct calling by the kernel.
  • the eBPF program module 901 and the management module 902 can be deployed on the service node at the same time, as shown in Figure 10; they can also be deployed on a dedicated network processing device at the same time, as shown in Figure 11; or the eBPF program module 901 can be deployed on the business On the intelligent network card of the node, the management module 902 is deployed on the service node, as shown in FIG. 12 .
  • the workflow of the management module 902 is described below. As shown in FIG. 13 , the workflow of the management module 902 includes steps 1300 to 1302 .
  • Step 1300 when starting and running, read the preset configuration data, check the integrity of the configuration data, and execute step 1301 if the configuration data is complete; and end the procedure if the configuration data is incomplete.
  • Step 1301 generate an eBPF program according to configuration data.
  • Step 1302 enter the message processing loop, wait for the command input from the outside world and respond:
  • the eBPF program When a stop command is received, the eBPF program is unloaded from the kernel and terminates its own operation.
  • the working process of the eBPF program module 901 is described below. As shown in FIG. 14 , the working process of the eBPF program module 901 includes steps 1400 to 1405 .
  • Step 1400 receiving the memory buffer address passed by the kernel, and reading the data packet to be transmitted by the kernel from the memory buffer according to the memory buffer address.
  • Step 1401 when the information representing the underlying bearer mode of TIPC is the information representing the Ethernet bearer mode, perform step 1402; when the information representing the underlying bearer mode of TIPC is the information representing the UDP bearer mode, perform step 1402 1403.
  • Step 1402 parse the Ethernet frame header of the data packet to obtain the frame type, judge whether the data packet is a TIPC data packet according to the frame type; in the case that the data packet is a TIPC data packet, perform step 1404; if the data packet is not a TIPC data packet In this case, end this process.
  • Step 1403 analyze the Ethernet frame head, IP head and UDP head of data packet successively to obtain UDP port number, judge whether data packet is TIPC data packet according to UDP port number; Under the situation that data packet is TIPC data packet, execute step 1404 ; If the data packet is not a TIPC data packet, end this process.
  • Step 1404 analyzing the TIPC protocol header of the data packet to obtain feature information.
  • Step 1405 match the feature information with all the filter rules, and block the data packet if any filter rule matches the feature information; if the feature information of all filter rules does not match, block the data packet to release.
  • the functional modules/units in the system, and the device can be implemented as software, firmware, hardware, and an appropriate combination thereof.
  • the division between functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be composed of several physical components. Components cooperate to execute.
  • Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit circuit.
  • Such software may be distributed on computer readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media).
  • computer storage media includes both volatile and nonvolatile media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. permanent, removable and non-removable media.
  • Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cartridges, tape, magnetic disk storage or other magnetic storage, or may be used Any other medium that stores desired information and can be accessed by a computer.
  • communication media typically 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 .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请提供了一种数据包过滤方法、一种数据包过滤装置、一种电子设备、以及一种计算机可读存储介质，该数据包过滤方法包括：在通过已加载的扩展的伯克利包过滤器(eBPF)程序识别内核需要传输的数据包为透明进程间通信(TIPC)数据包的情况下，通过所述eBPF程序将所述数据包与预先设置的过滤规则进行匹配得到匹配结果；以及通过所述eBPF程序根据所述匹配结果确定对所述数据包进行过滤。

Description

数据包过滤方法和装置、电子设备、和计算机可读存储介质
相关申请的交叉引用
本申请要求于2021年6月21日提交的中国专利申请NO.202110689119.4的优先权，该中国专利申请的内容通过引用的方式整体合并于此。
技术领域
本申请实施例涉及互联网技术领域，特别涉及数据包过滤方法和装置、电子设备、以及计算机可读存储介质。
背景技术
透明进程间通信(TIPC，Transparent Inter-process Communication)协议是一种用于进程间通信的网络通信协议。最初由爱立信研发，应用于电信集群内的应用间通信。后逐步开源，并合入Linux、VxWorks等操作系统的内核中，使得开发人员能够创建多个应用间快速、可靠的通信信道，同时无须考虑应用在集群环境中的物理位置。
目前在实现对TIPC数据包的识别和过滤方面存在问题。
公开内容
第一方面，本申请实施例提供一种数据包过滤方法，包括：
在通过已加载的扩展的伯克利包过滤器(eBPF，extended Berkeley Packet Filter)程序识别内核需要传输的数据包为透明进程间通信(TIPC，Transparent Inter-process Communication)数据包的情况下，通过所述eBPF程序将所述数据包与预先设置的过滤规则进行匹配得到匹配结果；以及
通过所述eBPF程序根据所述匹配结果确定对所述数据包进行过 滤。
第二方面，本申请实施例提供一种电子设备，包括：
至少一个处理器；以及
存储器，所述存储器上存储有至少一个计算机程序，当所述至少一个计算机程序被所述至少一个处理器执行时，实现上述数据包过滤方法。
第三方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述数据包过滤方法。
第四方面，本申请实施例提供一种数据包过滤装置，包括：
匹配模块，配置为在通过已加载的扩展的伯克利包过滤器eBPF程序识别内核需要传输的数据包为透明进程间通信TIPC数据包的情况下，通过所述eBPF程序将所述数据包与预先设置的过滤规则进行匹配得到匹配结果；以及
处理模块，配置为通过所述eBPF程序根据所述匹配结果确定对所述数据包进行过滤。
附图说明
图1为相关技术中透明进程间通信(TIPC)协议支持的底层承载方式示意图；
图2为本申请实施例提供的数据包过滤方法的流程图；
图3为本申请实施例提供的在TIPC的底层承载方式为以太网承载方式的情况下，扩展的伯克利包过滤器(eBPF)程序从内存缓冲区读取的数据包的结构示意图；
图4为本申请实施例提供的在TIPC的底层承载方式为用户数据报协议(UDP)承载方式的情况下，互联网协议第四版(IPV4)协议的数据包的结构示意图；
图5为本申请实施例提供的在TIPC的底层承载方式为UDP承载方式的情况下，互联网协议第六版(IPV6)协议的数据包的结构示意图；
图6为本申请实施例提供的载荷类型的TIPC数据包的结构示意图；
图7为本申请实施例提供的内部控制类型的TIPC数据包的结构示意图；
图8为本申请实施例提供的数据包过滤装置的组成框图；
图9为本申请实施例提供的数据包过滤装置的一种实施方式的示意图；
图10为本申请实施例提供的数据包过滤装置的一种部署示意图；
图11为本申请实施例提供的数据包过滤装置的一种部署示意图；
图12为本申请实施例提供的数据包过滤装置的一种部署示意图；
图13为本申请实施例提供的数据包过滤装置中的管理模块的工作处理流程图；以及
图14为本申请实施例提供的数据包过滤装置中的eBPF程序模块的工作处理流程图。
具体实施方式
为使本领域的技术人员更好地理解本申请的技术方案，下面结合附图对本申请提供的数据包过滤方法和装置、电子设备、以及计算机可读存储介质进行详细描述。
在下文中将参考附图更充分地描述示例实施例，但是所述示例实施例可以以不同形式来体现，且本申请不应当被解释为限于本文阐述的实施例。提供这些实施例的目的在于使本申请更加透彻和完整，并使本领域技术人员充分理解本申请的范围。
在不冲突的情况下，本申请各实施例及实施例中的各特征可相互组合。
如本文所使用的，术语“和/或”包括至少一个相关列举条目的任何和所有组合。
本文所使用的术语仅用于描述特定实施例，且不意欲限制本申请。如本文所使用的，单数形式“一个”和“该”也意欲包括复数形式，除非上下文另外清楚指出。还将理解的是，当本说明书中使用术 语“包括”和/或“由……制成”时，指定存在特定特征、整体、步骤、操作、元件和/或组件，但不排除存在或可添加至少一个其它特征、整体、步骤、操作、元件、组件和/或其群组。
除非另外限定，否则本文所用的所有术语(包括技术术语和科学术语)的含义与本领域普通技术人员通常理解的含义相同。还将理解，诸如在常用字典中限定的那些术语应当被解释为具有与其在相关技术以及本申请的背景下的含义一致的含义，且将不解释为具有理想化或过度形式上的含义，除非本文明确如此限定。
透明进程间通信(TIPC，Transparent Inter-process Communication)协议的一些功能特性包括：
每个服务有自己的地址(不是根据套接字而是基于地址来定位服务)；
服务状态追踪(应用可以订阅服务状态，当服务地址与底层套接字发生绑定或解绑等状态变化时能够收到通知)；
集群内统一的进程间调用(IPC，Inter-Process Communication)机制(通信双方只需要知道对方的服务地址，不知道也不关心对方在集群中的具体节点位置)；
提供不可靠的数据报传输服务(支持单播、多播、广播等模式)；
提供可靠的、基于链接的数据传输服务；
提供组播服务(基于可靠的数据报传输机制)；
集群拓扑状态追踪(应用可以订阅拓扑状态变化消息，当集群新增或丢失节点时会收到通知)；
节点链接状态追踪(应用可以订阅节点链接状态变化消息，当节点间通链或断链时会收到通知)；
集群能自动发现新增节点；
包含1000个节点规模的集群能够以秒级的响应速度发现节点异常；
提供了标准的套接字编程接口(新增了AF_TIPC协议地址族)；
其代码已合入Linux内核；以及
具备极佳的性能。
图1为相关技术中TIPC协议支持的底层承载方式示意图。如图1所示，TIPC协议目前主要支持两种底层承载：以太网(Ethernet)承载方式和用户数据报协议(UDP，User Datagram Protocol)承载方式。在开放系统互联模型(OSI，Open Systems Interconnection model)所定义的7层网络通信模型中，以太网属于层2(即图1中的传输链路层，也就是媒体访问控制(MAC，Media Access Control)层)，UDP属于层4(即图1中的传输层，即UDP层)。也就是说，TIPC可以直接工作在层2之上，而不依赖层3和层4协议(即互联网协议(IP，Internet Protocol)和传输控制协议(TCP，Transmission Control Protocol)/UDP)，在这种配置下也能获得较好的性能。但出于兼容性考虑，某些场景下可能还是需要利用层3和层4提供的功能(例如互联网协议安全性(IPSec，Internet Protocol Security)、路由等等)，因此TIPC也支持运行在UDP层之上。在使用UDP层作为底层承载时，通讯双方需要配置TIPC流量所使用的UDP端口号。
TIPC的主要优势在于其简单、扁平化的服务寻址方式和优异的传输时延性能。官方的性能测试显示，在使用以太网承载方式的场景下，TIPC与TCP相比，节点间通信时延减少近33％、节点内小报文通信时延减少近66％、大报文通信时延减少近87％。由于TIPC的上述优点，其在对传输可靠性和传输时延都有很高要求的电信级业务中有较广泛的应用。
TIPC在早期设计时主要是针对内部专网的电信集群场景，并未过多考虑安全相关的内容。但随着日益严峻的网络安全环境，对系统中任何网络通信平面都提出了更高的安全要求。TIPC当前并未内置任何数据传输加密功能，但该功能可以通过其依赖的底层协议来间接实现(媒体访问控制安全性(MACSec，Media Access Control Security)或IPSec，分别对应层2和层4的配置场景)；而针对数据包的检查与过滤(也就是通称的防火墙)，目前仍然不足：当前许多主流的Linux防火墙系统都是依赖内核中的iptable子系统来实现流量过滤，但iptable并不能识别和过滤TIPC协议流量，因此当前主流的防火墙系统试图通过服务地址或其他协议字段来进行TIPC流量过滤较难 实现。
图2为本申请实施例提供的数据包过滤方法的流程图。
第一方面，参照图2，本申请实施例提供一种数据包过滤方法，包括步骤S200和S201。
步骤200、在通过已加载的扩展的伯克利包过滤器(eBPF，extended Berkeley Packet Filter)程序识别数据包为TIPC数据包的情况下，通过eBPF程序将数据包与预先设置的过滤规则进行匹配得到匹配结果。
在一些实施方式中，内核可以是执行本申请实施例的数据包过滤方法的设备的内核。在一些实施方式中，由于市面上一些主流厂商的网卡已经支持直接加载并允许eBPF程序，这意味着特定的eBPF程序可以不必加载到业务节点上，而是在专用的网络处理硬件上运行。这可以避免消耗业务节点上的资源，获得更高的性能和更高的安全性。因此，内核也可以是执行本申请实施例的数据包过滤方法的设备的专用硬件的内核，这里专用硬件可以是USB接口的计算卡、智能网卡、以及专用的防火墙硬件平台等。
在一些实施方式中，执行本申请实施例的数据包过滤方法的设备可以是任何设备，如可以是业务节点，也可以是专用的网络处理设备，如交换机、路由器等。
本申请实施例所提及的eBPF诞生的初始目标就是实现一种全新的包过滤器以取代iptable，但后续的演进对eBPF的功能进行了扩展，现在的eBPF本质上是一个运行在内核里的微型虚拟机，用户可以在规定的限制条件下编写功能代码，这些功能代码编译后可以加载到内核里执行。在加载eBPF程序到内核中时，内核会对eBPF程序进行类型、语义以及其他合法性检查，确保eBPF程序不存在可能导致挂死或崩溃的缺陷。在eBPF程序运行时，内核还会执行其他一些保护措施以防止eBPF程序崩溃。而在性能方面，由于eBPF程序运行在内核态，不需要与用户面程序频繁交互，理论上eBPF程序的性能与传统内核模块相当。
eBPF支持多种程序类型，不同类型的eBPF程序适用于不同的用 途，针对网络流量处理的程序类型是流量控制(TC，Traffic Control)或快速数据路径(XDP，eXpress Data Path)。TC类型的eBPF程序能够直接拦截Linux内核对于网络数据包的处理入口和出口，在内核对数据包进行接收或发送前，TC类型的eBPF程序就可以直接访问到最原始的网络数据包缓存，在对数据包进行处理(如分析、修改、统计等)后，再交给内核完成其他的处理。XDP类型的eBPF程序的工作原理与TC类型的eBPF程序的工作原理类似，只是内核对XDP类型的eBPF程序进行了特别的路径优化，使得XDP类型的eBPF程序处理数据包的效率更高，但目前XDP类型的eBPF程序只能处理入向数据包，也就是内核接收的数据包。
在一些实施方式中，在内核有数据包需要传输的情况下，内核会调用已加载的eBPF程序，将待传输的数据包的内存缓冲区地址传递给eBPF程序，eBPF程序就可以根据内存缓冲区地址从内存缓冲区中读取内核待传输的数据包。
在一些实施方式中，传输包括以下至少之一：发送、接收。
在一些实施方式中，在通过eBPF程序识别数据包不是TIPC数据包的情况下，结束本数据包过滤方法的流程。
在一些实施方式中，通过eBPF程序识别数据包是否为透明进程间通信TIPC数据包包括：
通过eBPF程序根据表征TIPC的底层承载方式的信息识别数据包是否为TIPC数据包。
在一些实施方式中，表征TIPC的底层承载方式的信息可以是在生成eBPF程序时包含在eBPF程序中的，也就是在生成eBPF程序时将表征TIPC的底层承载方式的信息嵌入到代码模板的全局数据区中，然后调用编译工具(如clang)根据代码模板编译并输出eBPF程序，eBPF程序可在代码中直接获取表征TIPC的底层承载方式的信息，这种方式在表征TIPC的底层承载方式的信息发生变化时需要重新生成新的eBPF程序，并将新生成的eBPF程序重新加载到内核中，但是这种方法不需要进行内存分配或执行系统调用，因此运行时效率较高；也可以是eBPF程序加载到内核后，通过eBPF与用户面之间的通信机 制将表征TIPC的底层承载方式的信息传递给eBPF程序，eBPF程序需要通过系统调用或bpf库的辅助函数来读取表征TIPC的底层承载方式的信息，这种方法在表征TIPC的底层承载方式的信息发生变化时不需要重新生成新的eBPF程序，只需要将新的TIPC的底层承载方式传递给eBPF程序即可，但是这种方法需要进行内存分配和执行系统调用，因此运行时效率较低。
在本申请提供的数据包过滤方法中，clang是一种C/C++语言编译器，目前该编译器支持输出eBPF程序字节码。
在本申请提供的数据包过滤方法中，eBPF与用户面之间的通信机制可以是任意一种可实现的通信机制，如可以通过bpf_map对象来实现数据的传递。
在一些实施方式中，通过eBPF程序根据表征TIPC的底层承载方式的信息识别数据包是否为TIPC数据包包括：
在表征TIPC的底层承载方式的信息为表征以太网承载方式的信息的情况下，通过eBPF程序解析数据包的以太网帧头得到帧类型；以及
通过eBPF程序根据帧类型判断数据包是否为TIPC数据包。
在本申请提供的数据包过滤方法中，在表征TIPC的底层承载方式的信息为表征以太网承载方式的信息的情况下，说明以太网协议之上就是TIPC协议，中间没有其他协议存在，eBPF程序从内存缓冲区读取的数据包的结构如图3所示，包括以太网帧头和载荷，以太网帧头包括：目的MAC地址、源MAC地址、以及帧类型。eBPF程序需要将数据缓存指针偏移12个字节，然后读取2字节即可获得帧类型。
不同类型的上层协议载荷都各自对应一个不同的帧类型，TIPC协议对应的帧类型为0x88CA，因此，如果eBPF程序获得的帧类型为0x88CA，则说明载荷部分为TIPC数据；如果eBPF程序获得的帧类型不是0x88CA，则说明载荷部分不是TIPC数据。
在一些实施方式中，通过eBPF程序根据表征TIPC的底层承载方式的信息识别数据包为TIPC数据包包括：
在表征TIPC的底层承载方式的信息为表征UDP承载方式的信息 的情况下，通过eBPF程序依次解析数据包的以太网帧头、IP头和UDP头得到UDP端口号；以及
通过eBPF程序根据UDP端口号判断数据包是否为TIPC数据包。
在本申请提供的数据包过滤方法中，在表征TIPC的底层承载方式的信息为表征UDP承载方式的信息的情况下，说明以太网协议之上还有IP协议和UDP协议，之后才是TIPC协议，IP协议分为互联网协议第四版(IPV4，Internet Protocol Version 4)协议和互联网协议第六版(IPV6，Internet Protocol Version 6)协议，IPV4协议对应的以太网帧的帧类型为0x0800，IPV6协议对应的以太网帧的帧类型为0x86DD，可以根据IPV4的帧类型和IPV6的帧类型识别出IP协议的数据包；IP协议头中也有载荷类型指示，如图4和图5所示，UDP协议的载荷类型为0x11，根据UDP协议的载荷类型可以从IP协议的数据包中识别出UDP协议的数据包；UDP协议头中包括源端口号和目的端口号，根据UDP协议头中的源端口号和目的端口号可以判断UDP数据包中的载荷部分是否为TIPC数据。也就是说，前面描述的UDP端口号包括源端口号和目的端口号。
在一些实施方式中，根据UDP协议头中的源端口号和目的端口号判断UDP数据包中的载荷部分是否为TIPC数据包括：
在源端口号和目的端口号均在TIPC所使用的UDP端口号内的情况下，确定UDP数据包中的载荷部分为TIPC数据，也就是说前面描述的数据包为TIPC数据包；以及
在源端口号或目的端口号不在TIPC所使用的UDP端口号内的情况下，确定UDP数据包中的载荷部分不是TIPC数据，也就是说前面描述的数据包不是TIPC数据包。
在一些实施方式中，TIPC所使用的UDP端口号可以是在生成eBPF程序时包含在eBPF程序中的，也就是在生成eBPF程序时将TIPC所使用的UDP端口号嵌入代码模板的全局数据区，然后调用编译工具(如clang)根据代码模板编译并输出eBPF程序，eBPF程序可在代码中直接访问TIPC所使用的UDP端口号，这种方式在TIPC所使用的UDP端口号发生变化时需要重新生成新的eBPF程序，并将新生成的 eBPF程序重新加载到内核中，但是这种方法不需要进行内存分配或执行系统调用，因此运行时效率较高；也可以是eBPF程序加载到内核后，通过eBPF与用户面之间的通信机制将TIPC所使用的UDP端口号传递给eBPF程序，eBPF程序需要通过系统调用或bpf库的辅助函数来读取TIPC所使用的UDP端口号，这种方法在TIPC所使用的UDP端口号发生变化时不需要重新生成新的eBPF程序，只需要将TIPC所使用的新的UDP端口号传递给eBPF程序即可，但是这种方法需要进行内存分配和执行系统调用，因此运行时效率较低。
综上所述，针对表征TIPC的底层承载方式的信息为表征UDP承载方式的信息的情况，eBPF程序识别TIPC数据包的过程如下：
eBPF程序将数据缓存指针偏移12个字节，然后读取2字节即可获得帧类型。如果eBPF程序获得的帧类型为0x0800，则说明载荷部分为IPV4数据；如果eBPF程序获得的帧类型为0x86DD，则说明载荷部分为IPV6数据。
如果eBPF程序获得的帧类型为0x0800(即载荷部分为IPV4数据)，则eBPF程序将数据缓存指针再偏移9个字节后读取1个字节即可得到载荷类型，如果eBPF程序得到的载荷类型为0x11，则eBPF程序将数据缓存指针再偏移2个字节后读取4个字节即可获得UDP协议的源端口号和目的端口号，如果eBPF程序获得的源端口号和目的端口号均在TIPC所使用的UDP端口号内，则说明载荷部分为TIPC数据；如果eBPF程序获得的源端口号或目的端口号不在TIPC所使用的UDP端口号内，则说明载荷部分不是TIPC数据。
如果eBPF程序获得的帧类型为0x86DD(即载荷部分为IPV6数据)，则eBPF程序将数据缓存指针再偏移39个字节后读取1个字节即可得到载荷类型，如果eBPF程序得到的载荷类型为0x11，则eBPF程序再读取4个字节即可获得UDP协议的源端口号和目的端口号，如果eBPF程序获得的源端口号和目的端口号均在TIPC所使用的UDP端口号内，则说明载荷部分为TIPC数据；如果eBPF程序获得的源端口号或目的端口号不在TIPC所使用的UDP端口号内，则说明载荷部分不是TIPC数据。
在一些实施方式中，通过eBPF程序将数据包与预先设置的过滤规则进行匹配得到匹配结果包括：
通过eBPF程序解析数据包的TIPC协议头得到特征信息；以及
通过eBPF程序将特征信息与过滤规则进行匹配得到匹配结果。
在本申请提供的数据包过滤方法中，TIPC共有8种载荷类型的数据包和9种内部控制类型的数据包，载荷类型的数据包共享相同的协议头格式，如图6所示，内部控制类型的数据包也共享相同的协议头格式，如图7所示。
TIPC协议提供了四种寻址方式：端口号、端口名称、端口名称序列、以及网络地址。任何一种寻址方式都可以精确定位TIPC集群网络中的一个或一个以上通信终端。从协议头的前两个字(Word)中可以获取数据包的用途大类(User)和子类型信息(MType)，根据用途大类和子类型信息就可以确定一个TIPC数据包是载荷类型的数据包还是内部控制类型的数据包，进而判断TIPC数据包使用的是何种寻址方式。
具体地，一个字包含4个字节。
在一些实施方式中，特征信息可以是源服务地址、目的服务地址中的至少一个等。
在一些实施方式中，服务地址(源服务地址或目的服务地址)可以是端口号、端口名称、端口名称范围、网络地址、节点号等中的至少一个。
在一些实施方式中，通过eBPF程序解析数据包的TIPC协议头得到特征信息包括：
通过eBPF程序解析数据包的TIPC协议头中的前2个字(即8个字节)获得数据包的用途大类和子类型信息；以及
根据数据包的用途大类和子类型信息确定协议头结构和寻址类型，根据协议头结构和寻址类型解析TIPC协议头的后续内容得到特征信息。
在一些实施方式中，过滤规则可以是在生成eBPF程序时包含在eBPF程序中的，也就是在生成eBPF程序时将过滤规则嵌入代码模板 的全局数据区，然后根据代码模板生成eBPF程序，eBPF程序可在代码中直接访问过滤规则，这种方式在过滤规则发生变化时需要重新生成新的eBPF程序，并将新生成的eBPF程序重新加载到内核中，但是这种方法不需要进行内存分配或执行系统调用，因此运行时效率较高；也可以是eBPF程序加载到内核后，通过eBPF与用户面的通信机制将过滤规则传递给eBPF程序，eBPF程序需要通过系统调用或bpf库的辅助函数来读取过滤规则，这种方法在过滤规则发生变化时不需要重新生成新的eBPF程序，只需要将新的过滤规则传递给eBPF程序即可，但是这种方法需要进行内存分配和执行系统调用，因此运行时效率较低。
在本申请提供的数据包过滤方法中，eBPF与用户面的通信机制可以是任意一种可实现的通信机制，如可以通过bpf_map对象来实现数据的传递。
在本申请提供的数据包过滤方法中，用于传递表征TIPC的底层承载方式的信息的bpf_map对象和用于传递过滤规则的bpf_map对象可以是同一个对象，也可以是不同的对象，过滤规则也可以通过两个或两个以上bpf_map对象来传递，每个bpf_map对象传递的数据可以预先设定好。
步骤201、通过eBPF程序根据匹配结果确定对数据包进行过滤。
在一些实施方式中，通过eBPF程序根据匹配结果确定对数据包进行过滤包括以下至少之一：
在匹配结果为数据包与过滤规则匹配的情况下，对数据包进行阻拦；以及
在匹配结果为数据包与过滤规则不匹配的情况下，对数据包进行放行。
在一些实施方式中，过滤规则可以是一个或一个以上。在过滤规则为两个或两个以上时，数据包与过滤规则匹配是指数据包与任意一个过滤规则匹配，数据包与过滤规则不匹配是指数据包与所有过滤规则均不匹配。
在一些实施方式中，数据包与过滤规则匹配也就是特征信息与 过滤规则匹配，数据包与过滤规则不匹配也就是特征信息与过滤规则不匹配。
在一些实施方式中，对数据包进行阻拦也就是不允许内核后续对数据包进行任何处理，eBPF程序可以通知内核丢弃该数据包；对数据包进行放行也就是允许内核后续对数据包进行处理，eBPF程序可以通知内核对数据包进行处理。
在一些实施方式中，该数据包过滤方法还包括：
在内核有数据包需要传输之前，根据预先设置的配置数据生成eBPF程序；配置数据包括过滤规则；以及
将eBPF程序加载到内核中。
在一些实施方式中，配置数据还包括以下至少之一：表征TIPC的底层承载方式的信息、TIPC所使用的UDP端口号。
本申请提供的数据包过滤方法中，生成的eBPF程序中包含有配置数据。
在一些实施方式中，该数据包过滤方法还包括：
在根据预先设置的配置数据生成eBPF程序之前，读取预先设置的配置数据，检查配置数据的完整性，在配置数据完整的情况下，继续执行根据预先设置的配置数据生成eBPF程序的步骤。
在一些实施方式中，在接收到防火墙激活指令的情况下，将eBPF程序加载到内核中。
在一些实施方式中，该数据包过滤方法还包括：
在接收到防火墙禁用指令的情况下，从内核中卸载eBPF程序。
在一些实施方式中，该数据包过滤方法还包括：
在接收到数据读取请求的情况下，通过eBPF与用户面的通信机制读取eBPF程序的运行状态数据，显示读取到的eBPF程序的运行状态数据。
在本申请提供的数据包过滤方法中，eBPF与用户面的通信机制可以是任意一种可实现的通信机制，如通过bpf_map对象来实现数据的传递，即eBPF程序需要通过系统调用或bpf库中的辅助函数来向bpf_map对象中写入运行状态数据。
在一些实施方式中，运行状态数据包括以下至少之一：
过滤规则触发的次数、阻拦的次数、放行的次数、以及过滤的数据包数量等。
在一些实施方式中，该数据包过滤方法还包括：
在接收到停止指令的情况下，从内核中卸载eBPF程序，并终止自身运行。
在一些实施方式中，该数据包过滤方法还包括：
在将eBPF程序加载到内核中后、在内核有数据包需要传输之前，根据新的配置数据生成新的eBPF程序；新的配置数据包括：新的过滤规则；以及
将新的eBPF程序重新加载到内核中。
在一些实施方式中，新的配置数据还包括：新的表征TIPC的底层承载方式的信息。
本申请提供的数据包过滤方法中，新的eBPF程序中包含有新的过滤规则和新的表征TIPC的底层承载方式的信息。
在一些实施方式中，该数据包过滤方法还包括：
根据新的配置数据生成新的eBPF程序之前，获取新的配置数据，检查新的配置数据的完整性，在新的配置数据完整的情况下，继续执行根据新的配置数据生成新的eBPF程序的步骤。
在一些实施方式中，在接收到配置更新指令的情况下，根据新的配置数据生成新的eBPF程序。如果当前防火墙为激活状态则将新的eBPF程序重新加载到内核中。
本申请提供的数据包过滤方法，通过加载在内核中的eBPF程序实现了对TIPC数据包的识别和过滤，不需要自定义的内核代码补丁，且对内核版本变化不敏感。
第二方面，本申请实施例提供一种电子设备，包括：
至少一个处理器；以及
存储器，存储器上存储有至少一个计算机程序，当所述至少一个计算机程序被所述至少一个处理器执行时，实现上述数据包过滤方法。
处理器为具有数据处理能力的器件，包括但不限于中央处理器(CPU)等；存储器为具有数据存储能力的器件，包括但不限于随机存取存储器(RAM，更具体如SDRAM、DDR等)、只读存储器(ROM)、带电可擦可编程只读存储器(EEPROM)、以及闪存(FLASH)。
在一些实施方式中，处理器、存储器通过总线相互连接，进而与计算设备的其它组件连接。
第三方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述数据包过滤方法。
图8为本申请实施例提供的数据包过滤装置的组成框图。
第四方面，参照图8，本申请实施例提供一种数据包过滤装置，包括匹配模块801和处理模块802。
匹配模块801配置为在通过已加载的eBPF程序识别内核需要传输的数据包为TIPC数据包的情况下，通过eBPF程序将数据包与预先设置的过滤规则进行匹配得到匹配结果。
处理模块802配置为通过eBPF程序根据匹配结果确定对数据包进行过滤。
在一些实施方式中，该数据包过滤装置还包括生成模块803和加载模块804。
生成模块803配置为在内核有数据包需要传输之前，根据预先设置的配置数据生成eBPF程序；配置数据包括过滤规则。
加载模块804配置为将eBPF程序加载到内核中。
在一些实施方式中，生成模块803还配置为在将eBPF程序加载到内核中后、在内核有数据包需要传输之前，根据新的配置数据生成新的eBPF程序；新的配置数据包括新的过滤规则；
加载模块804还配置为将新的eBPF程序重新加载到内核中。
在一些实施方式中，配置数据还包括以下至少之一：表征TIPC的底层承载方式的信息、TIPC所使用的UDP端口号。
在一些实施方式中，匹配模块801具体配置为采用以下方式实现通过已加载的eBPF程序识别内核需要传输的数据包为透明进程间 通信TIPC数据包：
通过eBPF程序根据表征TIPC的底层承载方式的信息识别数据包为TIPC数据包。
在一些实施方式中，匹配模块801具体配置为采用以下方式实现通过eBPF程序根据表征TIPC的底层承载方式的信息识别数据包为TIPC数据包：
在表征TIPC的底层承载方式的信息为表征以太网承载方式的信息的情况下，通过eBPF程序解析数据包的以太网帧头得到帧类型；以及
通过eBPF程序根据帧类型判断数据包为TIPC数据包。
在一些实施方式中，匹配模块801具体配置为采用以下方式实现通过eBPF程序根据表征TIPC的底层承载方式的信息识别数据包为TIPC数据包：
在表征TIPC的底层承载方式的信息为表征用户数据报协议UDP承载方式的信息的情况下，通过eBPF程序依次解析数据包的以太网帧头、互联网协议IP头和UDP头得到UDP端口号；以及
通过eBPF程序根据UDP端口号判断数据包为TIPC数据包。
在一些实施方式中，匹配模块801具体配置为采用以下方式实现通过eBPF程序将数据包与预先设置的过滤规则进行匹配得到匹配结果：
通过eBPF程序解析数据包的TIPC协议头得到特征信息；以及
通过eBPF程序将特征信息与过滤规则进行匹配得到匹配结果。
在一些实施方式中，处理模块802具体配置为采用以下方式至少之一实现通过eBPF程序根据匹配结果确定对数据包进行过滤：
在匹配结果为数据包与过滤规则匹配的情况下，对数据包进行阻拦；以及
在匹配结果为数据包与过滤规则不匹配的情况下，对数据包进行放行。
在一些实施方式中，内核为专用硬件的内核。
本申请提供的数据包过滤装置可以设置在业务节点上，也可以 设置在专用的网络处理设备上。
上述数据包过滤装置的具体实现过程与前述数据包过滤方法的具体实现过程相同，这里不再赘述。
图9为本申请实施例提供的数据包过滤装置的一种实施方式的示意图。如图9所示，该数据包过滤装置包括eBPF程序模块901和管理模块902。
eBPF程序模块901运行在内核态，配置为对内核需要传输的数据包进行识别和过滤。具体的，在识别数据包为TIPC数据包的情况下，将该数据包与预先设置的过滤规则进行匹配得到匹配结果；以及配置为通过eBPF程序根据匹配结果确定对该数据包进行过滤。
管理模块902运行在用户面，配置为对eBPF程序模块901的过滤规则和TIPC的底层承载方式进行配置。
管理模块902可以包括用户交互接口，管理模块402可以通过用户交互接口接收用户输入的过滤规则和TIPC的底层承载方式，也可以通过用户交互接口接收用户输入的eBPF程序模块901，将eBPF程序模块901加载到内核中供内核直接调用。
eBPF程序模块901和管理模块902可以同时部署在业务节点上，如图10所示；也可以同时部署在专用的网络处理设备上，如图11所示；也可以是eBPF程序模块901部署在业务节点的智能网卡上，管理模块902部署在业务节点上，如图12所示。
图10、图12、图11的部署成本依次递增，但是处理性能和安全性也依次递增。
下面描述管理模块902的工作处理流程，如图13所示，管理模块902的工作处理流程包括步骤1300至1302。
步骤1300、在启动运行时，读取预先设置的配置数据，检查配置数据的完整性，在配置数据完整的情况下，执行步骤1301；在配置数据不完整的情况下，结束本流程。
步骤1301、根据配置数据生成eBPF程序。
步骤1302、进入消息处理循环，等待外界输入的指令并进行响应：
在接收到防火墙激活指令的情况下，将eBPF程序加载到内核中；
在接收到防火墙禁用指令的情况下，从内核中卸载eBPF程序；
在接收到配置更新指令的情况下，根据新的配置数据生成新的eBPF程序；如果当前防火墙为激活状态则将新的eBPF程序重新加载到内核中；
在接收到数据读取请求的情况下，通过eBPF与用户面的通信机制读取eBPF程序的运行状态数据，显示读取到的eBPF程序的运行状态数据；以及
在接收到停止指令的情况下，从内核中卸载eBPF程序，并终止自身运行。
下面描述eBPF程序模块901的工作处理流程，如图14所示，eBPF程序模块901的工作处理流程包括步骤1400至1405。
步骤1400、接收内核传递过来的内存缓冲区地址，根据内存缓冲区地址从内存缓冲区中读取内核待传输的数据包。
步骤1401、在表征TIPC的底层承载方式的信息为表征以太网承载方式的信息的情况下，执行步骤1402；在表征TIPC的底层承载方式的信息为表征UDP承载方式的信息的情况下，执行步骤1403。
步骤1402、解析数据包的以太网帧头得到帧类型，根据帧类型判断数据包是否为TIPC数据包；在数据包为TIPC数据包的情况下，执行步骤1404；在数据包不是TIPC数据包的情况下，结束本流程。
步骤1403、依次解析数据包的以太网帧头、IP头和UDP头得到UDP端口号，根据UDP端口号判断数据包是否为TIPC数据包；在数据包为TIPC数据包的情况下，执行步骤1404；在数据包不是TIPC数据包的情况下，结束本流程。
步骤1404、解析数据包的TIPC协议头得到特征信息。
步骤1405、将特征信息与所有的过滤规则进行匹配，在有任意一个过滤规则与特征信息匹配的情况下，对数据包进行阻拦；在所有过滤规则均匀特征信息不匹配的情况下，对数据包进行放行。
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、 硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器(如中央处理器、数字信号处理器或微处理器)执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其它数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字多功能盘(DVD)或其它光盘存储、磁盒、磁带、磁盘存储或其它磁存储器、或者可以用于存储期望的信息并且可以被计算机访问的任何其它的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其它传输机制之类的调制数据信号中的其它数据，并且可包括任何信息递送介质。
本文已经公开了示例实施例，并且虽然采用了具体术语，但它们仅用于并仅应当被解释为一般说明性含义，并且不用于限制的目的。在一些实例中，对本领域技术人员显而易见的是，除非另外明确指出，否则与特定实施例相结合描述的特征、特性和/或元素可单独使用，或可与结合其它实施例描述的特征、特性和/或元件组合使用。因此，本领域技术人员将理解，在不脱离由所附的权利要求阐明的本申请的范围的情况下，可进行各种形式和细节上的改变。

Claims (13)

  1. 一种数据包过滤方法，包括：
    在通过已加载的扩展的伯克利包过滤器(eBPF)程序识别内核需要传输的数据包为透明进程间通信(TIPC)数据包的情况下，通过所述eBPF程序将所述数据包与预先设置的过滤规则进行匹配得到匹配结果；以及
    通过所述eBPF程序根据所述匹配结果确定对所述数据包进行过滤。
  2. 根据权利要求1所述的数据包过滤方法，还包括：
    在所述通过已加载的扩展的伯克利包过滤器(eBPF)程序识别内核需要传输的数据包为透明进程间通信(TIPC)数据包之前，根据预先设置的配置数据生成所述eBPF程序；其中，所述配置数据包括所述过滤规则；以及
    将所述eBPF程序加载到所述内核中。
  3. 根据权利要求2所述的数据包过滤方法，还包括：
    在所述将所述eBPF程序加载到所述内核中后、以及在所述内核有数据包需要传输之前，根据新的配置数据生成新的eBPF程序；其中，所述新的配置数据包括：新的过滤规则；以及
    将所述新的eBPF程序重新加载到所述内核中。
  4. 根据权利要求2所述的数据包过滤方法，所述配置数据还包括以下至少之一：表征TIPC的底层承载方式的信息、以及TIPC所使用的用户数据报协议(UDP)端口号。
  5. 根据权利要求1所述的数据包过滤方法，其中，所述通过已加载的扩展的伯克利包过滤器(eBPF)程序识别内核需要传输的数据包为透明进程间通信(TIPC)数据包包括：
    通过所述eBPF程序根据表征TIPC的底层承载方式的信息识别所述数据包为所述TIPC数据包。
  6. 根据权利要求5所述的数据包过滤方法，其中，所述通过所述eBPF程序根据所述表征TIPC的底层承载方式的信息识别所述数据包为所述TIPC数据包包括：
    在所述表征TIPC的底层承载方式的信息为表征以太网承载方式的信息的情况下，通过所述eBPF程序解析所述数据包的以太网帧头得到帧类型；以及
    通过所述eBPF程序根据所述帧类型判断所述数据包为所述TIPC数据包。
  7. 根据权利要求5所述的数据包过滤方法，其中，所述通过所述eBPF程序根据所述表征TIPC的底层承载方式的信息识别所述数据包为所述TIPC数据包包括：
    在所述表征TIPC的底层承载方式的信息为用户数据报协议(UDP)承载方式的情况下，通过所述eBPF程序依次解析所述数据包的以太网帧头、互联网协议(IP)头和UDP头得到UDP端口号；以及
    通过所述eBPF程序根据所述UDP端口号判断所述数据包为所述TIPC数据包。
  8. 根据权利要求1所述的数据包过滤方法，其中，所述通过所述eBPF程序将所述数据包与预先设置的过滤规则进行匹配得到匹配结果包括：
    通过所述eBPF程序解析所述数据包的TIPC协议头得到特征信息；以及
    通过所述eBPF程序将所述特征信息与所述过滤规则进行匹配得到所述匹配结果。
  9. 根据权利要求1所述的数据包过滤方法，其中，所述通过所 述eBPF程序根据所述匹配结果确定对所述数据包进行过滤包括以下至少之一：
    在所述匹配结果为所述数据包与所述过滤规则匹配的情况下，对所述数据包进行阻拦；以及
    在所述匹配结果为所述数据包与所述过滤规则不匹配的情况下，对所述数据包进行放行。
  10. 根据权利要求1所述的数据包过滤方法，其中，所述内核为专用硬件的内核。
  11. 一种电子设备，包括：
    至少一个处理器；以及
    存储器，所述存储器上存储有至少一个计算机程序，当所述至少一个计算机程序被所述至少一个处理器执行时，实现根据权利要求1至10中任意一项所述的数据包过滤方法。
  12. 一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现根据权利要求1至10中任意一项所述的数据包过滤方法。
  13. 一种数据包过滤装置，包括：
    匹配模块，配置为在通过已加载的扩展的伯克利包过滤器(eBPF)程序识别内核需要传输的数据包为透明进程间通信(TIPC)数据包的情况下，通过所述eBPF程序将所述数据包与预先设置的过滤规则进行匹配得到匹配结果；以及
    处理模块，配置为通过所述eBPF程序根据所述匹配结果确定对所述数据包进行过滤。
PCT/CN2022/095438 2021-06-21 2022-05-27 数据包过滤方法和装置、电子设备、和计算机可读存储介质 WO2022267815A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110689119.4A CN115514508A (zh) 2021-06-21 2021-06-21 数据包过滤方法和装置、电子设备、计算机可读存储介质
CN202110689119.4 2021-06-21

Publications (1)

Publication Number Publication Date
WO2022267815A1 true WO2022267815A1 (zh) 2022-12-29

Family

ID=84499377

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/095438 WO2022267815A1 (zh) 2021-06-21 2022-05-27 数据包过滤方法和装置、电子设备、和计算机可读存储介质

Country Status (2)

Country Link
CN (1) CN115514508A (zh)
WO (1) WO2022267815A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115801482A (zh) * 2023-02-08 2023-03-14 银河麒麟软件(长沙)有限公司 云原生环境下基于eBPF的组播实现方法、系统及介质
CN115883255A (zh) * 2023-02-02 2023-03-31 中信证券股份有限公司 数据过滤方法、设备以及计算机可读介质
CN116545978A (zh) * 2023-05-16 2023-08-04 深圳市石犀科技有限公司 数据处理方法、装置、系统、可读存储介质及进口网卡

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106452925A (zh) * 2016-12-02 2017-02-22 华为技术有限公司 在nfv系统中检测故障的方法、装置和系统
WO2017046617A1 (en) * 2015-09-18 2017-03-23 Telesoft Technologies Ltd Methods and apparatus for detecting patterns in data packets in a network
CN111984290A (zh) * 2020-08-06 2020-11-24 锐捷网络股份有限公司 嵌入式设备升级的方法、嵌入式设备及存储介质
CN112367196A (zh) * 2020-10-30 2021-02-12 锐捷网络股份有限公司 一种检测网络通信故障的方法、装置及电子设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017046617A1 (en) * 2015-09-18 2017-03-23 Telesoft Technologies Ltd Methods and apparatus for detecting patterns in data packets in a network
CN106452925A (zh) * 2016-12-02 2017-02-22 华为技术有限公司 在nfv系统中检测故障的方法、装置和系统
CN111984290A (zh) * 2020-08-06 2020-11-24 锐捷网络股份有限公司 嵌入式设备升级的方法、嵌入式设备及存储介质
CN112367196A (zh) * 2020-10-30 2021-02-12 锐捷网络股份有限公司 一种检测网络通信故障的方法、装置及电子设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DONG YE: "Optimization Design and Implement of Multi-mode Heterogeneous Convergent Terminal Based on 4G", MASTER THESIS, TIANJIN POLYTECHNIC UNIVERSITY, CN, 15 January 2019 (2019-01-15), CN , XP093017511, ISSN: 1674-0246 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115883255A (zh) * 2023-02-02 2023-03-31 中信证券股份有限公司 数据过滤方法、设备以及计算机可读介质
CN115883255B (zh) * 2023-02-02 2023-06-23 中信证券股份有限公司 数据过滤方法、设备以及计算机可读介质
CN115801482A (zh) * 2023-02-08 2023-03-14 银河麒麟软件(长沙)有限公司 云原生环境下基于eBPF的组播实现方法、系统及介质
CN116545978A (zh) * 2023-05-16 2023-08-04 深圳市石犀科技有限公司 数据处理方法、装置、系统、可读存储介质及进口网卡
CN116545978B (zh) * 2023-05-16 2024-05-17 深圳市石犀科技有限公司 数据处理方法、装置、系统、可读存储介质及进口网卡

Also Published As

Publication number Publication date
CN115514508A (zh) 2022-12-23

Similar Documents

Publication Publication Date Title
WO2022267815A1 (zh) 数据包过滤方法和装置、电子设备、和计算机可读存储介质
US11824962B2 (en) Methods and apparatus for sharing and arbitration of host stack information with user space communication stacks
CN108111523B (zh) 数据传输方法和装置
US10713099B2 (en) Modifying application behaviour
US11558348B2 (en) Methods and apparatus for emerging use case support in user space networking
US9882808B2 (en) Packet processing method and apparatus
WO2018032399A1 (en) Server and method having high concurrency capability
US10499311B2 (en) Method and apparatus for implementing network sharing
US20120140640A1 (en) Apparatus and method for dynamically processing packets having various characteristics
CN115589383B (zh) 基于eBPF的虚拟机数据传输方法、装置、设备、存储介质和程序产品
WO2022068744A1 (zh) 获取报文头信息、生成报文的方法、设备及存储介质
US8943123B2 (en) Server apparatus, network access method, and computer program
CN114697387B (zh) 数据包传输方法、装置及存储介质
KR20230017886A (ko) 패킷 처리 방법, 기기 및 시스템
CN115033407B (zh) 一种适用于云计算的采集识别流量的系统和方法
WO2021128936A1 (zh) 报文的处理方法及装置
CN113890789B (zh) 适用于数据中心的udp隧道流量的分流方法、流量转发方法
BR102019009234A2 (pt) dispositivo de rede e método para processar o tráfego de rede com estrutura sdn de modo dinâmico e independente de protocolo
US10282331B1 (en) System and method for command processing
US11301231B2 (en) Dynamic run time programming of hardware tables
WO2023065670A1 (zh) 远程证明的方法、装置、设备、系统及可读存储介质
KR20180002535A (ko) 직접 메모리 액세스 제어 장치 및 그 작동 방법
WO2024027398A1 (zh) 一种通信方法和装置
US20040174885A1 (en) Method, system and computer program product for processing packets at forwarder interfaces
Sommese Boosting the performance of NFV services with SmartNIC

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22827312

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22827312

Country of ref document: EP

Kind code of ref document: A1