Traffic characteristic monitoring method, apparatus, terminal device, and computer program product

Abstract

This application relates to a traffic characteristic monitoring method, apparatus, terminal device, and computer program product. The method includes: mounting an eBPF program at a target hook point in kernel mode; extracting the peer IP address, local IP address, and traffic characteristics of each data packet or connection using the eBPF program; querying the location and carrier corresponding to the peer IP address of the data packet or connection, and the logical line ID corresponding to the local IP address of the data packet or connection, using the location, carrier, and local IP as dimension labels, and aggregating the traffic characteristics of data packets or connections with the same dimension labels to obtain the overall traffic characteristics under each dimension label. This application solves the problem of coarse-grained and low-precision traffic characteristic monitoring in related technologies, achieving the technical effect of reducing the monitoring granularity of traffic characteristics and improving the monitoring precision of traffic characteristics.

Description

Technical Field

[0001] This application belongs to the field of communication technology, and in particular relates to a method, device, terminal equipment and computer program product for monitoring traffic characteristics. Background Technology

[0002] As CDN services continue to evolve towards cloud-native and virtualized architectures, the form of network infrastructure is becoming increasingly complex. A single node often simultaneously hosts containers, virtual machines, or multiple network namespaces, significantly increasing the need for granular monitoring of traffic characteristics.

[0003] Currently, coarse-grained traffic characteristics can be obtained by reading counters provided by the network interface card (NIC) driver layer to count the number of packets sent and received, the number of bytes, and the number of packet losses. However, the statistical dimensions of traffic characteristics obtained in this way are limited, and it is impossible to obtain traffic characteristics under a specific physical location or even a specific logical line ID. This is not conducive to subsequent fine-grained network resource scheduling and rapid fault location.

[0004] There is still no effective solution to the problem that the monitoring granularity of flow characteristics in related technologies is too coarse and the precision is too low. Summary of the Invention

[0005] This application provides a method, apparatus, terminal device, and computer program product for monitoring traffic characteristics, in order to at least solve the problem of coarse granularity and low precision in monitoring traffic characteristics in related technologies.

[0006] In a first aspect, embodiments of this application provide a traffic characteristic monitoring method, the method comprising: mounting an eBPF program at a target hook point in kernel mode; extracting the peer IP address, local IP address, and traffic characteristics of each data packet or connection through the eBPF program; querying the location and operator corresponding to the peer IP address of the data packet or connection and the logical line ID corresponding to the local IP address of the data packet or connection through the eBPF program; using the location, operator, and local IP as dimension labels, aggregating the traffic characteristics of data packets or connections with the same dimension labels to obtain the overall traffic characteristics under each dimension label.

[0007] In some embodiments, before mounting the eBPF program at the target hook point in kernel mode, the method further includes: loading an IP address database into a first eBPF mapping table and loading a logical line information database into a second eBPF mapping table; the IP address database stores multiple IP addresses and the location and operator corresponding to each IP address; the logical line information database stores multiple IP addresses and the logical line ID corresponding to each IP address; the step of querying the location and operator corresponding to the peer IP address of the data packet or connection and the logical line ID corresponding to the local IP address of the data packet or connection through the eBPF program includes: querying the location and operator corresponding to the peer IP address of the data packet or connection from the first eBPF mapping table through the eBPF program, and querying the logical line ID corresponding to the local IP address of the data packet or connection from the second eBPF mapping table.

[0008] In some embodiments, the target hook point includes: a fast data path module, a flow control module, and a TCP closure tracking point; the extraction of the peer IP address, local IP address, and traffic characteristics of each data packet or connection by the eBPF program includes: extracting the peer IP address, local IP address, and traffic characteristics of each data packet passing through the fast data path module by the eBPF program mounted on the fast data path module; extracting the peer IP address, local IP address, and traffic characteristics of each data packet passing through the flow control module by the eBPF program mounted on the flow control module; and extracting the peer IP address, local IP address, and traffic characteristics of each closed connection by the eBPF program mounted on the TCP closure tracking point.

[0009] In some embodiments, the step of extracting the peer IP address, the local IP address, and the traffic characteristics of each data packet passing through the fast data path module using the eBPF program mounted on the fast data path module includes: for each data packet passing through the fast data path module, before the data packet enters the kernel protocol stack, extracting the source IP address, destination IP address, and traffic characteristics of the data packet using the eBPF program mounted on the fast data path module, and using the source IP address as the peer IP address and the destination IP address as the local IP address; the step of extracting the peer IP address, the local IP address, and the traffic characteristics of each data packet passing through the flow control module using the eBPF program mounted on the flow control module includes: for each data packet passing through the flow control module, before the data packet enters the network interface card from the kernel protocol stack, extracting the source IP address, destination IP address, and traffic characteristics of the data packet using the eBPF program mounted on the flow control module, and using the source IP address as the local IP address and the destination IP address as the peer IP address.

[0010] In some embodiments, after aggregating the traffic characteristics of data packets or connections with the same dimension label by using the location, the operator, and the local IP as dimension labels to obtain the overall traffic characteristics under each dimension label, the method further includes: performing performance optimization and security monitoring of the network environment based on the overall traffic characteristics under each dimension label.

[0011] In some embodiments, the performance optimization and security monitoring of the network environment based on the overall traffic characteristics under each dimension label includes: storing the overall traffic characteristics under each dimension label in a third eBPF mapping table; reading the overall traffic characteristics of each dimension label within a preset time period from the third eBPF mapping table at a preset period; and performing performance optimization and security monitoring of the network environment based on the overall traffic characteristics of each dimension label within the preset time period.

[0012] In some embodiments, the overall traffic characteristics include at least one of the following: number of data packets sent, number of data packets retransmitted, average round-trip time of data packets, number of uplink and downlink bytes, retransmission rate, and uplink and downlink rate.

[0013] Secondly, embodiments of this application provide a traffic characteristic monitoring device, the device comprising: a mounting module for mounting an eBPF program at a target hook point in kernel mode; an extraction module for extracting the peer IP address, local IP address, and traffic characteristics of each data packet or connection through the eBPF program; a query module for querying the location and operator corresponding to the peer IP address of the data packet or connection, and the logical line ID corresponding to the local IP address of the data packet or connection, through the eBPF program; and a statistics module for aggregating the traffic characteristics of data packets or connections with the same dimension label, using the location, operator, and local IP as dimension labels, to obtain the overall traffic characteristics under each dimension label.

[0014] Thirdly, embodiments of this application provide a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the traffic characteristic monitoring method described in any one of the first aspects above.

[0015] Fourthly, embodiments of this application provide a computer program product, including a computer program, which, when run, causes the traffic characteristic monitoring method described in any one of the first aspects to be executed.

[0016] Compared to related technologies, the traffic feature monitoring method, apparatus, terminal device, and computer program product provided in this application can mount an eBPF program at the target hook point in kernel mode. Then, the eBPF program can extract the peer IP address, local IP address, and traffic features for each data packet or connection. Subsequently, the eBPF program can query the location and ISP corresponding to the peer IP address of the data packet or connection, as well as the logical line ID corresponding to the local IP address of the data packet or connection. Finally, the location, ISP, and local IP can be used as dimension labels to aggregate the traffic features of data packets or connections with the same dimension labels, obtaining the overall traffic features under each dimension label. In this way, by mounting an eBPF program at a key location in the network data path, querying the location, ISP, and logical line ID corresponding to each data packet or connection through the eBPF program, and using the location, ISP, and local IP as dimension labels, traffic classification and feature statistics can be directly completed in kernel mode, achieving high-performance, fine-grained traffic identification and feature collection. This application solves the problem of coarse granularity and low precision in the monitoring of flow characteristics in related technologies, and achieves the technical effect of reducing the monitoring granularity of flow characteristics and improving the monitoring precision of flow characteristics.

[0017] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart of a traffic characteristic monitoring method according to an embodiment of this application; Figure 2 This is a flowchart of a traffic characteristic monitoring method according to another embodiment of this application; Figure 3 This is a schematic diagram illustrating the collection of traffic information according to one embodiment of this application; Figure 4 This is a schematic diagram of the structure of a flow characteristic monitoring device according to an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a terminal device according to an embodiment of this application. Detailed Implementation

[0020] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0021] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0022] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0023] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0024] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0025] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0026] As CDN services continue to evolve towards cloud-native and virtualized architectures, the form of network infrastructure is becoming increasingly complex. A single node often simultaneously hosts containers, virtual machines, or multiple network namespaces, significantly increasing the need for granular monitoring of traffic characteristics.

[0027] Currently, coarser-grained traffic characteristics can be obtained by reading counters provided by the network card driver layer to count the number of packets sent and received, the number of bytes, and the number of lost packets; alternatively, traffic calculation rules can be inserted into the Netfilter rules in the kernel space, and the net_cls subsystem can be used to distinguish between containers or processes to achieve simple process-level or container-level traffic statistics; or, the kernel protocol stack code can be modified to achieve process-level traffic statistics.

[0028] However, the statistical dimensions of traffic characteristics obtained in these ways are limited, and it is impossible to obtain traffic characteristics under a certain physical location or even a certain logical line ID. This is not conducive to subsequent fine-grained network resource scheduling and rapid fault location.

[0029] There is still no effective solution to the problem that the monitoring granularity of flow characteristics in related technologies is too coarse and the precision is too low.

[0030] In view of this, this application provides a traffic feature monitoring method. An eBPF program can be mounted at a target hook point in the kernel mode. Then, the eBPF program can extract the peer IP address, local IP address, and traffic features of each data packet or connection. Subsequently, the eBPF program can query the location and ISP corresponding to the peer IP address of the data packet or connection, as well as the logical line ID corresponding to the local IP address of the data packet or connection. Finally, the location, ISP, and local IP can be used as dimension labels to aggregate the traffic features of data packets or connections with the same dimension labels, obtaining the overall traffic features under each dimension label. In this way, by mounting an eBPF program at a key location in the network data path, querying the location, ISP, and logical line ID corresponding to each data packet or connection through the eBPF program, and using the location, ISP, and local IP as dimension labels, traffic classification and feature statistics can be directly completed in the kernel mode, achieving high-performance, fine-grained traffic identification and feature acquisition. This application solves the problem of coarse-grained and low-precision traffic feature monitoring in related technologies, achieving the technical effect of reducing the monitoring granularity of traffic features and improving the monitoring precision of traffic features.

[0031] The following will combine Figure 1 For an explanation of a traffic characteristic monitoring method provided in one embodiment of this application, please refer to [link to relevant documentation]. Figure 1 , Figure 1 This is a flowchart of a traffic characteristic monitoring method according to an embodiment of this application, such as... Figure 1 As shown, the method includes: Step S101: Mount the eBPF program at the target hook point in kernel mode.

[0032] In one embodiment, the target hook point mentioned above includes: a fast data path module, a flow control module, and a TCP closure tracking point.

[0033] In this embodiment, the target hook point in kernel mode can refer to the location in the operating system (e.g., Linux system) kernel that allows the mounting of eBPF (Extended Berkeley Packet Filter) programs and can trigger packet or connection events.

[0034] The target hook point can include an eXpress Data Path (XDP) module, a Traffic Control (TC) module, and a TCP close tracepoint (tcp_close). The eBPF program mounted on the XDP is triggered before the packet enters the kernel protocol stack and is suitable for feature extraction of uplink traffic. The eBPF program mounted on the TC is triggered before the packet enters the network interface card and is suitable for feature extraction of downlink traffic. The eBPF program mounted on the TCP close tracepoint is triggered when the kernel's TCP protocol stack closes a TCP connection. This eBPF program can capture traffic information for the entire lifecycle of the closed TCP connection.

[0035] In this way, by coordinating the mounting of eBPF programs at multiple target hook points, comprehensive monitoring of uplink data packets, downlink data packets, and connection-level traffic information can be achieved.

[0036] In one embodiment, prior to step S101, the method further includes: loading an IP address database into a first eBPF mapping table and loading a logical line information database into a second eBPF mapping table; the IP address database stores multiple IP addresses and the location and operator corresponding to each IP address; the logical line information database stores multiple IP addresses and the logical line ID corresponding to each IP address.

[0037] In this embodiment, the IP address database stores multiple IP address ranges and the corresponding geographical location information (e.g., country, region, province, city) and carrier information for each IP address. As an example, the first eBPF mapping table can adopt the LPM Trie (Longest Prefix Matching Tree) type to support efficient matching of IPv4 and IPv6 address prefixes. Subsequent eBPF programs can query this first eBPF mapping table to achieve nanosecond-level geographical location and carrier determination for data packets or connections.

[0038] In this embodiment, the logical line information database stores multiple IP addresses and the logical line ID corresponding to each IP address. The logical line ID is a service identifier defined internally by the CDN scheduling system to distinguish different customers, different service levels, or different egress lines. As an example, the second eBPF mapping table adopts a Hash Map type, which can use IP addresses as keys and logical line IDs as values. Subsequent eBPF programs can query this second eBPF mapping table to determine the nanosecond-level logical line ID of data packets or connections.

[0039] In one embodiment, the user-space application can populate the first and second eBPF mapping tables via system calls before all eBPF programs have completed mounting (that is, loading the IP address database into the first eBPF mapping table and the logical line information database into the second eBPF mapping table). After each eBPF mapping table is loaded, the eBPF program can directly query these eBPF mapping tables during subsequent packet or connection traffic statistics without interacting with the user-space application, thereby completing traffic classification and feature statistics directly in kernel mode.

[0040] Step S102: Extract the peer IP address, local IP address, and traffic characteristics of each data packet or connection using the eBPF program.

[0041] Understandably, the flow direction of data packets detected at different hook points may be different, therefore, the definition process for their peer IP address and local IP address will also differ.

[0042] Figure 2 This is a flowchart of a traffic characteristic monitoring method according to another embodiment of this application, such as... Figure 2 As shown, in one embodiment, step S102 includes: Step S201: Extract the peer IP address, local IP address, and traffic characteristics of each data packet passing through the Fast Data Path module using the eBPF program mounted on the Fast Data Path module.

[0043] Please see Figure 3 , Figure 3 This is a schematic diagram illustrating the collection of traffic information according to one embodiment of this application, such as... Figure 3 As shown, step S201 includes: for each data packet passing through the fast data path module 30, before the data packet enters the kernel protocol stack 32, the source IP address, destination IP address and traffic characteristics of the data packet are extracted by the eBPF program mounted on the fast data path module 30, and the source IP address is used as the peer IP address and the destination IP address is used as the local IP address.

[0044] like Figure 3As shown, XDP 30 is located after network interface card 33 receives the data packet and before the kernel protocol stack 32 processes it. For a data packet entering the local machine, its source IP address represents the sender (i.e., the peer), and its destination IP address represents the local machine (i.e., the local machine). Therefore, at this hook point, the eBPF program can parse the IP header of the data packet, extract the source IP address as the peer IP address, and extract the destination IP address as the local IP address. Simultaneously, the traffic characteristics of the data packet extracted by the eBPF program can include, but are not limited to: data packet length, protocol type, timestamp, etc. For TCP data packets, the eBPF program can also extract information such as the TCP header flags.

[0045] The eBPF program described above can parse data packets and identify various protocol headers (e.g., QinQ, VLAN, PPPoE, IPv4, IPv6, UDP, TCP) to extract the source and destination IP addresses of the data packets.

[0046] The eBPF program described above can perform lightweight aggregation of data packets. For example, it can perform preliminary aggregation of traffic characteristics by using "peer IP address + local IP address (+ protocol)" as the key (e.g., counting data packets or accumulating the number of bytes in data packets) to reduce subsequent processing overhead.

[0047] Step S202: Extract the peer IP address, local IP address, and traffic characteristics of each data packet passing through the flow control module using the eBPF program mounted on the flow control module.

[0048] like Figure 3 As shown, in one embodiment, step S202 includes: for each data packet passing through the flow control module 31, before the data packet enters the network card 33 from the kernel protocol stack 32, extracting the source IP address, destination IP address and traffic characteristics of the data packet by the eBPF program mounted on the flow control module 31, and using the source IP address as the local IP address and the destination IP address as the peer IP address.

[0049] Please see Figure 3TC 31 is located at the outbound direction of NIC 33. That is, the eBPF program mounted at TC 31 is triggered when a data packet has been processed by the kernel protocol stack 32 and is about to be sent to NIC 33. For a data packet sent from the local machine, its source IP address represents the local machine (i.e., the local machine), and its destination IP address represents the receiver (i.e., the peer). Therefore, at this hook point, the eBPF program can parse the IP header of the data packet, extract the source IP address as the local IP address, and extract the destination IP address as the peer IP address. Simultaneously, the traffic characteristics of the data packet extracted by the eBPF program can include, but are not limited to: data packet length, protocol type, timestamp, etc. For TCP data packets, the eBPF program can also extract information such as the TCP header flags.

[0050] It should be noted that the eBPF programs mounted at XDP 30 and TC 31 are mainly used to process the real-time traffic characteristics of individual packets. The above eBPF programs can be used in conjunction with the eBPF programs mounted at the TCP closing tracking point to obtain connection-level traffic characteristics (e.g., retransmission rate, average round-trip time (RTT)).

[0051] Step S203: Extract the peer IP address, local IP address, and traffic characteristics of each closed connection using the eBPF program mounted on the TCP close tracking point.

[0052] In this embodiment, when a TCP connection in the kernel is completely closed, the kernel triggers a TCP close tracking point and passes a pointer to the socket structure corresponding to the closed TCP connection to the eBPF program. The eBPF program mounted on the TCP close tracking point can obtain the cumulative statistical information (i.e., the traffic characteristics of the connection) of the entire lifecycle of the TCP connection from establishment to closure by reading the member variables in the socket structure.

[0053] The aforementioned cumulative statistics may include, but are not limited to: the total number of data packets sent by the connection, the total number of data packets retransmitted by the connection, the average RTT of data packets in the connection, the total number of bytes sent by the connection, the total number of bytes received by the connection, the retransmission rate of the connection, and the uplink and downlink rates of the connection.

[0054] In addition, the eBPF program mounted on the TCP close tracking point can directly extract the source IP address and destination IP address of the TCP connection from the socket structure corresponding to the closed TCP connection, and determine the local IP address and peer IP address based on the local address, so as to match the dimension labels in the future.

[0055] Step S103: Use the eBPF program to query the location and operator corresponding to the peer IP address of the data packet or connection, as well as the logical line ID corresponding to the local IP address of the data packet or connection.

[0056] In one embodiment, step S103 includes: querying the location and operator corresponding to the peer IP address of the data packet or connection from the first eBPF mapping table through the eBPF program, and querying the logical line ID corresponding to the local IP address of the data packet or connection from the second eBPF mapping table.

[0057] In this embodiment, for the peer IP address and local IP address of the data packet or connection queried by the eBPF program, the eBPF program can use the peer IP address as the query key to perform longest prefix matching in the first eBPF mapping table to determine the location and operator corresponding to the peer IP address; the eBPF program can use the local IP address as the query key to perform exact matching in the second eBPF mapping table to determine the logical line ID corresponding to the local IP address.

[0058] In one embodiment, to avoid performing a mapping table lookup for every data packet, the eBPF program mounted on XDP or TC employs a lookup caching strategy: the most recently queried "peer IP address → location, ISP" mapping result is temporarily stored in a Least Recently Used Map (LRU Map). For subsequent data packets with the same peer IP address, the cached result in the LRU Map can be used directly, thereby reducing the number of queries to the first eBPF mapping table. When the cached result is not found, the query will fall back to the first eBPF mapping table.

[0059] It is understandable that the mapping result of "local IP address → logical line ID" can also be temporarily stored in another LRUMap, and the eBPF program can also use a lookup cache strategy to determine the logical line ID. This application will not elaborate on this further.

[0060] Step S104: Using location, carrier, and local IP as dimension labels, aggregate the traffic characteristics of data packets or connections with the same dimension labels to obtain the overall traffic characteristics under each dimension label.

[0061] In this embodiment, the dimension label can be a combination of multiple parameters, including location (e.g., country, region, province, city, etc.), carrier, and logical line ID. In some embodiments, the dimension label may also include more parameters, such as protocol type.

[0062] In this embodiment, dimension labels (e.g., through hash calculation or binary concatenation) can be encoded as integer keys to serve as keys in a third eBPF mapping table, which can be of type Hash Map to store the overall traffic characteristics under each dimension label.

[0063] The aggregation process of traffic characteristics for packets or connections with the same dimension label can include: When processing a packet, an eBPF program mounted on XDP or TC can accumulate the following metrics in the third eBPF mapping table according to the dimension label corresponding to that packet: number of packets, number of bytes (or packet length), and number of packets in the uplink / downlink direction; When a TCP connection is closed, an eBPF program mounted on a TCP close tracking point can accumulate the following metrics in the third eBPF mapping table according to the dimension label corresponding to that connection: total number of packets sent by the connection, total number of packets retransmitted by the connection, average RTT of packets in the connection (which can be accumulated to the total RTT of all packets), total number of bytes sent by the connection, and total number of bytes received by the connection.

[0064] In this way, by directly aggregating the aforementioned traffic characteristics in kernel space, the communication overhead required to report traffic characteristics to user-space applications individually for each packet or connection can be avoided, thereby reducing the resource consumption of the traffic characteristic monitoring system.

[0065] In one embodiment, the overall traffic characteristics include at least one of the following: number of data packets sent, number of data packets retransmitted, average round-trip time of data packets, number of uplink and downlink bytes, retransmission rate, and uplink and downlink rate.

[0066] Through the above embodiments, after obtaining the traffic characteristics of each data packet or each connection under the same dimension label, the traffic characteristics of the data packets and the traffic characteristics of the connections can be aggregated and calculated to obtain the network quality index under the dimension label (i.e., the location, operator and logical line ID corresponding to the dimension label). The network quality index may include: average round-trip time of data packets (total RTT of all data packets divided by the number of data packets), retransmission rate (number of data packet retransmissions divided by number of data packets sent), uplink and downlink rates, and median uplink and downlink rates, etc.

[0067] In one embodiment, after step S104 above, the method further includes: optimizing the network environment for performance and monitoring security based on the overall traffic characteristics under each dimension label.

[0068] In this embodiment, performance optimization and security monitoring of the network environment based on the overall traffic characteristics under each dimension label includes: storing the overall traffic characteristics under each dimension label in a third eBPF mapping table; reading the overall traffic characteristics of each dimension label within a preset time period from the third eBPF mapping table according to a preset period; and performing performance optimization and security monitoring of the network environment based on the overall traffic characteristics of each dimension label within the preset time period.

[0069] In this embodiment, the overall traffic characteristics under each dimension label can be stored in a third eBPF mapping table. All entries in the third eBPF mapping table can be read by a user-space application (e.g., a separate traffic monitoring daemon) at a preset period (e.g., every 30 seconds or every minute) via system calls. Then, the overall traffic characteristics of each dimension label within a preset time period can be reported to the scheduling platform by the user-space application. The scheduling platform can then perform performance optimization and security monitoring of the network environment based on the overall traffic characteristics of each dimension label within the preset time period (e.g., the scheduling platform can schedule traffic to a location / operator / logical line ID combination with better network quality, or determine whether a network attack or network malfunction has occurred at a location / operator / logical line ID combination by detecting whether a sudden increase in the retransmission rate occurs at that location / operator / logical line ID combination).

[0070] Through steps S101 to S104, an eBPF program can be mounted at the target hook point in kernel mode. Then, the eBPF program can extract the peer IP address, local IP address, and traffic characteristics of each data packet or connection. Subsequently, the eBPF program can query the location and ISP corresponding to the peer IP address of the data packet or connection, as well as the logical line ID corresponding to the local IP address of the data packet or connection. Finally, the location, ISP, and local IP can be used as dimension labels to aggregate the traffic characteristics of data packets or connections with the same dimension labels, obtaining the overall traffic characteristics under each dimension label. In this way, by mounting an eBPF program at a key location in the network data path, querying the location, ISP, and logical line ID corresponding to each data packet or connection through the eBPF program, and using the location, ISP, and local IP as dimension labels, traffic classification and feature statistics can be directly completed in kernel mode, achieving high-performance, fine-grained traffic identification and feature acquisition. This application solves the problem of coarse-grained and low-precision traffic feature monitoring in related technologies, achieving the technical effect of reducing the monitoring granularity of traffic features and improving the monitoring precision of traffic features.

[0071] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0072] Corresponding to the traffic characteristic monitoring method described in the above embodiments, Figure 4 A schematic diagram of a flow characteristic monitoring device according to an embodiment of this application is shown. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0073] Please see Figure 4 The traffic characteristic monitoring device 4 includes: a mounting module 40 for mounting an eBPF program at a target hook point in kernel mode; an extraction module 41 for extracting the peer IP address, local IP address, and traffic characteristics of each data packet or connection through the eBPF program; a query module 42 for querying the location and operator corresponding to the peer IP address of the data packet or connection, and the logical line ID corresponding to the local IP address of the data packet or connection, through the eBPF program; and a statistics module 43 for aggregating the traffic characteristics of data packets or connections with the same dimension label, using location, operator, and local IP as dimension labels, to obtain the overall traffic characteristics under each dimension label.

[0074] In one embodiment, the traffic characteristic monitoring device 4 further includes a loading module for loading an IP address database into a first eBPF mapping table and a logical line information database into a second eBPF mapping table; the IP address database stores multiple IP addresses and the location and operator corresponding to each IP address; the logical line information database stores multiple IP addresses and the logical line ID corresponding to each IP address; the query module 42 is further used to query the location and operator corresponding to the peer IP address of the data packet or connection from the first eBPF mapping table through an eBPF program, and to query the logical line ID corresponding to the local IP address of the data packet or connection from the second eBPF mapping table.

[0075] In one embodiment, the target hook point includes: a fast data path module, a flow control module, and a TCP closure tracking point; the extraction module 41 is further configured to extract the peer IP address, local IP address, and traffic characteristics of each data packet passing through the fast data path module using an eBPF program mounted on the fast data path module; extract the peer IP address, local IP address, and traffic characteristics of each data packet passing through the flow control module using an eBPF program mounted on the flow control module; and extract the peer IP address, local IP address, and traffic characteristics of each closed connection using an eBPF program mounted on the TCP closure tracking point.

[0076] In one embodiment, the extraction module 41 is further configured to extract the source IP address, destination IP address, and traffic characteristics of each data packet passing through the fast data path module before the data packet enters the kernel protocol stack, using an eBPF program mounted on the fast data path module, and using the source IP address as the peer IP address and the destination IP address as the local IP address; the extraction module 41 is further configured to extract the source IP address, destination IP address, and traffic characteristics of each data packet passing through the flow control module before the data packet enters the network card from the kernel protocol stack, using an eBPF program mounted on the flow control module, and using the source IP address as the local IP address and the destination IP address as the peer IP address.

[0077] In one embodiment, the traffic characteristic monitoring device 4 further includes an optimization module for optimizing network performance and monitoring security based on the overall traffic characteristics under each dimension label.

[0078] In one embodiment, the optimization module is further configured to store the overall traffic characteristics under each dimension label into a third eBPF mapping table; read the overall traffic characteristics of each dimension label within a preset time period from the third eBPF mapping table according to a preset period; and perform performance optimization and security monitoring of the network environment based on the overall traffic characteristics of each dimension label within the preset time period.

[0079] In one embodiment, the overall traffic characteristics include at least one of the following: number of data packets sent, number of data packets retransmitted, average round-trip time of data packets, number of uplink and downlink bytes, retransmission rate, and uplink and downlink rate.

[0080] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0081] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0082] Figure 5 This is a schematic diagram of the structure of a terminal device according to an embodiment of this application. Figure 5 As shown, the terminal device 5 includes: at least one processor 50 ( Figure 5 (Only one is shown in the image) a processor, a memory 51, and a computer program 52 stored in the memory 51 and capable of running on at least one processor 50, wherein the processor 50 executes the computer program 52 to implement the steps in any of the above-described traffic characteristic monitoring method embodiments.

[0083] Terminal device 5 can be a computing device such as a desktop computer, laptop, handheld computer, or cloud server. Terminal device 5 may include, but is not limited to, processor 50 and memory 51. Those skilled in the art will understand that... Figure 5 This is merely an example of terminal device 5 and does not constitute a limitation on terminal device 5. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0084] The processor 50 can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or 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.

[0085] In some embodiments, memory 51 may be an internal storage unit of terminal device 5, such as a hard disk or memory of terminal device 5. In other embodiments, memory 51 may be an external storage device of terminal device 5, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on terminal device 5. In other embodiments, memory 51 may include both internal storage units and external storage devices of terminal device 5. Memory 51 is used to store operating system, application programs, bootloader, data, and other programs, such as the program code of computer program 52. Memory 51 may also be used to temporarily store data that has been output or will be output.

[0086] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the above-described traffic characteristic monitoring method embodiments.

[0087] This application provides a computer program product that, when run on a mobile terminal, enables the mobile terminal to implement the steps described in the above-described traffic characteristic monitoring method embodiments.

[0088] This application implements all or part of the processes in the methods of the above embodiments, which can be accomplished by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or some intermediate form. The computer-readable medium can include at least: any entity or device capable of carrying the computer program code to a traffic characteristic monitoring device or terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, such as a USB flash drive, a portable hard drive, a magnetic disk, or an optical disk.

[0089] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0090] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0091] In the embodiments provided in this application, it should be understood that the disclosed apparatus / network devices and methods can be implemented in other ways. For example, the apparatus / network device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0092] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0093] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for monitoring flow characteristics, characterized in that, The method includes: Mount the eBPF program at the target hook point in kernel mode; The eBPF program extracts the peer IP address, local IP address, and traffic characteristics of each data packet or connection. The eBPF program queries the location and operator corresponding to the peer IP address of the data packet or connection, as well as the logical line ID corresponding to the local IP address of the data packet or connection. Using the location, the carrier, and the local IP as dimension labels, the traffic characteristics of data packets or connections with the same dimension label are aggregated to obtain the overall traffic characteristics under each dimension label.

2. The method according to claim 1, characterized in that, Before mounting the eBPF program at the target hook point in kernel mode, the method further includes: The IP address database is loaded into the first eBPF mapping table, and the logical line information database is loaded into the second eBPF mapping table; the IP address database stores multiple IP addresses and the location and operator corresponding to each IP address; the logical line information database stores multiple IP addresses and the logical line ID corresponding to each IP address. The step of querying the location and carrier corresponding to the peer IP address of the data packet or connection, and the logical line ID corresponding to the local IP address of the data packet or connection, through the eBPF program includes: The eBPF program queries the first eBPF mapping table for the location and operator corresponding to the peer IP address of the data packet or connection, and queries the second eBPF mapping table for the logical line ID corresponding to the local IP address of the data packet or connection.

3. The method according to claim 1, characterized in that, The target hook point includes: a fast data path module, a flow control module, and a TCP shutdown tracking point; The extraction of the peer IP address, local IP address, and traffic characteristics of each data packet or connection through the eBPF program includes: The eBPF program mounted on the Fast Data Path module extracts the peer IP address, the local IP address, and the traffic characteristics of each data packet passing through the Fast Data Path module. The eBPF program mounted on the flow control module extracts the peer IP address, the local IP address, and the traffic characteristics of each data packet passing through the flow control module. The eBPF program mounted on the TCP close tracking point extracts the peer IP address, the local IP address, and the traffic characteristics for each closed connection.

4. The method according to claim 3, characterized in that, The step of extracting the peer IP address, the local IP address, and the traffic characteristics of each data packet passing through the fast data path module using the eBPF program mounted on the fast data path module includes: For each data packet passing through the fast data path module, before the data packet enters the kernel protocol stack, the source IP address, destination IP address and traffic characteristics of the data packet are extracted by the eBPF program mounted on the fast data path module, and the source IP address is used as the peer IP address and the destination IP address is used as the local IP address. The step of extracting the peer IP address, the local IP address, and the traffic characteristics of each data packet passing through the flow control module using the eBPF program mounted on the flow control module includes: For each data packet passing through the flow control module, before the data packet enters the network card from the kernel protocol stack, the source IP address, destination IP address and flow characteristics of the data packet are extracted by the eBPF program mounted on the flow control module, and the source IP address is used as the local IP address and the destination IP address is used as the peer IP address.

5. The method according to any one of claims 1 to 4, characterized in that, After aggregating the traffic characteristics of data packets or connections with the same dimension label by using the location, the carrier, and the local IP as dimension labels to obtain the overall traffic characteristics under each dimension label, the method further includes: Based on the overall traffic characteristics under each dimension label, the network environment is optimized for performance and monitored for security.

6. The method according to claim 5, characterized in that, The process of optimizing network performance and monitoring security based on the overall traffic characteristics under each dimension label includes: Store the overall traffic characteristics under each dimension label into a third eBPF mapping table; The overall traffic characteristics of each dimension label within a preset time period are read from the third eBPF mapping table according to a preset period. Based on the overall traffic characteristics of each dimension label within the preset time period, the network environment is optimized for performance and monitored for security.

7. The method according to any one of claims 1 to 4, characterized in that, The overall traffic characteristics include at least one of the following: number of data packets sent, number of data packets retransmitted, average round-trip time of data packets, number of uplink and downlink bytes, retransmission rate, and uplink and downlink speed.

8. A flow characteristic monitoring device, characterized in that, The device includes: The mount module is used to mount eBPF programs at the target hook point in kernel mode. The extraction module is used to extract the peer IP address, local IP address, and traffic characteristics of each data packet or connection through the eBPF program; The query module is used to query the location and operator corresponding to the peer IP address of the data packet or connection, as well as the logical line ID corresponding to the local IP address of the data packet or connection, through the eBPF program. The statistics module is used to aggregate the traffic characteristics of data packets or connections with the same dimension label, using the location, the operator, and the local IP as dimension labels, to obtain the overall traffic characteristics under each dimension label.

9. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the traffic characteristic monitoring method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, Includes a computer program, which, when run, causes the traffic characteristic monitoring method as described in any one of claims 1 to 7 to be executed.

Images