Network traffic control method, apparatus, storage medium, device, and program product

Abstract

The application relates to the technical field of computer networks, in particular to a network traffic control method and device, a storage medium, equipment and a program product. The method comprises the following steps: acquiring a speed-limiting rule for network traffic; establishing a first mapping relationship between a network connection object identifier and a target process identifier, and establishing a second mapping relationship between a local network tuple and the target process identifier; querying a first target process identifier corresponding to a first local network tuple; limiting the number of tokens in a token bucket state storage structure within a maximum bucket capacity determined by a speed threshold and a burst tolerance parameter; and determining a processing mode for a network data packet according to the relationship between the updated number of tokens and the data packet length of the network data packet. The application solves the technical problem that, due to the difficulty of related network traffic control methods in accurately distinguishing the independent traffic of different processes on the same host, the non-target process traffic is easily damaged when the bandwidth of a specific process is limited.

Description

Technical Field

[0001] This application relates to the field of computer network technology, and more specifically, to a network traffic control method, apparatus, storage medium, device, and program product. Background Technology

[0002] In general-purpose operating systems, network traffic control is a key means of ensuring fair allocation of system resources and service stability. Related network traffic control schemes typically manage traffic based on network tuples such as network interface, IP address, port number, or protocol type. For example, by configuring queue rules or network filter rules, traffic can be rate-limited or dropped for specific network cards, source / destination IPs, or specific port ranges.

[0003] However, with the increasing number of concurrent processes in operating systems and the widespread adoption of containerization technology, the aforementioned control method based on network tuples has significant drawbacks:

[0004] First, the control granularity is coarse, which can easily lead to false positives. Multiple different business processes may share the same network interface, access the same remote server address, or even dynamically use the same temporary port. When an administrator intends to limit the bandwidth of only a specific process (such as a background synchronization process), IP- or port-based control rules will simultaneously apply to all processes using that address or port. This can cause traffic to non-target processes (such as critical business processes) to be incorrectly rate-limited or dropped, severely impacting the overall stability of the system.

[0005] Second, process attribution association is delayed and inaccurate. Traditional solutions rely on user-space polling to read process or connection tables to infer the correspondence between processes and network connections. Because network connection states change rapidly, and connectionless protocols such as User Datagram Protocol (UDP) lack fixed connection states, periodic sampling in user space cannot accurately and in real-time establish the mapping between processes and data packets. This leads to delays in control command issuance or missed or incorrect judgments during process iteration.

[0006] Third, there is a lack of native process-level control mechanisms in the kernel. Related kernel-level rate limiting modules mostly focus on queue scheduling, making it difficult to directly obtain the fine-grained process context corresponding to data packets; while cgroup-based solutions support resource isolation, they are complex to configure and lack flexibility in complex network paths and dynamic port scenarios.

[0007] In summary, no effective solution has yet been proposed for how to achieve low-overhead, high-precision process-level network traffic control in the Linux kernel, avoiding the limitations of network tuple-based control. Summary of the Invention

[0008] This application provides a network traffic control method, apparatus, storage medium, device, and program product to at least solve the technical problem that, due to the difficulty of accurately distinguishing the independent traffic of different processes on the same host, the traffic of non-target processes is easily damaged when limiting the bandwidth of a specific process.

[0009] According to one aspect of this application, a network traffic control method is provided, comprising: obtaining rate limiting rules for network traffic; wherein the rate limiting rules include: a rate threshold, a target process identifier, a control direction, and a burst tolerance parameter; the burst tolerance parameter is used to characterize the number of tokens allowed to accumulate by a process; establishing a first mapping relationship between a network connection object identifier and a target process identifier, and establishing a second mapping relationship between a local network tuple and a target process identifier; extracting the packet direction, transport layer protocol type, and a first local network tuple and a first network connection object identifier corresponding to the network packet from the network packet; when the transport layer protocol type is Transmission Control Protocol, querying the first target process identifier corresponding to the first network connection object identifier based on the first mapping relationship; when the transport layer protocol type is User Datagram Protocol, querying the first target process identifier corresponding to the first local network tuple based on the second mapping relationship; determining whether the packet direction matches the control direction, and whether the first target process identifier matches the target process identifier; if both match, limiting the number of tokens in the token bucket state storage structure to within the maximum bucket capacity jointly determined by the rate threshold and the burst tolerance parameter; and determining the processing method for the network packet based on the relationship between the updated number of tokens and the packet length of the network packet.

[0010] Optionally, determining whether the data packet direction matches the control direction and whether the first target process identifier matches the target process identifier includes: determining the target mapping relationship used to obtain the first target process identifier; wherein the target mapping relationship is a first mapping relationship or a second mapping relationship; determining the type of the target mapping relationship as the mapping source; obtaining the process mapping record corresponding to the first target process identifier in the target mapping relationship; determining the timeliness factor based on the time difference between the target time and the first timestamp when processing the network data packet; wherein the first timestamp is the timestamp recorded in the process mapping record when the update or hit is closest to the target time; and determining the timeliness factor based on the local network address and the local network address recorded in the process mapping record. The binding status of the ground port is used to determine the binding accuracy factor; based on the consistency relationship between the learning direction and protocol type recorded in the process mapping record and the data packet direction and transport layer protocol type in the network data packet, the direction protocol consistency factor is determined; based on the mapping source, timeliness factor, binding accuracy factor, and direction protocol consistency factor, the attribution confidence of the first target process identifier is determined, wherein the attribution confidence is used to characterize the degree of consistency between the first target process identifier and the actual process to which the network data packet belongs; if the attribution confidence is greater than or equal to the first preset control threshold, it is determined whether the data packet direction matches the control direction, and whether the first target process identifier matches the target process identifier.

[0011] Optionally, the number of tokens in the token bucket state storage structure is limited to the maximum bucket capacity determined by a rate threshold and a burst tolerance parameter. This includes: querying or creating a bucket state associated with a hierarchical state key corresponding to a network data packet; wherein the bucket state includes token bucket state information; the hierarchical state key is used to characterize the hierarchical position of the token bucket; if the bucket state is being created for the first time, initializing the current available token count in the bucket state according to a preset cold start strategy; wherein the cold start strategy is configured to initialize the current available token count to a preset proportion of the maximum bucket capacity; determining the maximum bucket capacity based on the rate threshold and the burst tolerance parameter; obtaining the last update time in the bucket state, and calculating the number of tokens to be replenished based on the time difference between the target time when processing network data packets and the last update time; increasing the current available token count in the bucket state by the number of tokens to be replenished, limiting the increased current available token count to within the maximum bucket capacity, and using the limited current available token count as the updated token count.

[0012] Optionally, the method further includes: when calculating the number of tokens to be replenished, if the time difference is greater than a preset time limit, correcting the time difference to the preset time limit; when determining the maximum bucket capacity, if the maximum bucket capacity determined based on the rate threshold and the burst tolerance parameter is greater than the preset maximum capacity, setting the maximum bucket capacity to the preset maximum capacity; if the drop rate of the target process within the preset time window is less than a preset threshold, increasing the burst tolerance parameter; if the drop rate of the target process within the preset time window is greater than the preset threshold, decreasing the burst tolerance parameter.

[0013] Optionally, based on the relationship between the updated token count and the length of the network data packet, the processing method for the network data packet is determined, including: generating a basic state key based on the target process identifier; wherein the basic state key is used to represent the identifier of the target process; on the basis of the basic state key, a direction field is superimposed to form a second-level direction state key, or a protocol field is superimposed on the second-level direction state key to form a third-level protocol state key, so as to construct a hierarchical token bucket state structure; wherein the token bucket corresponding to the basic state key is used to represent the total bandwidth budget of the process, the token bucket corresponding to the direction state key is used to represent the bandwidth budget in a specified direction, and the token bucket corresponding to the protocol state key is used to represent the bandwidth budget on a specified protocol; based on the characteristics of the network data packet, the hierarchical state key corresponding to the network data packet is determined, and the updated token count in the bucket state associated with the hierarchical state key is obtained; wherein the hierarchical state key is the basic state key and the second-level direction state key. Alternatively, one of the three-level protocol status keys; check the token limit of each enabled level in hierarchical order. If the updated token count of all enabled levels is greater than or equal to the length of the network data packet, deduct the tokens corresponding to each level and allow the network data packet to pass; where enabled levels include: the level corresponding to the basic status key, the level corresponding to the second-level directional status key, and the level corresponding to the third-level protocol status key, and the combination of levels enabled according to a preset policy; if the updated token count of any level is less than the length of the data packet, perform an overdraft-allowed passage operation, statistical alarm, or discard operation on the network data packet; where the overdraft-allowed passage operation includes: allowing the network data packet and recording the available token count as a negative value or recording the overdraft limit, with subsequent replenished tokens prioritizing the repayment of the overdraft limit; statistical alarm includes: statistically analyzing abnormal event information of the network data packet and sending alarm events to the user space, without performing a discard operation.

[0014] Optionally, the process of allowing overdraft on network data packets includes: calculating the difference between the data packet length and the updated token count to obtain the single overdraft byte count; determining whether the single overdraft byte count is less than or equal to a preset single overdraft threshold; if the single overdraft byte count is less than or equal to the single overdraft threshold, determining to allow overdraft and updating the bucket state associated with the hierarchical state key; subtracting the data packet length from the current available token count in the bucket state to obtain the overdraft limit, and recording the overdraft limit in the bucket state; wherein, tokens replenished in subsequent cycles are preferentially used to offset the overdraft limit.

[0015] Optionally, a drop operation is performed on the network data packet, including: determining whether any of the following drop conditions are met: the cumulative overdraft limit in the hierarchical bucket state corresponding to the network data packet exceeds a preset cumulative overdraft threshold, the number of bytes exceeding the limit in a single transaction exceeds a preset single overdraft threshold, the overdraft allowance function is not enabled and the data packet length of the network data packet is greater than the updated token quantity; if any drop condition is met, the drop operation is performed.

[0016] When performing a drop operation, the transport layer protocol type of the network data packet is obtained, and a corresponding packet loss statistics event is sent to the user space according to the transport layer protocol type. Specifically, if the transport layer protocol type is Transmission Control Protocol, a packet loss statistics event including the Transmission Control Protocol identifier is sent to the user space; if the transport layer protocol type is User Datagram Protocol, a packet loss statistics event including the User Datagram Protocol identifier is sent to the user space.

[0017] Optionally, after querying the first target process identifier corresponding to the first network connection object identifier, the method further includes: performing a state aging check on the process mapping or network tuple mapping; wherein, the state aging check includes: obtaining the most recent hit time or the most recent update time of the process mapping or network tuple mapping; if the difference between the most recent hit time or the most recent update time and the target time when processing network data packets exceeds a first preset aging threshold, deleting the corresponding mapping relationship; after limiting the number of tokens in the token bucket state storage structure to within the maximum bucket capacity jointly determined by the rate threshold and the burst tolerance parameter, the method further includes: obtaining the most recent hit time or the most recent update time in the token bucket state; if the difference between the most recent hit time or the most recent update time and the target time when processing network data packets exceeds a second preset aging threshold, deleting the corresponding token bucket state.

[0018] Optionally, before determining whether the data packet direction matches the control direction and whether the first target process identifier matches the target process identifier, the method further includes: determining whether any of the following abnormal conditions exist: network packet parsing failure, the first target process identifier query result is empty, the rate limiting rule query result is empty, or the attribution confidence corresponding to the first target process identifier is less than a preset control threshold; if any of the abnormal conditions exist, the network data packet is allowed to pass, and an abnormal diagnosis event is sent to the user space; wherein, the abnormal diagnosis event includes at least one of the following: network packet parsing failure event, process mapping missing event, rule missing event, confidence insufficient event, and abnormal release statistics event; the process mapping missing event is used to indicate that the first target process identifier was not found; the rule missing event is used to indicate that the corresponding rate limiting rule was not found; the confidence insufficient event is used to indicate that the attribution confidence corresponding to the first target process identifier is less than a preset control threshold; the abnormal release statistics event is used to indicate the network data packet information that was allowed to pass due to the abnormal condition.

[0019] Optionally, after obtaining the rate-limiting rules for network traffic, the method further includes: loading a dynamically executable kernel-mode program, mounting the first subroutine of the kernel-mode program to the process-network connection association path, mounting the second subroutine of the kernel-mode program to the network packet processing path, and writing the rate-limiting rules into a first shared memory structure; wherein the first subroutine and the second subroutine are different subroutines; through the first subroutine, the following steps are performed: establishing a first mapping relationship between the network connection object identifier and the target process identifier, and establishing a second mapping relationship between the local network tuple and the target process identifier; writing the first mapping relationship into a second shared memory structure, and writing the second mapping relationship into a third shared memory structure; through the second subroutine, the following steps are performed: extracting the packet direction, transport layer protocol type, and the first local data type corresponding to the network packet from the network packet. The system retrieves the local network tuple and the first network connection object identifier. If the transport layer protocol type is User Datagram Protocol (UDP), it queries the first target process identifier corresponding to the first local network tuple based on the second mapping relationship stored in the third shared storage structure. If the transport layer protocol type is Transmission Control Protocol (TCP), it queries the first target process identifier corresponding to the first network connection object identifier based on the first mapping relationship stored in the second shared storage structure. It reads the rate limiting rule from the first shared storage structure and determines whether the packet direction matches the control direction, and whether the first target process identifier matches the target process identifier. If all match, it limits the number of tokens in the token bucket state storage structure to within the maximum bucket capacity determined by the rate threshold and the burst tolerance parameter. Based on the relationship between the updated number of tokens and the packet length of the network data packet, it determines the processing method for the network data packet.

[0020] According to another aspect of this application, a network traffic control device is also provided, comprising: an acquisition module, configured to acquire rate limiting rules for network traffic; wherein the rate limiting rules include: a rate threshold, a target process identifier, a control direction, and a burst tolerance parameter; the burst tolerance parameter is used to characterize the number of tokens allowed to accumulate by a process; an establishment module, configured to establish a first mapping relationship between a network connection object identifier and a target process identifier, and to establish a second mapping relationship between a local network tuple and the target process identifier; an extraction module, configured to extract the data packet direction, transport layer protocol type, and the first local network tuple and the first network connection object identifier corresponding to the network data packet from the network data packet; and a query module, configured to query the data packet whose transport layer protocol type is Transmission Control. In the case of the protocol, based on the first mapping relationship, the first target process identifier corresponding to the first network connection object identifier is queried; in the case where the transport layer protocol type is User Datagram Protocol, based on the second mapping relationship, the first target process identifier corresponding to the first local network tuple is queried; the execution module is used to determine whether the direction of the data packet matches the control direction, and whether the first target process identifier matches the target process identifier; if both match, the number of tokens in the token bucket state storage structure is limited to the maximum bucket capacity determined by the rate threshold and the burst tolerance parameter; the determination module is used to determine the processing method for the network data packet based on the relationship between the updated number of tokens and the data packet length of the network data packet.

[0021] According to another aspect of this application, a non-volatile storage medium is also provided, the storage medium including a stored program, wherein the program, when running, controls the device where the storage medium is located to execute the above-described network traffic control method.

[0022] According to another aspect of this application, an electronic device is also provided, comprising: a memory and a processor, the processor being configured to run a program stored in the memory, wherein the program executes the above-described network traffic control method during runtime.

[0023] According to another aspect of this application, a computer program is also provided, wherein the computer program, when executed by a processor, implements the above-described network traffic control method.

[0024] According to another aspect of this application, a computer program product is also provided, comprising a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program that, when executed by a processor, implements the above-described network flow control method.

[0025] In this application, a rate-limiting rule for network traffic is obtained; the rate-limiting rule includes: a rate threshold, a target process identifier, a control direction, and a burst tolerance parameter; the burst tolerance parameter is used to characterize the number of tokens allowed to accumulate by a process; a first mapping relationship is established between a network connection object identifier and a target process identifier, and a second mapping relationship is established between a local network tuple and a target process identifier; the packet direction, transport layer protocol type, and the first local network tuple and the first network connection object identifier corresponding to the network packet are extracted from the network packet; when the transport layer protocol type is Transmission Control Protocol, the first target process identifier corresponding to the first network connection object identifier is queried based on the first mapping relationship; when the transport layer protocol type is User Datagram Protocol, the first target process identifier corresponding to the first local network tuple is queried based on the second mapping relationship; the packet direction and control direction, and the first target process identifier and the target process identifier are determined. The process identifiers are checked for matching. If all match, the number of tokens in the token bucket state storage structure is limited to the maximum bucket capacity determined by the rate threshold and burst tolerance parameter. Based on the relationship between the updated number of tokens and the length of the network data packet, the method for processing the network data packet is determined. This achieves the goal of improving the granularity of traffic control from a coarse-grained dimension to a fine-grained process dimension, and ensuring that rate limiting is applied only to the matching target process in the specified direction. This enables precise targeting of the target traffic when limiting the bandwidth of a specific process, avoiding accidental damage to other non-target processes sharing the same network resources. At the same time, the kernel-level real-time association and token bucket algorithm ensure low overhead, high precision, and burst traffic tolerance. This solves the technical problem that related network traffic control methods are unable to accurately distinguish the independent traffic of different processes on the same host, which can easily damage the traffic of non-target processes when limiting the bandwidth of a specific process. Attached Figure Description

[0026] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0027] Figure 1 This is a flowchart of a network traffic control method according to an embodiment of this application;

[0028] Figure 2 This is a schematic diagram of the architecture and interaction of a network traffic control system according to an embodiment of this application;

[0029] Figure 3 This is a flowchart of another network traffic control method according to an embodiment of this application;

[0030] Figure 4This is a schematic diagram of a process attribution learning process according to an embodiment of this application;

[0031] Figure 5 This is a schematic diagram of a process attribution confidence determination process according to an embodiment of this application;

[0032] Figure 6 This is a schematic diagram of a hierarchical token bucket rate limiting process according to an embodiment of this application;

[0033] Figure 7 This is a schematic diagram of a protocol-aware packet loss rate limiting process according to an embodiment of this application;

[0034] Figure 8 This is a schematic diagram of a state aging and recycling process according to an embodiment of this application;

[0035] Figure 9 This is a schematic diagram of the interaction timing between user mode and kernel mode according to an embodiment of this application;

[0036] Figure 10 This is a structural diagram of a network traffic control device according to an embodiment of this application;

[0037] Figure 11 This is a hardware structure block diagram of a computer terminal for a network traffic control method according to an embodiment of this application. Detailed Implementation

[0038] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0039] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0040] According to an embodiment of this application, an embodiment of a network traffic control method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0041] Figure 1 This is a flowchart of a network traffic control method according to an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:

[0042] Step S101: Obtain rate limiting rules for network traffic; wherein, the rate limiting rules include: rate threshold, target process identifier, control direction and burst tolerance parameter; the burst tolerance parameter is used to characterize the number of tokens that a process is allowed to accumulate.

[0043] In step S101, the network traffic control policy issued by the administrator is received, and a rate-limiting rule containing rate-limiting elements is generated. This rate-limiting rule mainly includes a rate threshold, a target process identifier (PID), a control direction, and a burst tolerance parameter. The rate threshold represents the maximum average transmission rate allowed for the target process (usually in bytes per second); the target process identifier identifies the specific process to be restricted; the control direction specifies the network path for implementing rate limiting, including inbound (received locally) or outbound (sent locally); and the burst tolerance parameter determines the time scale in the token bucket algorithm, thus characterizing the number of tokens a process is allowed to accumulate, supporting a certain degree of short-term burst traffic without immediate rate limiting.

[0044] In addition, after obtaining the rate limiting rules for network traffic, the rate limiting rules can be written into the first BPF Map (i.e., the process rate limiting rule mapping) for kernel-mode programs to read.

[0045] Step S102: Establish a first mapping relationship between the network connection object identifier and the target process identifier, and establish a second mapping relationship between the local network tuple and the target process identifier.

[0046] In step S102, a mapping of ownership between processes and network communication endpoints is established in kernel mode. Specifically, this includes establishing a first mapping between network connection object identifiers and target process identifiers, and a second mapping between local network tuples and target process identifiers. The first mapping is primarily implemented through a first eBPF program mounted on the socket operation path (such as hooks for connection, send, and receive). This program binds the socket object pointer (i.e., the network connection object identifier) ​​in the kernel to the process identifier currently executing the socket operation and stores it in the second BPF Map. Here, eBPF, or extended Berkeley Packet Filter, is a verifiable and dynamically loadable kernel-mode program execution mechanism provided by the Linux kernel. BPF Map: A kernel-mode key-value storage structure for shared data between eBPF programs and user mode.

[0047] The second mapping relationship is mainly for connectionless UDP protocols. By parsing the IP address, port number and protocol type bound locally to the Socket, a local network tuple is constructed, and this tuple is associated with the corresponding target process identifier and stored in the third BPF Map to solve the problem that the process ownership of UDP inbound packets cannot be directly obtained through the Socket pointer.

[0048] Step S103: Extract the data packet direction, transport layer protocol type, and the first local network tuple and first network connection object identifier corresponding to the network data packet from the network data packet.

[0049] In step S103, the data packet direction refers to the flow direction of network data packets relative to the local machine, including the inbound direction (i.e., the local machine's receiving path) and the outbound direction (i.e., the local machine's sending path). In this embodiment, the data packet direction is used to determine the application scenario of the rate-limiting policy, such as limiting the upload traffic (outbound direction) or download traffic (inbound direction) of only a specific process. Here, "local machine" refers to a computer device (including physical servers, desktop terminals, or container hosts) running a Linux operating system and eBPF program. In network communication, "local machine" is relative to a remote device. The inbound direction refers to the process where data packets are sent from the remote device, reach the local machine's network interface via the network, enter the local machine's kernel protocol stack, and are delivered to the local machine's process. The outbound direction refers to the process where data packets are generated by the local machine's process, processed by the local machine's kernel protocol stack, and sent from the local machine's network interface to the remote device.

[0050] Step S104: When the transport layer protocol type is Transmission Control Protocol, query the first target process identifier corresponding to the first network connection object identifier based on the first mapping relationship; when the transport layer protocol type is User Datagram Protocol, query the first target process identifier corresponding to the first local network tuple based on the second mapping relationship.

[0051] In step S104, based on the extracted transport layer protocol type, a differentiated query strategy is used to determine the target process to which the network data packet belongs, thereby achieving accurate identification of process affiliation.

[0052] If the transport layer protocol type is Transmission Control Protocol (TCP), since TCP is a connection-based protocol, each network connection corresponds to a unique Socket object. Based on the first mapping relationship, the first network connection object identifier (i.e., Socket kernel pointer) extracted in step S103 is used to query the corresponding first target process identifier in the second BPF Map (i.e., Socket to process mapping).

[0053] In other words, because TCP is a connection-oriented protocol, each network connection (Socket) corresponds to a specific process during its lifecycle. Therefore, when the data packet is a TCP packet, the first mapping relationship (i.e., the mapping from network connection object identifier / Socket pointer to process identifier) ​​is directly used to quickly look up the corresponding first target process identifier through the first network connection object identifier (Socket pointer) in the data packet. This method is direct and accurate because the relationship between the Socket and the process is determined and relatively stable when the TCP connection is established.

[0054] If the transport layer protocol type is User Datagram Protocol (UDP), since UDP is a connectionless protocol, it is not possible to directly and stably associate a specific process through the Socket pointer. Based on the second mapping relationship, the first local network tuple (containing local IP, local port and protocol number) extracted in step S103 is used to query the corresponding first target process identifier in the third BPF Map (i.e., local network tuple to process mapping).

[0055] In other words, because UDP is a connectionless protocol, when a data packet arrives, there may not be a persistent Socket object uniquely bound to it, or multiple processes may share the same Socket for sending, making it difficult to accurately distinguish which process generated the traffic based solely on the Socket pointer. Therefore, for inbound UDP data packets, a second mapping relationship based on local network tuples (local IP, local port, protocol number) is used. When a data packet is a UDP packet, the system extracts the first local network tuple corresponding to the data packet and queries the first target process identifier based on the second mapping relationship (i.e., the mapping from local network tuples to process identifiers).

[0056] This protocol-type-based attribution query method overcomes the differences in context acquisition between TCP long connections and UDP connectionless communication, ensuring that the kernel-mode data packet path can accurately obtain the process attribution information of the data packet.

[0057] Optionally, step S104 can also be implemented through the following steps: when the socket object corresponding to the network connection object identifier is valid, query the first target process identifier corresponding to the first network connection object identifier based on the first mapping relationship; when the transport layer protocol type is User Datagram Protocol and the network data packet is in the inbound direction, query the first target process identifier corresponding to the first local network tuple based on the second mapping relationship.

[0058] Step S105: Determine whether the data packet direction matches the control direction and whether the first target process identifier matches the target process identifier; if they all match, limit the number of tokens in the token bucket state storage structure to within the maximum bucket capacity determined by the rate threshold and the burst tolerance parameter.

[0059] The purpose of step S105 is to ensure that the rate-limiting action only applies to the traffic of a specific process in a specific direction specified by the rate-limiting rule, thereby avoiding false positives. For example, an administrator may only want to limit the outbound upload traffic of a process, but not its inbound download traffic; or only limit process A, without affecting process B. Only when all of the above matching is passed can the data packet be confirmed as the target of the rate-limiting policy.

[0060] Step S106: Determine the processing method for network packets based on the relationship between the updated number of tokens and the length of network packets.

[0061] In step S106, based on the comparison between the updated token quantity and the current network data packet length, a corresponding processing action is performed to implement rate limiting. If the updated token quantity is greater than or equal to the data packet length, it indicates that the current quota is sufficient. The corresponding number of tokens is deducted, and the data packet is allowed to pass. At the same time, the cumulative number of bytes allowed and the time of the most recent hit are updated.

[0062] If the number of tokens is insufficient, the handling method is determined by combining the token debt mechanism and the protocol awareness strategy: if the difference is within the preset debt threshold range, the data packet can be allowed to pass and the token debt can be recorded (i.e. the number of tokens is negative or the debt value is recorded separately). The tokens that are subsequently added are used to repay the debt first, thereby smoothing out the frequent dropping caused by short-term bursts.

[0063] If the excess exceeds the debt threshold or a debt-free policy is applied, a drop action is executed, and the drop event is reported. For TCP packets, dropping excess packets aims to trigger the congestion control mechanism of the TCP sender (such as fast retransmission, timeout retransmission, and congestion window adjustment), thereby automatically reducing the sending rate. For UDP packets, the drop operation utilizes its unreliable transmission semantics, allowing real-time services to tolerate the loss of non-critical data or allowing the application layer with reliability requirements to retransmit the data itself.

[0064] Through the above token bucket-based decision-making process, while achieving process-level bandwidth limiting, it also takes into account business continuity and protocol semantic adaptability, effectively solving the problems of crude packet loss strategies and easy damage to non-target services in traditional solutions.

[0065] Through the above steps S101 to S106, the granularity of traffic control is improved from a coarse-grained dimension to a fine-grained process dimension, and the purpose of ensuring that the rate limit is applied only to the matched target process in the specified direction is achieved. This enables precise targeting of the target traffic when limiting the bandwidth of a specific process, avoiding accidental damage to other non-target processes sharing the same network resources. At the same time, the kernel-mode real-time association and token bucket algorithm ensure the technical effect of low overhead, high precision and burst traffic tolerance of the control.

[0066] The following are Figure 1 The steps shown are illustrated and explained by way of example.

[0067] According to some optional embodiments of this application, the determination of whether the data packet direction matches the control direction and whether the first target process identifier matches the target process identifier in step S105 can be achieved through the following steps: determining the target mapping relationship used to obtain the first target process identifier; wherein, the target mapping relationship is a first mapping relationship or a second mapping relationship; determining the type of the target mapping relationship as the mapping source; obtaining the process mapping record corresponding to the first target process identifier in the target mapping relationship; determining the timeliness factor based on the time difference between the target time and the first timestamp when processing the network data packet; wherein, the first timestamp is the timestamp of the update or hit closest to the target time recorded in the process mapping record; and determining the timeliness factor based on the time difference between the target time and the first timestamp when processing the network data packet. The binding accuracy factor is determined based on the binding status of the local network address and local port recorded in the process mapping record; the direction protocol consistency factor is determined based on the consistency relationship between the learning direction and protocol type recorded in the process mapping record and the data packet direction and transport layer protocol type in the network data packet; the attribution confidence of the first target process identifier is determined based on the mapping source, timeliness factor, binding accuracy factor, and direction protocol consistency factor, wherein the attribution confidence is used to characterize the degree of consistency between the first target process identifier and the actual process to which the network data packet belongs; if the attribution confidence is greater than or equal to the first preset control threshold, it is determined whether the data packet direction matches the control direction and whether the first target process identifier matches the target process identifier.

[0068] In this embodiment, a target mapping relationship for obtaining the first target process identifier is determined. This target mapping relationship can be a first mapping relationship (i.e., a mapping from a Socket object to a process, stored in a second BPF Map) or a second mapping relationship (i.e., a mapping from a local network tuple to a process, stored in a third BPF Map). The type of this target mapping relationship is determined as the mapping source. For example, if the query is made directly through a Socket pointer, the mapping source is a high-confidence source; if the query is made through a local network tuple, the mapping source is a medium-confidence source.

[0069] Retrieve the process mapping record corresponding to the first target process identifier from the corresponding BPF Map. This record contains information such as the mapping update time, the bound local network address, the local port, the learning direction, and the protocol type.

[0070] The various dimensions of the attribution confidence score are calculated. First, a timeliness factor is determined based on the time difference between the current time when processing network packets (i.e., the target time) and the most recent update or hit time recorded in the process mapping record (i.e., the first timestamp). This timeliness factor reflects the timeliness of the mapping relationship; the smaller the time difference, the higher the timeliness factor, indicating a fresher mapping relationship. Second, a binding accuracy factor is determined based on the binding status of the local network address and local port recorded in the process mapping record. For example, if both the local address and local port are explicitly bound (not wildcard addresses), the binding accuracy is high; if a wildcard address exists and relies on user-space supplementation of the local IP, the binding accuracy is low. Third, a direction protocol consistency factor is determined based on the consistency between the learning direction and protocol type recorded in the process mapping record and the packet direction and transport layer protocol type in the current network packet. If the learning direction and protocol are consistent with the current packet, the consistency factor is high; otherwise, it is low.

[0071] Finally, considering the mapping source, timeliness factor, binding accuracy factor, and direction protocol consistency factor, the attribution confidence of the first target process identifier is determined through weighted scoring or rule-based judgment. This attribution confidence is used to quantitatively characterize the degree of consistency between the queried first target process identifier and the actual process to which the network data packet belongs.

[0072] When the calculated attribution confidence is greater than or equal to the first preset control threshold, the process attribution is considered trustworthy, and the subsequent steps are executed, namely, determining whether the data packet direction matches the control direction in the rate limiting rule, and whether the first target process identifier matches the target process identifier in the rate limiting rule.

[0073] On the other hand, when the attribution confidence is greater than the second preset threshold and less than the first preset threshold, statistical, alarm or non-discarding observations are performed on the network data packets; wherein the second preset threshold is less than the first preset threshold; when the attribution confidence is less than or equal to the second preset threshold, the network data packets are directly allowed to pass.

[0074] The above process introduces a multi-dimensional attribution confidence determination based on mapping source, timeliness, binding accuracy, and protocol consistency. It performs rate limiting matching under the premise of ensuring process attribution trust, effectively avoiding the incorrect rate limiting of non-target process traffic due to misjudgment of process attribution. This significantly reduces the risk of kernel-mode traffic control harming normal business operations and improves the security and accuracy of control.

[0075] For example, by comprehensively considering the mapping source, timeliness factor, binding accuracy factor, and direction protocol consistency factor, the attribution confidence of the first target process identifier is determined through weighted scoring or rule-based judgment. The specific implementation method is as follows:

[0076] A tiered scoring mechanism is used to calculate the attribution confidence score. Each factor is mapped to a specific score, and weight or priority rules are set to ultimately synthesize a numerical confidence score (e.g., 0-100). The specific steps are as follows:

[0077] The first step is to determine the mapping source score. If the target mapping relationship is the first mapping relationship (i.e., obtained directly through the Socket object pointer), it indicates that the data packet belongs to an established connection and is directly associated with the process currently executing the Socket operation. The highest mapping source score is assigned, for example, 100 points. If the target mapping relationship is the second mapping relationship (i.e., obtained through the local network tuple), it is usually used for UDP connectionless protocols. Its accuracy depends on historical binding information. A medium score is assigned, for example, 60 points.

[0078] The second step is to determine the timeliness factor score. Calculate the time difference between the current processing time and the most recent update time or hit time (first timestamp) recorded in the process mapping record. If the time difference is less than the first timeliness threshold (e.g., 5 seconds), it indicates that the mapping relationship is very fresh, and the highest timeliness factor score is assigned, for example, 100 points. If the time difference is between the first and second timeliness thresholds (e.g., 5 to 60 seconds), a medium score is assigned, for example, 50 points. If the time difference exceeds the second timeliness threshold (e.g., 60 seconds), it indicates that the mapping relationship may have expired, and a low score or zero score is assigned, for example, 0 points, to reflect the risk that the process may have exited or the socket may have been closed.

[0079] The third step is to determine the binding precision factor score. Check the binding information in the process mapping record. If the local network address is a specific IP address (not 0.0.0.0 or a wildcard) and the local port is a specific non-zero port, the binding is clear, and the highest binding precision score is assigned, for example, 100 points. If the local address is a wildcard address but the port is clear, and it relies on the user-space pre-written local IP address for supplementation, the binding has some uncertainty, and a medium score is assigned, for example, 50 points. If both the address and port contain wildcards, reused information, or missing key information, a low score is assigned, for example, 0 points.

[0080] The fourth step is to determine the direction protocol consistency factor score. Compare the learned direction and protocol type in the process mapping record with the data packet direction and transport layer protocol type extracted from the current network data packet. If both are completely consistent (e.g., both are TCP and both are outgoing), assign the highest score, such as 100 points; if the protocol is consistent but the direction needs to be inferred or there is inconsistency (e.g., UDP usually has no concept of direction, but records a tuple of the receiving direction, while the current packet is in the sending direction, or vice versa), assign a lower score, such as 20 points; if the protocol or direction completely conflicts, assign zero points.

[0081] Step 5: Synthesize the attribution confidence score. Based on the scores of the above factors, a weighted summation or minimum value rule is used for synthesis. In a preferred embodiment, a weighted summation formula is used:

[0082] The attribution confidence score is calculated as follows: (Mapping source score × W1) + (Timeliness factor score × W2) + (Binding accuracy factor score × W3) + (Direction protocol consistency factor score × W4); where W1, W2, W3, and W4 are preset weights, and W1 + W2 + W3 + W4 = 1. For example, W1 can be set to 0.4 (emphasizing source directness), W2 to 0.3 (emphasizing timeliness), W3 to 0.2, and W4 to 0.1.

[0083] According to some optional embodiments of this application, the step S105 of limiting the number of tokens in the token bucket state storage structure to within the maximum bucket capacity jointly determined by the rate threshold and the burst tolerance parameter can be achieved through the following steps: querying or creating a bucket state associated with the hierarchical state key corresponding to the network data packet; wherein, the bucket state includes the state information of the token bucket; the hierarchical state key is used to characterize the hierarchical position of the token bucket; if the bucket state is created for the first time, initializing the number of currently available tokens in the bucket state according to a preset cold start strategy; wherein, the cold start strategy is configured to initialize the number of currently available tokens to a preset proportion of the maximum bucket capacity; determining the maximum bucket capacity according to the rate threshold and the burst tolerance parameter; obtaining the last update time in the bucket state, and calculating the number of tokens to be replenished according to the time difference between the target time when processing the network data packet and the last update time; increasing the number of currently available tokens in the bucket state by the number of tokens to be replenished, limiting the increased number of currently available tokens to within the maximum bucket capacity, and using the limited number of currently available tokens as the updated number of tokens.

[0084] In this embodiment, firstly, based on the layer to which the data packet belongs, a bucket state (i.e., a record in the token bucket state storage structure or token bucket state mapping) associated with the layer status key (i.e., a status key composed of fields such as process identifier, direction, and protocol, used to characterize the specific position of the token bucket in the rate-limiting layer structure) is queried or created. This bucket state records key status information of the token bucket, including the current number of available tokens, maximum bucket capacity, last update time, and cumulative number of bytes allowed / discarded.

[0085] If the query results show that the bucket state corresponding to the status key at that level does not exist, it is determined to be the first creation, and the bucket state is initialized according to the preset cold start strategy. The cold start strategy is used to balance the service experience of new connections with the strictness of rate limiting. In this embodiment, the cold start strategy is configured to initialize the number of currently available tokens to a preset proportion of the maximum bucket capacity (e.g., 50% or 100%), thereby allowing new connections to have a certain burst sending capacity in the initial stage, avoiding significant delays or stuttering in interactive services due to strict rate limiting. Subsequently, the maximum bucket capacity of the token bucket at that level is determined according to the rate limiting rules of the level to which the bucket state belongs, combined with the rate threshold (i.e., the configured average rate) and the burst tolerance parameter (i.e., the time scale). The maximum bucket capacity can be determined by the product of the rate threshold and the burst tolerance parameter. The larger the burst tolerance parameter, the higher the maximum bucket capacity, and the more short-term burst traffic is allowed.

[0086] After the bucket state is queried or created, the last update time recorded in the bucket state is obtained, and the time difference between the target time (i.e., the current time) for processing the current network data packet and the last update time is calculated. Based on this time difference and the rate threshold, the number of tokens to be replenished in this cycle is calculated. The calculation formula is: Number of tokens to be replenished = Time difference × Rate threshold.

[0087] The calculated number of tokens to be replenished is added to the current available token count in the bucket state. To prevent tokens from accumulating indefinitely due to time jumps, prolonged idle periods, or abnormal configurations, which could cause subsequent instantaneous traffic to far exceed the rate-limiting threshold, the increased current available token count is limited to within the maximum bucket capacity. Specifically, if the increased token count exceeds the maximum bucket capacity, it is truncated to the maximum bucket capacity; otherwise, the increased value is retained. The current available token count after the above limiting operation is determined as the updated token count and written back to the bucket state for subsequent steps to determine whether to deduct or discard tokens based on packet length.

[0088] The above process introduces a cold start strategy to initialize available tokens for new connections to support short bursts, and combines time difference to dynamically replenish tokens while limiting the number of tokens to no more than the maximum bucket capacity determined by the rate threshold and burst tolerance parameters. This effectively balances the business interaction experience with long-term bandwidth limitations, prevents the infinite accumulation of tokens due to long periods of idle time, and ensures the stability and fairness of the rate limiting algorithm.

[0089] In some optional embodiments of this application, when calculating the number of tokens to be replenished, if the time difference is greater than a preset time limit, the time difference is corrected to the preset time limit; when determining the maximum bucket capacity, if the maximum bucket capacity determined based on the rate threshold and the burst tolerance parameter is greater than the preset maximum capacity, the maximum bucket capacity is set to the preset maximum capacity; if the drop rate of the target process within the preset time window is less than a preset threshold, the burst tolerance parameter is increased; if the drop rate of the target process within the preset time window is greater than the preset threshold, the burst tolerance parameter is decreased.

[0090] It is worth noting that, to prevent arithmetic overflow and rate limiting outages caused by time anomalies, prolonged process idleness, or configuration errors, this embodiment introduces a boundary restriction mechanism. When calculating the number of tokens to be replenished, the time difference between the target time for processing network data packets and the last update time of the token bucket is obtained. If this time difference is greater than a preset time limit (e.g., a preset maximum allowed interval), the time difference is corrected to the preset time limit, and replenishment tokens are calculated only according to this limit time. This avoids exceeding the rate limit due to unlimited token accumulation when a large number of data packets suddenly flood in after a long period of idleness, ensuring the predictability of the rate limiting behavior.

[0091] Meanwhile, when determining the maximum bucket capacity of the token bucket, the theoretical maximum bucket capacity is calculated based on the rate threshold (i.e., the configured average rate) and the burst tolerance parameter (i.e., the time scale). If the calculated result is greater than the preset maximum capacity (e.g., the maximum value determined by the data type bit width or the protection threshold), the maximum bucket capacity is forcibly set to the preset maximum capacity to prevent token bucket state data from overflowing or consuming too much kernel memory resources.

[0092] Furthermore, this embodiment introduces an adaptive adjustment mechanism to optimize the rate limiting experience under different service loads. It monitors the drop rate of the target process within a preset time window and dynamically adjusts the burst tolerance parameter (i.e., a time scale used to determine the maximum bucket capacity) based on this rate. If the drop rate of the target process within the preset time window is less than a preset threshold, it indicates that the current rate limiting policy is relatively lenient. The burst tolerance parameter is appropriately increased to allow the target process to accumulate more tokens to support possible subsequent short-term bursts of traffic, thereby improving the short-term service experience. Conversely, if the drop rate is greater than the preset threshold, it indicates that the target process is continuously exceeding the bandwidth limit. The burst tolerance parameter is decreased, the maximum bucket capacity is reduced, and the rate limiting becomes more stringent to prevent excessive long-term bandwidth consumption.

[0093] The above scheme prevents token overflow and rate limiting failure caused by long periods of idle time or abnormal configuration by limiting the time difference and the upper limit of the maximum bucket capacity. It also dynamically adjusts the burst tolerance parameter based on the drop ratio to adaptively optimize the rate limiting strategy, thereby balancing long-term bandwidth constraints and short-term burst service experience while ensuring the stability and security of the rate limiting algorithm.

[0094] As some optional embodiments of this application, the step S106, determining the processing method for the network data packet based on the relationship between the updated token quantity and the data packet length, can be implemented through the following steps: generating a basic state key based on the target process identifier; wherein, the basic state key is used to characterize the identifier of the target process; on the basis of the basic state key, a direction field is superimposed to form a second-level direction state key, or a protocol field is superimposed on the second-level direction state key to form a third-level protocol state key, so as to construct a hierarchical token bucket state structure; wherein, the token bucket corresponding to the basic state key is used to represent the total bandwidth budget of the process, the token bucket corresponding to the direction state key is used to represent the bandwidth budget in a specified direction, and the token bucket corresponding to the protocol state key is used to represent the bandwidth budget on a specified protocol; determining the hierarchical state key corresponding to the network data packet based on the characteristics of the network data packet, and obtaining the updated token quantity in the bucket state associated with the hierarchical state key; wherein, the hierarchical state key It selects one of the following: a basic state key, a second-level directional state key, or a third-level protocol state key. It checks the token limit of each enabled level in hierarchical order. If the updated token count of all enabled levels is greater than or equal to the length of the network data packet, it deducts the tokens corresponding to each level and allows the network data packet to pass. Enabled levels include combinations of levels enabled according to a preset policy, such as those corresponding to the basic state key, the second-level directional state key, and the third-level protocol state key. If the updated token count of any level is less than the data packet length, it performs an overdraft-allowed release operation, a statistical alarm operation, or a discard operation on the network data packet. The overdraft-allowed release operation includes: allowing the network data packet and recording the available token count as a negative value or recording the overdraft limit; subsequent replenished tokens prioritize repaying the overdraft limit. The statistical alarm operation includes: collecting abnormal event information of the network data packet and sending alarm events to user space, without performing a discard operation.

[0095] In the specific implementation of step S106, a basic state key (i.e., a first-level process bucket key) is first generated based on the target process identifier. This basic state key uniquely identifies the target process, and its corresponding token bucket represents the total bandwidth budget of that process. To support more granular flow control, a direction field is superimposed on the basic state key to form a second-level direction state key (i.e., a second-level direction bucket key), or a protocol field is further superimposed on the second-level direction state key to form a third-level protocol state key (i.e., a third-level protocol bucket key), thereby constructing a hierarchical token bucket state structure. The token bucket corresponding to the second-level direction state key represents the bandwidth budget for a specified direction (e.g., inbound or outbound), and the token bucket corresponding to the third-level protocol state key represents the bandwidth budget for a specified protocol (e.g., TCP or UDP). Through this hierarchical key-value structure, the traffic of multiple connections, ports, or short connections of the same target process can be merged and managed, while simultaneously constraining its total bandwidth, bandwidth in each direction, and bandwidth for each protocol, preventing a single direction or protocol from preempting the entire budget.

[0096] Then, based on the characteristics of the current network data packet (including its process, packet direction, and transport layer protocol type), the corresponding layer status key (i.e., one or more combinations of the basic status key, second-level direction status key, or third-level protocol status key) is determined, and the updated token quantity in the bucket state associated with that layer status key is obtained from the token bucket state mapping. The token quota of each enabled layer (i.e., the combination of layers enabled according to rules among the basic status key, second-level direction status key, and third-level protocol status key) is checked according to a preset layer order. When the updated token quantity of all enabled layers is greater than or equal to the length of the current network data packet, the quota is considered sufficient. At this point, the token quantity corresponding to each layer is deducted, and the network data packet is allowed to pass. Simultaneously, the cumulative number of bytes allowed and the timestamp for each layer are updated.

[0097] If the updated token count at any level is less than the packet length, it indicates insufficient bandwidth. Based on a preset policy, the network packet will be processed using one of the following methods: allowing overdraft, issuing a statistical alarm, or dropping the packet. Allowing overdraft aims to smooth out bursts of traffic. Specifically, it allows the current network packet to pass through, records the available token count as negative or records the overdraft amount (i.e., token debt). Tokens added in subsequent time periods will be used to repay this overdraft amount until the amount returns to a non-negative state. Issuing a statistical alarm aims to provide observability without impacting service. Specifically, it collects detailed information about the abnormal event (such as process ID, reason for dropping, etc.) and sends an alarm event to user space via an event channel, but does not perform a dropping operation; the packet is allowed to pass normally. If overdraft is not enabled and no alarm is selected, a dropping operation is performed, i.e., the network packet is directly dropped, and a dropping event is sent to user space, thus providing rate feedback to the target process.

[0098] The above process constructs a hierarchical token bucket state structure based on the basic, directional, and protocol levels to achieve multi-dimensional and refined budget control over the total bandwidth of the target process, the bandwidth of each direction, and the bandwidth of each protocol. It provides flexible handling strategies such as allowing overdraft, statistical alarms, or dropping when the quota is insufficient, thereby ensuring the effectiveness of bandwidth limiting while taking into account the smoothness of business bursts and the observability of operation and maintenance, and avoiding the risk of resource contention or business interruption caused by single-dimensional rate limiting.

[0099] Specifically, the process of allowing overdrafts on network data packets can include the following steps: calculating the difference between the data packet length and the updated token count to obtain the single overdraft byte count; determining whether the single overdraft byte count is less than or equal to a preset single overdraft threshold; if the single overdraft byte count is less than or equal to the single overdraft threshold, determining to allow overdrafts and updating the bucket state associated with the hierarchical status key; subtracting the data packet length from the current available token count in the bucket state to obtain the overdraft limit, and recording the overdraft limit in the bucket state; wherein, tokens replenished in subsequent cycles are preferentially used to offset the overdraft limit.

[0100] It should be noted that if the updated token count at any level is less than the length of the current network data packet, it indicates that the current bandwidth is insufficient to support the complete transmission of the packet. In this case, a further assessment is needed to determine whether the packet should be allowed a limited overdraft. To do this, the difference between the network data packet length and the updated token count in the bucket state associated with the current level's state key is first calculated. This difference is defined as the single overdraft byte count, used to quantify the portion of the current data packet exceeding the available tokens. Then, the single overdraft byte count is compared with a preset single overdraft threshold to determine if the overdraft is within a tolerable safety range. The preset single overdraft threshold can be pre-configured based on the service's tolerance for sudden traffic spikes and system stability requirements. This prevents extreme negative values ​​in the token bucket state caused by a few extremely large data packets, which could affect the stability of subsequent rate-limiting algorithms.

[0101] If the calculated number of bytes exceeding the limit in a single instance is less than or equal to the preset single overdraft threshold, an overdraft-allowing operation is performed. Under this operation, the bucket state associated with the hierarchical state key is updated. Specifically, this involves subtracting the length of the current network data packet from the current number of available tokens in the bucket state. Since the data packet length is greater than the number of available tokens, the result will be negative. This negative value is recorded as the overdraft limit (or token debt) and stored in the bucket state. By recording this overdraft limit, it is clearly indicated that the current process's usage of the hierarchical bandwidth budget has exceeded its current available range. The network data packet is then allowed to continue transmitting in the network path, thereby avoiding service interruptions or increased latency caused by strict rate limiting.

[0102] During subsequent token replenishment cycles, when calculating the number of tokens to be replenished based on the new time difference, the debt repayment logic is executed first. That is, before or simultaneously with adding the newly replenished tokens to the bucket state, these new tokens are first used to offset the previously recorded overdraft. Once the overdraft is fully repaid (i.e., the current number of available tokens returns to a non-negative state), the remaining replenished tokens are considered as the currently available bandwidth budget and used to support the transmission of subsequent data packets.

[0103] The smoothing process based on overdraft limits described above can provide a smoother rate limiting curve than a fixed threshold when dealing with common instantaneous bursts of traffic in the network (such as TCP slow start phase or application layer bursts). This ensures both the limitation of the long-term average bandwidth of the target process and effectively reduces frequent packet loss caused by a single large packet slightly exceeding the limit, thereby improving user experience and business continuity.

[0104] Furthermore, performing a discarding operation on network packets can specifically include the following steps.

[0105] Determine if any of the following discard conditions are met: the cumulative overdraft limit in the hierarchical bucket state corresponding to the network packet exceeds the preset cumulative overdraft threshold; the number of bytes exceeding the limit in a single instance exceeds the preset single overdraft threshold; the overdraft allowance function is not enabled and the packet length of the network packet is greater than the updated token quantity; if any of the discard conditions are met, execute the discard operation; when executing the discard operation, obtain the transport layer protocol type of the network packet, and send the corresponding packet loss statistics event to the user space according to the transport layer protocol type; specifically, if the transport layer protocol type is Transmission Control Protocol, send a packet loss statistics event including the Transmission Control Protocol identifier to the user space; if the transport layer protocol type is User Datagram Protocol, send a packet loss statistics event including the User Datagram Protocol identifier to the user space.

[0106] Understandably, the specific dropping conditions include one of the following three scenarios: First, the cumulative overdraft limit (i.e., the total amount of historically outstanding token debt) in the hierarchical bucket state corresponding to the network data packet exceeds the preset cumulative overdraft threshold, indicating that the target process has been exceeding the bandwidth limit for a long time, triggering the long-term overdraft protection mechanism; Second, the number of bytes exceeding the limit in a single instance (i.e., the difference between the current data packet length and the number of available tokens) exceeds the preset single overdraft threshold, indicating that the current burst traffic is too large, and the excess amount of a single data packet exceeds the boundary of allowed smooth processing; Third, if the overdraft function is not enabled in the configuration (i.e., the token debt mechanism is disabled), and the data packet length is greater than the updated number of tokens, it is directly determined that the limit is insufficient and must be dropped. Through this multi-condition logical judgment, a balance can be flexibly found between allowing moderate bursts and strict rate limiting according to business scenarios and configuration strategies.

[0107] If any of the above discarding conditions are met, a discarding operation will be performed, meaning the network data packet will be directly discarded, preventing it from entering or leaving the network protocol stack. To provide observability and facilitate auditing and diagnosis in user space, the transport layer protocol type of the network data packet is obtained simultaneously with the packet discarding, and a corresponding packet loss statistics event is sent to user space based on the protocol type. Specifically, structured events are reported to the user space control program via the BPF Ring Buffer (or a kernel-to-user space event channel such as perf event). If the transport layer protocol type of the network data packet is TCP, the generated packet loss statistics event will contain an explicit TCP identifier so that user space can identify that the packet loss may trigger the TCP sender's congestion window adjustment and retransmission mechanism; if the transport layer protocol type is UDP, the generated packet loss statistics event will contain a UDP identifier, indicating to user space that the packet loss belongs to an unreliable transmission scenario, which may be tolerated by real-time services or handled by the application layer itself.

[0108] The above process ensures that discarding operations are only performed when the target process is severely overdrawn or overdrawn is not allowed by setting multi-dimensional discarding conditions such as cumulative overdraft threshold, single overdraft threshold, and overdraft function switch, thus avoiding accidental damage to services. In addition, it sends packet loss statistics events with specific identifiers to the user space in combination with the transport layer protocol type (TCP or UDP), realizing protocol-aware fine-grained rate limiting and observability, which makes it easier to distinguish between congestion feedback signals and unreliable transmission packet loss, thereby optimizing bandwidth management strategies.

[0109] As some optional embodiments of this application, after querying the first target process identifier corresponding to the first network connection object identifier, the following steps can also be performed: performing a state aging check on the process mapping or network tuple mapping; wherein, the state aging check includes: obtaining the most recent hit time or the most recent update time of the process mapping or network tuple mapping; if the difference between the most recent hit time or the most recent update time and the target time when processing network data packets exceeds a first preset aging threshold, deleting the corresponding mapping relationship; after limiting the number of tokens in the token bucket state storage structure to within the maximum bucket capacity jointly determined by the rate threshold and the burst tolerance parameter, the method further includes: obtaining the most recent hit time or the most recent update time in the token bucket state; if the difference between the most recent hit time or the most recent update time and the target time when processing network data packets exceeds a second preset aging threshold, deleting the corresponding token bucket state.

[0110] In this embodiment, to reduce kernel state occupancy in long-running scenarios and prevent incorrect attribution caused by stale mappings, a state aging and reclamation mechanism is introduced. This mechanism performs independent state aging checks on process mappings (i.e., the association between Sock object pointers stored in the second BPF Map and process information) and network tuple mappings (i.e., the association between local network tuples stored in the third BPF Map and process information).

[0111] First, the most recent hit time or most recent update time recorded in these mappings is obtained and compared with the target time when the network data packet is being processed. If the time difference between the two exceeds a first preset aging threshold (which can be dynamically adjusted according to network load or configuration), it indicates that the relevant process or network connection has been inactive for a long time. The mapping relationship is then determined to be invalid, and a deletion operation is performed to release kernel resources. In this way, unused process ownership information can be cleaned up in a timely manner, avoiding ownership confusion when new processes reuse the same Socket object or port, thereby ensuring the accuracy of process ownership query.

[0112] Simultaneously, the rate-limiting states stored in the first BPF Map, using the PID as the key, also undergo a similar state aging and recycling process. After limiting the number of tokens to no more than the maximum bucket capacity, the most recent hit time or most recent update time recorded in the token bucket state is retrieved. If the difference between this time and the current target time exceeds a second preset aging threshold, it indicates that the target process has not generated network traffic for a long time, and the corresponding token bucket state is no longer necessary to retain. At this time, the token bucket state is deleted, releasing the BPF Map space it occupies so that other processes or rules may reuse this storage structure in the future.

[0113] The above process, by setting a first preset aging threshold and a second preset aging threshold, performs independent aging checks and deletion operations on process mapping, network tuple mapping, and token bucket state, respectively. This can promptly clean up invalid mappings that have not been hit for a long time and idle token bucket states, thereby reducing the memory usage of the kernel-mode BPF Map, preventing performance degradation caused by excessive state table capacity, and avoiding incorrect process ownership associations caused by stale mappings when new processes reuse identifiers, thus ensuring the long-term stable operation of network flow control and the accuracy of ownership relationships.

[0114] In some optional embodiments, before determining whether the data packet direction matches the control direction and whether the first target process identifier matches the target process identifier, the following steps may be performed: determining whether any of the following abnormal conditions exist: network packet parsing failure, the first target process identifier query result is empty, the rate limiting rule query result is empty, or the attribution confidence corresponding to the first target process identifier is less than a preset control threshold; if any of the abnormal conditions exist, the network data packet is allowed, and an abnormal diagnosis event is sent to the user space; wherein, the abnormal diagnosis event includes at least one of the following: network packet parsing failure event, process mapping missing event, rule missing event, confidence insufficient event, and abnormal allowance statistics event; the process mapping missing event is used to indicate that the first target process identifier was not found; the rule missing event is used to indicate that the corresponding rate limiting rule was not found; the confidence insufficient event is used to indicate that the attribution confidence corresponding to the first target process identifier is less than a preset control threshold; the abnormal allowance statistics event is used to indicate the network data packet information allowed due to abnormal conditions.

[0115] In this embodiment, the following abnormal conditions are first determined in the current processing flow: First, network packet parsing fails, that is, the header information of the network data packet cannot be correctly parsed or the necessary context cannot be obtained in the kernel path; Second, the query result of the first target process identifier is empty, such as the query of the second BPF Map or the third BPF Map failing to find the process identifier corresponding to the network connection object (Sock object or local network tuple) associated with the current data packet; Third, the query result of the rate limiting rule is empty, that is, no effective rate limiting configuration for the target process is found in the first BPF Map; Fourth, the attribution confidence corresponding to the first target process identifier is less than the preset control threshold, that is, although the process attribution is found, according to the calculation result of the attribution confidence determination module, the confidence of the attribution relationship is insufficient to support the execution of the determined rate limiting control action.

[0116] If any of the above-mentioned anomalies are detected, a conservative pass-through policy will be implemented to ensure business continuity. This means the network data packet will be allowed to pass directly without subsequent token bucket limit checks or dropping. Simultaneously, to provide observability and assist administrators in fault diagnosis, a corresponding anomaly diagnostic event will be sent to the user space.

[0117] Anomaly diagnostic events are asynchronously reported to the user-space control program via the BPF Ring Buffer (or a kernel-to-user-space event channel such as perf event). Anomaly diagnostic events include, but are not limited to, the following types: network packet parsing failure events, used to indicate abnormal packet header parsing; missing process mapping events, used to indicate that the first target process identifier was not found, prompting the administrator to check the process-Socket association establishment status; missing rule events, used to indicate that the corresponding rate-limiting rule was not found, prompting the administrator to check the rule distribution status; insufficient confidence events, used to indicate that the attribution confidence corresponding to the first target process identifier is lower than the preset control threshold, prompting the administrator to check the attribution learning logic or changes in the network environment; and anomaly release statistics events, used to record network packet information released due to the above anomalies, facilitating subsequent analysis of the false release ratio and locating the root cause of the anomaly.

[0118] The above process introduces multiple anomaly detection methods, such as network packet parsing, process attribution query, rule matching, and confidence verification, before performing strict rate limiting. When an anomaly is detected, conservative permission is granted and structured diagnostic events are reported. This effectively prevents misjudgments and false alarms caused by missing kernel context, uncertain attribution, or missing configuration, thereby ensuring network service continuity while improving the observability of fault diagnosis.

[0119] According to some preferred embodiments of this application, after obtaining the rate limiting rules for network traffic, the following steps can also be performed: loading a dynamically executable kernel program, mounting the first subroutine of the kernel program to the process-network connection association path, mounting the second subroutine of the kernel program to the network packet processing path, and writing the rate limiting rules into the first shared storage structure; wherein the first subroutine and the second subroutine are different subroutines;

[0120] The first subroutine performs the following steps: establishing a first mapping relationship between the network connection object identifier and the target process identifier, and establishing a second mapping relationship between the local network tuple and the target process identifier; writing the first mapping relationship into the second shared memory structure, and writing the second mapping relationship into the third shared memory structure.

[0121] The second subroutine performs the following steps: extracting the packet direction, transport layer protocol type, and the first local network tuple and first network connection object identifier corresponding to the network packet from the network packet; if the transport layer protocol type is User Datagram Protocol (UDP), querying the first target process identifier corresponding to the first local network tuple based on the second mapping relationship stored in the third shared storage structure; if the transport layer protocol type is Transmission Control Protocol (TCP), querying the first target process identifier corresponding to the first network connection object identifier based on the first mapping relationship stored in the second shared storage structure; reading the rate limiting rule from the first shared storage structure, determining whether the packet direction matches the control direction, and whether the first target process identifier matches the target process identifier; if all match, limiting the number of tokens in the token bucket state storage structure to within the maximum bucket capacity determined by the rate threshold and burst tolerance parameter; and determining the processing method for the network packet based on the relationship between the updated number of tokens and the packet length of the network packet.

[0122] In this embodiment, the first subroutine is attached to the process-network connection associated path (e.g., a kernel path related to socket operations, including hooks for sending, receiving, connecting, or listening). This path is used to capture context information when the process creates a network connection. Simultaneously, the second subroutine is attached to the network packet processing path (e.g., Netfilter local receive hooks and local send hooks). This path is used to intercept and process packets as they flow through the kernel protocol stack. Furthermore, the rate-limiting rules issued by user space (including target process identifier, rate threshold, control direction, and burst tolerance parameters) are written into the first shared memory structure (i.e., the first BPF Map) so that the kernel-mode program can quickly query them at runtime.

[0123] The first subroutine, mounted on the process-network connection association path, establishes and maintains the process ownership relationship. When a socket operation occurs, the first subroutine reads the process information of the current task (such as the process ID PID) and the network connection object identifier (such as a Sock object pointer). For connection-oriented protocols (such as TCP), the first subroutine establishes a first mapping relationship between the network connection object identifier and the target process identifier, and writes this mapping relationship into a second shared memory structure (i.e., the second BPF Map). For connectionless protocols (such as UDP), due to the lack of persistent connection state, the first subroutine further extracts the local network tuple (including the local IP address, local port, and protocol number), establishes a second mapping relationship between the local network tuple and the target process identifier, and writes this mapping relationship into a third shared memory structure (i.e., the third BPF Map).

[0124] A second subroutine, mounted on the network packet processing path, performs packet parsing, attribution lookup, and rate limiting. When a network packet arrives, the second subroutine first extracts key information about the packet, including its direction (inbound or outbound), transport layer protocol type (e.g., TCP or UDP), the first local network tuple corresponding to the packet, and the first network connection object identifier. Next, it selects the appropriate attribution lookup path based on the transport layer protocol type: if the transport layer protocol type is UDP, it uses the first local network tuple to query the corresponding first target process identifier based on the second mapping relationship stored in the third shared storage structure; if the transport layer protocol type is Transmission Control TCP, it uses the first network connection object identifier to query the corresponding first target process identifier based on the first mapping relationship stored in the second shared storage structure.

[0125] After obtaining the first target process identifier, the second subroutine reads the rate limiting rules for the target process from the first shared storage structure and performs a matching judgment.

[0126] The main differences between the first and second subroutines lie in their mounted kernel paths, triggering times, acquired context information, and core functionalities. The first subroutine is mounted on the process-network connection association path (such as the Socket operation path, including hooks for connecting, sending, and receiving). It is triggered when a process is created, bound, listening, or performing Socket I / O operations. It primarily acquires the context information of the current task (process) and the Socket object pointer. Its core function is to establish and maintain the mapping relationship between the Socket object identifier and the target process identifier, and to establish the mapping relationship between the local network tuple and the target process identifier for the UDP protocol, in order to solve the problem of process ownership establishment and learning.

[0127] The second subroutine is attached to the network packet processing path (such as the Netfilter local send / receive hook or the TC / XDP path). It is triggered when the network packet passes through a specific checkpoint during transmission in the kernel protocol stack. It mainly obtains the structured information of the packet (such as direction, protocol header, source / destination address and port, socket pointer, etc.). Its core function is to perform affiliation query based on the mapping relationship established by the first subroutine, and combine it with rate limiting rules to perform direction matching, destination matching, token bucket determination, and finally, allow or discard decisions. This is used to solve the problem of real-time control and execution at the packet level.

[0128] The advantages of distinguishing between the first and second subroutines are mainly reflected in the following aspects: First, separating the complex process attribution learning logic from the high-frequency packet processing logic avoids time-consuming process information scanning or complex Socket state parsing in the packet processing path, thereby reducing the performance overhead of the packet processing path and ensuring high throughput and low latency in network forwarding. Second, the first subroutine actively updates the mapping at key nodes in the Socket lifecycle (such as connect and bind), ensuring that the kernel has the latest and most accurate correspondence between processes and network connections; the second subroutine only uses the query results for fast matching, reducing misjudgments caused by polling or delayed inference. Third, since the two subroutines are mounted independently, targeted optimization, debugging, or replacement (such as replacing different hook points or algorithms) can be performed on the Socket path and the packet path respectively, without interference between them. Finally, separating the complex attribution judgment logic from the high-frequency triggered packet path reduces the risk of kernel-level crashes caused by failure or exceptions in the execution of complex logic, while ensuring that even if the attribution query temporarily fails, the packet processing path can still be conservatively allowed through the exception protection mechanism, ensuring business continuity.

[0129] Figure 2 This is a schematic diagram illustrating the architecture and interaction of a network traffic control system according to an embodiment of this application, such as... Figure 2 As shown, the system includes: a network tuple parsing module, a direction-aware rate limiting module, an attribution confidence determination module, a hierarchical token bucket state management module, a state aging and recycling module, and an anomaly protection module in the kernel space; and an eBPF loading and mounting module, a command-line configuration module, a rule distribution module, and an event consumption and display module in the user space.

[0130] Figure 2 The system shown can not only perform rate limiting on a single target process, but also extend to perform differentiated rate limiting based on combinations of process, direction, protocol, and local network tuples. Figure 2 In the system shown, the user space is used to receive administrator configurations, load kernel-mode programs, issue rules, and consume events. The kernel space is used to establish process ownership in the socket operation path, parse data packets in the network packet path, and complete control decisions through the direction-aware rate limiting module, the ownership confidence determination module, the hierarchical token bucket state management module, the state aging and recycling module, and the exception protection module. The rule issuance module in the user space interacts with the direction-aware rate limiting module in the kernel space through a BPF Map, and the event circular buffer is used to feed back the control process to the user space. The function of each module is explained in detail below.

[0131] Command-line configuration module: Used to receive network traffic control policy parameters input by the administrator. Its core functions include receiving the target process PID, rate threshold (supporting K / M / G suffix conversion, internal unit is bytes per second), control direction (inbound or outbound), and time scale (used to determine the token bucket burst tolerance window). In extended embodiments, this module also supports receiving protocol type, port range, process group, priority level, maximum burst capacity, and exception handling policy to form multi-dimensional fine-grained control rules.

[0132] The eBPF loading and mounting module is used for the lifecycle management of kernel-mode eBPF programs. Its functions include loading pre-compiled eBPF bytecode and mounting different eBPF subroutines to specific kernel hook points: mounting to Socket operation paths (such as send, receive, connect, and listen hooks) to establish the association between the process and the Socket; and mounting to Netfilter's local transmit / receive paths (including local receive and send hooks) to perform real-time parsing and flow control of network packets.

[0133] The rule delivery module synchronizes user-space configured policies to kernel space. Specifically, it writes rules (containing at least the target process PID, rate threshold, control direction, and time scale) into the first BPF Map. In multi-rule scenarios, this module also organizes rules using rule indexes, priorities, or matching masks (indicating the matching validity of fields such as PID, direction, and protocol) to support policy execution at different granularities, from rate limiting by process only to rate limiting by process, direction, and protocol.

[0134] Event Consumption and Display Module: This module receives and processes structured events reported from the kernel. It polls kernel event channels (such as BPF Ring Buffer) to obtain event information such as process mapping, network tuple parsing, packet passing, dropping, and anomaly protection, and converts it into visual data or log output for administrators to audit, diagnose, and adjust policies.

[0135] The network tuple parsing module is deployed in the Netfilter local receive or local send path. Its main function is to perform secure parsing of incoming network packets. Specifically, this includes reading the sk_buff structure, verifying the packet length, network layer protocol type, and header length, and then parsing the transport layer header to obtain the local network address, port, and protocol number, providing basic data for subsequent attribution queries and rate limiting determination.

[0136] The process attribution confidence assessment module is used to classify the confidence level of the retrieved process attribution results to balance control precision and the risk of false positives. This module calculates the confidence level based on factors such as the source of attribution (direct socket pointer hit or local tuple inference), timeliness (mapping update time), binding precision (wildcard address or explicit binding), and direction / protocol consistency. Based on the confidence level, this module decides to perform tiered actions: high confidence allows for drop-type rate limiting; medium confidence only performs statistics or alarms; low confidence allows direct passage, thus ensuring control effectiveness while avoiding false positives on non-target traffic.

[0137] Direction-Aware Rate Limiting Module: This module executes the control decision logic for data packets. After receiving the data packet parsing result, it first performs direction gating, proceeding to the next step only if the data packet's direction matches the control direction in the rule; secondly, it performs target gating, executing token bucket judgment only if the data packet's PID matches the target PID in the rule. If neither condition is met, the data packet is allowed to pass directly, ensuring that the rate limiting policy only applies to the specified target process and direction.

[0138] The hierarchical token bucket state management module is responsible for maintaining the rate-limiting state based on PIDs. This module uses PIDs as the basic state key and can further add fields such as direction and protocol to form a first-level process bucket, a second-level direction bucket, and a third-level protocol bucket. Its functions include: querying or creating bucket states and replenishing tokens according to the configured rate based on the difference between the current time and the last update time; limiting the number of tokens to within the maximum bucket capacity determined by the rate threshold and time scale; determining the quota according to the hierarchy, deducting tokens and allowing passage only when all buckets at each level meet their quotas; if the quota is insufficient, recording the debt and allowing passage or discarding data packets based on the debt policy.

[0139] State aging and reclamation module: Responsible for the lifecycle management of kernel resources. This module monitors the most recent hit time of process mappings, network tuple mappings, and token bucket states. When it detects that a state has been unhit for a long time or that the system is under capacity pressure, it automatically performs lazy cleanup, deletes expired states, and reclaims kernel resources to reduce memory consumption during long-term operation and reduce incorrect attribution caused by stale mappings.

[0140] Anomaly Protection Module: Responsible for ensuring system robustness. When anomalies such as network packet parsing failure, missing process ownership, non-existent rules, unavailable critical contexts, or insufficient ownership confidence are detected, this module enforces a conservative allow-through policy to ensure that normal communication of non-target services is not blocked due to anomalies in kernel-mode control logic. It can also report diagnostic events for subsequent analysis.

[0141] Furthermore, the attribution confidence determination module is also used to classify the process attribution results. This module can calculate the attribution confidence based on factors such as mapping source, update time, protocol type, direction, whether the port is wildcard bound, and whether the local address is supplemented by user space. The specific implementation steps are as follows.

[0142] Step S1: Determine the source of ownership. Based on the query path of the packet ownership information, determine the source level: High-trust source: directly hits the process mapping through the sock pointer in sk_buff; Medium-trust source: hits the process mapping through the UDP local network tuple (local IP, port, protocol); Source to be confirmed: Ownership information depends on wildcard binding, user-space supplemented local address, or historical learning results.

[0143] Step S2: Calculate the timeliness factor. Read the most recent update time or most recent hit time of the attribution mapping, calculate the difference with the current time, and define the timeliness level according to the threshold: High: the difference is less than the first timeliness threshold; Medium: the difference is between the first timeliness threshold and the second timeliness threshold; Low: the difference exceeds the second timeliness threshold (triggers state aging or relearning if necessary).

[0144] Step S3: Calculate the binding precision factor. Determine the precision level based on the binding status of the local address and local port: High: Both the local address and local port are explicitly bound; Medium: The local address is a wildcard address but the port is explicit, and the local address is supplemented by user space; Low: Both the address and port have wildcard, reuse, or missing conditions.

[0145] Step S4: Calculate the direction and protocol consistency factors. Compare the learned information of the attribution mapping with the characteristics of the current data packet: Increase confidence: The learned direction and protocol type are consistent with the current data packet direction and protocol; Decrease confidence: Only the protocol is consistent, but the direction needs to be inferred; Determine invalid / low confidence: The protocol or direction is inconsistent.

[0146] Step S5: Synthesize the confidence level. Based on the above factors, the final confidence level is synthesized using a weighted score, taking the minimum level, or a rule table. For example: High confidence: Direct Socket pointer hit, fresh mapping, precise binding, and consistent direction protocol; Medium-high confidence: UDP tuple hit, relatively new mapping, and clearly defined port; Medium-low / low confidence: Relies only on historical tuples, wildcard address supplementation, or mappings that haven't been updated for a long time.

[0147] Step S6: Execute tiered actions. Implement corresponding control strategies based on the synthesized confidence level: Strong control: When the confidence level reaches the first threshold, drop-type rate limiting is allowed; Weak control / observation: When the confidence level is between the second and first thresholds, only statistical, alarm, or non-drop-type observations are executed; Conservative release: When the confidence level is below the second threshold, data packets are directly released, and low-confidence events are reported.

[0148] Furthermore, the hierarchical token bucket state management module is also used to perform the following steps:

[0149] Step S1: Construct the basic state key. The basic state key includes at least the target process PID, and may further include the process start time, process namespace identifier, or rule number to reduce the risk of state misuse caused by PID reuse. In a single-rule embodiment, the basic key can be {pid}; in a multi-rule or containerized embodiment, the basic key can be {pid, start_time, netns, rule_id}.

[0150] Step S2: Construct hierarchical status keys. The first-level process bucket uses a base status key to represent the total budget of the target process; the second-level directional bucket adds a direction field to the base status key, forming {base_key, direction}; the third-level protocol bucket adds a protocol field to the directional bucket key, forming {base_key, direction, protocol}. If the system does not enable directional or protocol buckets, the corresponding fields can be omitted.

[0151] Step S3: Query or create bucket status. Each bucket must include at least the last update time, the current number of available tokens, the maximum bucket capacity, the cumulative number of bytes allowed, the cumulative number of bytes dropped, the most recent hit time, and the optional debt value. If the target process hits the rule for the first time but the bucket does not exist, an initial bucket is created, and the initial token capacity is set according to the configured rate, time scale, and cold start strategy.

[0152] Step S4: Replenish tokens and limit capacity. If a bucket already exists, calculate the number of tokens to be replenished in this cycle based on the time difference between the current time and the last update time. The replenishment amount is equal to the product of the configured rate and the time difference, and different rate parameters can be used according to the bucket level. The number of replenished tokens must not exceed the maximum bucket capacity; the maximum bucket capacity is determined by both the configured rate and the time scale. The larger the time scale, the higher the allowable short bursts; the smaller the time scale, the stricter the rate limit.

[0153] Step S5: Determine the quota by level. When a data packet arrives, first check the quota of the process bucket, then check the quota of the direction bucket, and finally check the quota of the protocol bucket. Only when all enabled buckets meet the quota required for the data packet length will the tokens of each layer be deducted and the data packet be allowed to pass; if the quota of any layer is insufficient, the decision will be made to allow the packet to pass, record the debt, issue an alarm, or discard it based on the debt policy, anomaly policy, and protocol-aware packet loss policy.

[0154] Step S6: Update statistics and timestamps. Regardless of whether a request is granted, a debt is incurred, or a request is dropped, the module updates the most recent hit time and updates the cumulative number of bytes granted, the cumulative number of bytes dropped, the current number of tokens, and the debt value based on the results. By using the PID as the base status key and overlaying fields such as direction and protocol, the system can both limit the total bandwidth of the target process and apply independent budgets to different directions and protocols.

[0155] In some optional embodiments, the hierarchical token bucket state management module supports the construction of multi-level token buckets to implement fine-grained bandwidth control: Level 1 Process Bucket: Based on the base state key (PID), used to limit the overall total bandwidth budget of the target process; Level 2 Directional Bucket: Overlays a directional field on the base key, used to constrain the independent bandwidth budgets for the ingress and egress directions respectively; Level 3 Protocol Bucket: Overlays a protocol field (such as TCP, UDP) on the directional bucket key, used to impose independent bandwidth budgets on specific transport layer protocols. When a data packet arrives, the quota is checked sequentially according to the hierarchical order of Level 1 Process Bucket → Level 2 Directional Bucket → Level 3 Protocol Bucket. When the current available tokens in all level buckets meet the data packet length requirement, token deduction is performed and the data packet is allowed to pass; if the quota in any level is insufficient, the corresponding exception handling mechanism (such as dropping or debt recording) is triggered.

[0156] This embodiment may also include a token debt mechanism. This mechanism smooths the rate-limiting curve by tolerating small, instantaneous over-limits, avoiding frequent packet loss. When the packet length is slightly greater than the currently available tokens but does not exceed a preset debt threshold, the system may choose to allow the packet and record the token count as a negative value or record the corresponding debt value. In subsequent cycles, supplementary tokens will be used first to repay the debt. If the accumulated debt exceeds the preset threshold, the system will perform a discard operation to prevent the target process from overdrawing bandwidth for a long time.

[0157] This embodiment may also include a cold start protection mechanism, which is used to adapt to the real-time requirements of different business scenarios. For the target process that first hits the rate-limiting rule, the initial token capacity setting strategy is determined by the user-space rule configuration or the system default strategy. Burst support mode: The initial token capacity is set to a portion or all of the maximum bucket capacity, giving newly established connections limited burst startup capabilities, suitable for interactive services; Strict rate-limiting mode: The initial token capacity is set to zero, causing the target process to start from a strictly rate-limited state, suitable for background batch services.

[0158] It should be noted that this embodiment uses a process-based token bucket algorithm, rather than a simple fixed-threshold discarding algorithm. This algorithm maintains the bandwidth budget on a process-by-process basis, linking token replenishment to actual elapsed time, token consumption to packet length, and bucket capacity to a user-specified burst tolerance window. All connections, ports, and short connections of the target process share the same process-level bandwidth budget, effectively preventing bypassing rate limits by splitting connections. The core logic is: replenishing the quota at the configured rate within time intervals; allowing packets with a length less than or equal to the current quota while deducting quota; and when the quota is insufficient, deciding whether to allow packets with debt or discard them based on debt thresholds, priorities, and exception policies, and reporting the results.

[0159] Packet loss rate limiting allocates a byte limit per unit time using a token bucket. Packets exceeding this limit are selectively discarded, and the effectiveness varies depending on the transport layer protocol. For TCP: Excessive packet loss triggers TCP congestion control mechanisms (such as fast retransmission, timeout retransmission, and congestion window adjustment), causing the sender to automatically reduce its sending rate, thus bringing the actual throughput closer to the long-term average rate set by the token bucket. For UDP: Utilizing UDP's non-reliable delivery characteristic, excessive packet loss does not disrupt the protocol state machine. Real-time services can tolerate a small amount of data loss, while reliable services handle retransmissions themselves at the application layer. Through this controlled discarding, the system achieves bandwidth constraint without modifying the application layer logic.

[0160] Optionally, to avoid accidentally affecting non-target services, the system strictly limits the execution conditions for packet dropping. Dropping is only performed when the packet's ownership is clear, the ownership confidence level meets the standard, the direction matches the rule, the target PID is consistent, and the token limit is insufficient (and the debt policy does not allow overdraft). For packets that do not meet the above conditions, the system adopts a strategy of allowing, statistically analyzing, or alarming to ensure that packet loss only serves as a feedback signal of "excessive communication by the target process," rather than a brutal blockade of overall traffic.

[0161] Optionally, the system can dynamically adjust the burst window based on the drop rate, release rate, and bucket vacancy status. When the target process consistently falls below the configured rate, a limited number of tokens are allowed to accumulate to support subsequent short-term bursts; when dropouts are continuously triggered, the burst window is reduced or a strict rate limit is maintained, and user-mode adjustments are prompted via an event channel. This mechanism optimizes short-term experience and stability under different loads without changing the long-term average rate cap.

[0162] Optionally, to prevent arithmetic overflow or abnormal time differences from causing rate limiting anomalies, the token bucket state management module implements boundary limits on time differences, the number of replenished tokens, and the maximum bucket capacity. For example, when the interval between two hits exceeds a preset upper limit, tokens are replenished only according to the upper limit time; when the computation capacity exceeds the maximum representable value, saturation limits are applied. These boundary handling measures ensure that the system maintains predictable and stable behavior even under long periods of idle time, time jitter, or abnormal configurations.

[0163] Figure 3 This is a flowchart of another network traffic control method according to an embodiment of this application. Figure 3 for Figure 2 The control flow of the system shown is as follows: Figure 3 As shown, the method includes the following steps:

[0164] Step S301: The user inputs the target PID, speed, direction, and time scale.

[0165] Step S3021: Record the eBPF program in user mode.

[0166] Step S3022: Write the process rate limiting rule Map.

[0167] Step S3023: Write the local ID Map.

[0168] In step S301, the user inputs the target process identifier (PID), the desired bandwidth rate threshold, the network direction for implementing rate limiting (inbound or outbound), and the time scale parameter used to calculate the token bucket capacity via the control terminal, thereby completing the initial configuration of the flow control policy. Step S3021 involves the user-space program loading the compiled eBPF bytecode file into the kernel space, preparing for subsequent kernel-space execution. Step S3022 writes the key rule data configured in step S301, such as the target PID, rate, direction, and time scale, into the kernel-space BPF Map, serving as the basis for subsequent packet matching. Step S3023 writes the local machine's IP address information into a specific BPF Map, primarily used to assist in determining the attribution of connectionless protocols (such as UDP), resolving IP identification issues in wildcard address binding scenarios.

[0169] Step S303: Attach the socket operation hook.

[0170] Step S3031: Save the socket to process mapping in the socket operation path.

[0171] Step S3032: Save the local tuple to the process mapping in the UDP receive path.

[0172] Step S303 mounts the eBPF program to the Linux kernel's Socket operation path hook to capture context information when a process initiates a network connection, sends or receives data. Step S3031, upon triggering a Socket operation, reads the process ID and process name of the current task, associates the Socket object pointer (sock) in the kernel with the process information, and writes it into the BPF Map, thereby establishing a direct mapping relationship between the Socket and the process, ensuring that data packets with connection-oriented protocols can be accurately attributed. Step S3032, specifically for the UDP protocol's receive path, reads the local IP address, port, and protocol number during Socket operations, constructs a local network tuple, associates it with the process information, and writes it into the BPF Map to solve the problem of querying the attribution of inbound data packets caused by the connectionless nature of UDP.

[0173] Step S304: Attach the Netfilter local send / receive hook.

[0174] Step S305: Parse network layer and transport layer data packets.

[0175] Step S306: Determine if the configured direction matches. If yes, proceed to step S307; otherwise, allow the data packet to pass.

[0176] Step S307: Query the process ownership and determine if it is the target PID. If yes, proceed to step S308; otherwise, allow the data packet.

[0177] Step S304 mounts another part of the eBPF program to the network packet processing path (such as a Netfilter hook) to intercept and inspect data packets flowing through the kernel network protocol stack. Step S305 parses the sk_buff structure of the data packet in the kernel path, extracts the network layer and transport layer header information, and obtains key metadata such as source / destination IP, port, and protocol type. Step S306 first determines whether the processing direction of the current data packet is consistent with the direction configured in step S301. If the directions do not match, the data packet is allowed to pass directly to ignore traffic in non-control directions; if the directions match, proceed to step S307. Step S307 determines whether the process ID to which the data packet belongs is consistent with the target PID configured in the rule. If they do not match, the packet is allowed to pass directly to avoid accidentally harming other processes; if they match, proceed to the attribution confidence assessment stage.

[0178] Step S308: Calculate the attribution confidence score.

[0179] Step S309: Determine if the attribution confidence level meets the standard. If yes, proceed to step S310; otherwise, allow the data packet to pass.

[0180] Step S310: Query or create a hierarchical token bucket.

[0181] Step S308 calculates the confidence score of the current attribution relationship based on factors such as the source of the data packet (e.g., direct Socket pointer hit or local tuple inference), mapping update timeliness, and port binding accuracy, to assess the security and accuracy of the rate limiting decision. Step S309 determines whether the calculated attribution confidence score reaches a preset security threshold. If the confidence score is insufficient, the data packet is allowed to pass directly, and an anomaly may be reported to prevent service interruption due to incorrect attribution information. If the confidence score meets the threshold, it is confirmed that the data packet belongs to a controlled target and its attribution is reliable, and step S310 is executed. Step S310 uses the target PID as the base key, combined with fields such as direction and protocol, to query the corresponding hierarchical token bucket status in the BPF Map. If it does not exist, a new token bucket instance is created according to the rules.

[0182] Step S311: Replenish tokens according to the time difference and limit the bucket capacity.

[0183] Step S312: Determine if there are enough tokens.

[0184] Step S3131: If there are enough tokens, deduct the tokens according to the packet length and release the packet, and report the release event.

[0185] Step S3132: If there are slightly insufficient tokens, release the tokens and record the token debt, and report the debt release time.

[0186] Step S3133: If the tokens are slightly insufficient, discard the data packet and report the discard event.

[0187] Step S311 replenishes the token quantity according to the configured rate based on the difference between the current time and the last update time of the token bucket, while ensuring that the total number of tokens does not exceed the maximum bucket capacity determined by the rate and time scale, in order to maintain the long-term average of the rate limiting. Step S312 determines whether the number of currently available tokens is sufficient to cover the length of the current data packet. If there are enough tokens, proceed to step S3131, that is, deduct the corresponding number of tokens according to the data packet length, allow the data packet, and report the allowance event through the Ring Buffer for user-space monitoring. If there are slightly fewer tokens but not exceeding the debt threshold, proceed to step S3132, that is, allow the data packet, record the token debt (negative value), and report the debt allowance event, smoothing the rate limiting curve by allowing short-term overdraft and reducing frequent drops caused by small packet bursts. If there are severely fewer tokens or the debt threshold is exceeded, proceed to step S3133, that is, drop the data packet, use the TCP congestion control mechanism or the UDP application layer tolerance mechanism to form rate feedback, and report the drop event through the Ring Buffer, thereby achieving forced bandwidth limitation on the target process.

[0188] Figure 4 This is a schematic diagram of a process attribution learning process according to an embodiment of this application, such as... Figure 4As shown, the method includes the following steps:

[0189] Step S401: Socket operation event is triggered.

[0190] Step S402: Determine if a valid socket object exists. If yes, proceed to step S403; otherwise, end the process.

[0191] Step S403: Read the current process PID and process name.

[0192] Step S404: Read the sock pointer corresponding to the socket.

[0193] Step S405: Update the sock mapping to the process.

[0194] Step S401 is triggered by a Socket operation event, marking the start of the process attribution learning process. Step S402 determines whether a valid Socket object exists in the current context. If a valid object exists, proceed to step S403; otherwise, terminate the process directly to avoid invalid processing. Step S403 reads the process identifier and process name of the current task at the time the event was triggered, obtaining process-level identity information. Step S404 reads the kernel sock structure pointer corresponding to the Socket object, establishing the association between the network object and the kernel data structure. Step S405 associates the process information (PID and process name) obtained in step S403 with the sock pointer obtained in step S404 and updates it in the BPF Map, forming a sock-to-process mapping relationship, so that the process to which the socket belongs can be found later through the sock pointer in the data packet.

[0195] Step S406: Determine if it is a UDP receive-related path. If yes, proceed to step S4071; otherwise, proceed to step S4072.

[0196] Step S4071: Read the local IP address and local port, and then proceed to step S408.

[0197] Step S4072: Report the socket mapping event.

[0198] Step S406 determines whether the currently triggered Socket operation belongs to a UDP receive-related path. If so, step S4071 is executed to handle the UDP-specific attribution logic; otherwise, step S4072 is executed to only report the mapping event. Step S4071 reads the local IP address and local port number bound to the Socket to prepare for constructing the local network tuple, and then executes step S408. Step S4072, after the Socket mapping relationship is updated, reports the Socket mapping event to user space, notifying the user-space program process that the association with the Socket has been established.

[0199] Step S408: Determine if the local IP address is a wildcard address. If yes, proceed to step S4091; otherwise, proceed to step S4092.

[0200] Step S4091: Read the local IP address configured in user mode.

[0201] Step S4092: Use the local IP address of the socket.

[0202] Step S410: Construct the local network tuple.

[0203] Step S411: Update the local network tuple to the process mapping.

[0204] Step S412: Report the local tuple learning event.

[0205] Step S408 determines whether the read local IP address is a wildcard address. If yes, proceed to step S4091; otherwise, proceed to step S4092. Step S4091 reads the pre-configured local IP address from the BPF Map, using it as the actual local IP address of the socket to address the issue that wildcard addresses cannot uniquely identify specific network interfaces. Step S4092 directly uses the socket local IP address read in step S4071, as this address is already a specific non-wildcard address. Step S410 uses the determined local IP address, local port number, and protocol type to construct a unique local network tuple for attribution matching of connectionless protocols. Step S411 associates the constructed local network tuple with the current process information and updates it in the BPF Map, forming a mapping from local network tuples to processes, specifically for attribution lookup of inbound UDP packets. Step S412 reports a local tuple learning event to the user space, informing the user space that the UDP attribution mapping has been successfully established, completing the entire process attribution learning process.

[0206] Figure 5 This is a schematic diagram of a process attribution confidence determination process according to an embodiment of this application, as shown below. Figure 5 As shown, the method includes the following steps:

[0207] Step S501: The data packet enters the network hook.

[0208] Step S502: parse the direction, protocol, local IP and port.

[0209] Step S503: Determine if it is an inbound UDP connection. If yes, proceed to step S5041; otherwise, proceed to step S5042.

[0210] Step S5041: Query the local tuple to process mapping.

[0211] Step S5042: Query the sock-to-process mapping.

[0212] Step S501: The network packet enters the network hook, triggering the attribution confidence determination process. Step S502: Parses the packet's direction, transport layer protocol type, local IP address, and local port number to obtain the key metadata required for attribution lookup. Step S503: Determines whether the current packet is inbound traffic of the UDP protocol. If so, executes step S5041 to perform attribution lookup using the local tuple; otherwise, executes step S5042 to perform attribution lookup using the socket pointer. Step S5041 queries the BPF Map for the local network tuple composed of the local IP, port, and protocol parsed in step S502, finding the corresponding process information. This is suitable for attribution determination of connectionless UDP protocols. Step S5042 queries the BPF Map for the socket corresponding to the packet's socket, finding the mapped process information. This is suitable for connection-oriented protocols or UDP scenarios with established connections.

[0213] Step S505: Determine if a match has been found. If yes, proceed to step S5061; otherwise, proceed to step S5062.

[0214] Step S5061: Read the mapping source and update time, and then execute step S507.

[0215] Step S5062: Conservatively release the passage and record the unassigned event.

[0216] Step S507: Calculate the confidence level based on the source, timeliness, protocol, and binding method.

[0217] Step S508: Determine whether the confidence level has reached the control threshold. If yes, proceed to step S5091; otherwise, proceed to step S5092.

[0218] Step S5091: Proceed to directional gating and flow limiting determination.

[0219] Step S5092: Only perform statistics or issue an alarm and then allow passage.

[0220] Step S505 determines whether a process attribution mapping has been successfully matched. If so, proceed to step S5061 to further evaluate attribution reliability; otherwise, proceed to step S5062 to adopt a conservative strategy. Step S5061 reads the source type of the matched mapping (e.g., direct Socket pointer hit or local tuple inference) and the mapping's most recent update time to provide a basis for subsequent confidence calculation, and proceeds to step S507. Step S5062, since no definite process attribution was found, to avoid mistakenly affecting non-target traffic, the data packet is allowed to pass directly, and the unassigned event is recorded and reported to user space. Step S507 combines the reliability level of the mapping source, the timeliness factor reflected by the update time, the consistency of the protocol type, and the accuracy of port binding, and uses weighted or rule-based synthesis to obtain the final attribution confidence score. Step S508 determines whether the calculated attribution confidence score reaches the preset control threshold. If so, proceed to step S5091 to consider the attribution reliable and enter the formal rate limiting process; otherwise, proceed to step S5092 to consider the attribution uncertain. Step S5091 uses the direction gating and rate limiting determination module to perform token bucket rate control on target process data packets with high confidence. Step S5092 For data packets with insufficient confidence, only statistical counting or alarm operations are performed, and the data packets are directly allowed to pass, ensuring service continuity under uncertain attribution conditions.

[0221] In summary, upon receiving a network packet, the system first parses the direction, protocol, and local network tuple, then selects different attribution query paths based on the protocol and direction. For UDP inbound packets, it prioritizes querying the local tuple mapping; in other scenarios, it prioritizes querying the sock mapping. If no attribution is found, the packet is conservatively allowed to pass. If an attribution is found, a confidence level is calculated based on the mapping source, update time, protocol type, binding precision, and direction consistency. The calculation first determines the attribution source level, then calculates the timeliness factor, binding precision factor, and direction and protocol consistency factor, finally synthesizing high, medium, and low confidence levels. Only when the confidence level reaches the control threshold does it proceed to subsequent rate limiting; if the confidence level is insufficient, it only generates statistics or issues an alarm and allows the packet to pass.

[0222] Figure 6 This is a schematic diagram of a hierarchical token bucket rate limiting process according to an embodiment of this application, as shown below. Figure 6 As shown, the method includes the following steps:

[0223] Step S601: The target PID and direction are both matched.

[0224] Step S601 confirms that the target PID of the current data packet is consistent with the target PID in the control rule, and the direction of the data packet matches the direction configured in the rule, thus satisfying the prerequisite for entering the hierarchical token bucket current limiting judgment.

[0225] Step S602: Query or create a process bucket.

[0226] Step S603: Query or create a direction bucket.

[0227] Step S604: Query or create a protocol bucket.

[0228] Step S602 uses the target PID as the base key to query or create a first-level process bucket in the BPF Map to maintain the total bandwidth budget for that process. Step S603 adds a direction field as the key to the process bucket to query or create a second-level direction bucket to control bandwidth usage in the inbound and outbound directions respectively. Step S604 adds a protocol field as the key to the direction bucket to query or create a third-level protocol bucket to impose independent bandwidth constraints on different protocols (such as TCP and UDP).

[0229] Step S605: Replenish tokens to each bucket according to the time difference.

[0230] Step S606: Trim the upper limit of the confidence capacity of each bucket.

[0231] Step S607: Determine if the process bucket tokens are sufficient. If yes, proceed to step S608; otherwise, proceed to step S6103.

[0232] Step S605 calculates the replenishment amount according to the configured rate based on the time difference between the current time and the last update of each level of token bucket, and replenishes tokens for the process bucket, direction bucket, and protocol bucket respectively to achieve time-based rate control. Step S606 prunes the upper limit of the number of tokens replenished in each level of bucket to ensure that the number of tokens does not exceed the maximum bucket capacity determined by the configured rate and time scale, preventing tokens from accumulating indefinitely. Step S607 determines whether the available tokens in the first-level process bucket are sufficient to cover the current data packet length. If sufficient, proceed to step S608 to continue checking down to the next lower level; if insufficient, proceed to step S6103 to handle the insufficient quota at the process bucket level.

[0233] Step S608: Determine if there are enough direction bucket tokens. If yes, proceed to step S609; otherwise, proceed to step S6102.

[0234] Step S609: Determine if there are enough protocol bucket tokens. If yes, deduct tokens at each level and allow passage, and report the normal passage time; if not, proceed to step S6101.

[0235] Step S608 determines whether the available tokens in the second-level directional bucket are sufficient to cover the current data packet length. If sufficient, proceed to step S609 to continue checking the protocol bucket. If insufficient, proceed to step S6102 to handle the insufficient quota at the directional bucket level. Step S609 determines whether the available tokens in the third-level protocol bucket are sufficient to cover the current data packet length. If sufficient, deduct tokens from the process bucket, directional bucket, and protocol bucket in sequence, allow the data packet to pass, and report a normal release event to the user space.

[0236] Step S6101: Determine whether protocol bucket debt is allowed. If yes, record the protocol bucket debt, allow it, and report it. If no, discard it and report it.

[0237] Step S6102: Determine whether directional bucket debt is allowed. If yes, record the directional bucket debt, allow passage, and report it. If no, discard and report it.

[0238] Step S6103: Determine whether process bucket debt is allowed. If yes, record the process bucket debt, allow it, and report it. If no, discard it and report it.

[0239] Step S6101: When protocol bucket tokens are insufficient, determine whether protocol bucket debt is allowed. If allowed, record the debt value at the protocol level, allow the data packet, and report a debt allowance event. If not allowed, discard the data packet and report a drop event. Step S6102: When directional bucket tokens are insufficient, determine whether directional bucket debt is allowed. If allowed, record the debt value at the directional level, allow the data packet, and report a debt allowance event. If not allowed, discard the data packet and report a drop event. Step S6103: When process bucket tokens are insufficient, determine whether process bucket debt is allowed. If allowed, record the debt value at the process level, allow the data packet, and report a debt allowance event. If not allowed, discard the data packet and report a drop event. This achieves smooth and strict process-level bandwidth control through layered checks and debt mechanisms.

[0240] In summary, after matching the target PID and direction, a status key based on the PID is first constructed, which can be overlaid with process start time, network namespace, or rule number to prevent PID reuse. Then, a direction field is overlaid on the base key to form a direction bucket key, and a protocol field is overlaid on the direction bucket key to form a protocol bucket key. Process buckets, direction buckets, and protocol buckets are queried or created sequentially, and tokens are replenished to each level of bucket according to the time difference, while capacity limits are pruned. During judgment, the quota is checked in the order of process bucket, direction bucket, and protocol bucket: if all buckets have sufficient quota, tokens at each level are deducted and allowed; if any level has insufficient quota, if debt is allowed, the corresponding level of debt is recorded and allowed; otherwise, it is discarded. This process ensures that total bandwidth, direction bandwidth, and protocol bandwidth can jointly constrain the target process traffic.

[0241] Figure 7 This is a schematic diagram of a protocol-aware packet loss rate limiting process according to an embodiment of this application, as shown below. Figure 7 As shown, the method includes the following steps:

[0242] Step S701: The tiered token bucket determines that the amount is insufficient.

[0243] In step S701, during the hierarchical token bucket rate limiting determination process, it is confirmed that the length of the current data packet exceeds the available token quota, thereby triggering the protocol-aware controlled packet loss mechanism.

[0244] Step S702: Read the transport layer protocol.

[0245] Step S702 reads the transport layer protocol identifier in the header of the current network data packet to obtain protocol type information.

[0246] Step S703: Determine if the protocol is TCP. If yes, proceed to step S704; otherwise, proceed to step S705.

[0247] Step S703 determines whether the read transport layer protocol is TCP. If so, proceed to step S704 to use the congestion control characteristics of the TCP protocol to perform rate limiting feedback. Otherwise, proceed to step S705 to further determine whether it is UDP.

[0248] Step S704: Discard excess TCO packets, trigger TCP missing acknowledgment or timeout, sender performs retransmission and congestion window adjustment, and send rate decreases and approaches the configured limit.

[0249] Step S704 discards excess TCP packets. This packet loss action will cause the receiver to send missing acknowledgments or the sender to detect a timeout, thereby triggering the TCP sender to execute fast retransmission, timeout retransmission and congestion window adjustment mechanisms, so that the sender automatically reduces the sending rate, and finally makes the actual throughput approach the configured rate limit.

[0250] Step S705: Determine if the protocol is UDP. If yes, proceed to step S706; otherwise, allow, count, or discard according to the default policy.

[0251] Step S705 determines whether the transport layer protocol is UDP. If so, step S706 is executed to process the packet loss semantics of the UDP protocol. Otherwise, the default policy is used to perform the allow, count, or discard operations.

[0252] Step S706: Discard excess UDP packets and determine whether the service requires reliability. If so, the application layer retransmits according to its own mechanism; otherwise, the real-time service tolerates the loss of non-critical data.

[0253] Step S706 discards excess UDP packets. Since the UDP protocol itself does not guarantee reliable delivery, the system further determines whether the relevant service requires reliability assurance. If reliability is required, the application layer will retransmit the data according to its own sequence number, acknowledgment, or retransmission mechanism. If reliability is not required, the real-time service will tolerate the absence of non-critical data packets, thereby achieving rate control that conforms to the protocol semantics without modifying the application logic.

[0254] In summary, when the hierarchical token bucket determines that the target process's quota is insufficient, it further reads the transport layer protocol. For TCP, discarding excess packets triggers missing acknowledgments, fast retransmission, timeout retransmission, and congestion window adjustment in the TCP protocol stack, causing the sender to automatically reduce its sending rate. For UDP, discarding excess packets aligns with its protocol semantics of not guaranteeing reliable delivery; real-time services can tolerate the loss of non-critical data, while reliable services can have the application layer automatically retransmit the data. This process demonstrates that controlled packet loss does not disrupt business logic but rather utilizes existing mechanisms in different protocols to create rate feedback or business adaptation.

[0255] Figure 8 This is a schematic diagram of a state aging and recycling process according to an embodiment of this application, as shown below. Figure 8 As shown, the method includes the following steps:

[0256] Step S801: Data packet hit or periodic check triggered.

[0257] Step S802: Read the most recent hit time of the mapping and bucket.

[0258] Step S803: Determine whether the state exceeds the aging threshold. If yes, proceed to step S804; otherwise, retain the state.

[0259] Step S801 is triggered by a data packet hitting a specific state or a periodic check task, initiating the state aging and reclamation process to manage kernel resources. Step S802 reads the most recent hit time or update time of the relevant process mapping, local network tuple mapping, and token bucket state as the basis for evaluating state activity. Step S803 determines whether the most recent hit time of the current state has exceeded a preset aging threshold. If it has, step S804 is executed to further evaluate whether the reclamation conditions are met. If it has not exceeded the threshold, the state is directly retained to maintain its validity.

[0260] Step S804: Determine if there is capacity pressure or if the process has exited. If yes, proceed to step S805; otherwise, lower the status priority.

[0261] Step S805: Delete process mapping, delete network tuple mapping, delete token bucket state, and report state recycling event.

[0262] Step S804, after a state exceeds the aging threshold, further determines whether the system is under memory pressure or whether the corresponding process has completely exited. If so, step S805 immediately performs a cleanup operation; otherwise, it only lowers the priority of the state in the system, waiting for subsequent stricter checks or resource stress before further processing. Step S805 performs specific resource reclamation operations, sequentially deleting the corresponding process mappings, network tuple mappings, and token bucket states, releasing kernel memory usage, and reporting state reclamation events to user space to record the cleanup behavior, thereby ensuring the cleanliness and accurate attribution of kernel states during long-term operation.

[0263] In summary, the system reads the most recent hit time of the mapping and token bucket during packet hits or periodic checks. If the state has not exceeded the aging threshold, it is retained; if it exceeds the threshold, further investigation is conducted to determine if there is capacity pressure or if the process has exited. When the recycling conditions are met, the system sequentially deletes the process mapping, network tuple mapping, and token bucket state, and reports the state recycling event; if the recycling conditions are not yet met, the state priority is lowered, awaiting subsequent checks.

[0264] Figure 9 This is a schematic diagram illustrating the interaction timing between user mode and kernel mode according to an embodiment of this application, as shown below. Figure 9 As shown, the interactions between the objects specifically include the following:

[0265] User management: Input PID, speed, direction, and time scale.

[0266] The management user, as the main operator of the system, provides core control policy parameters to the system through command line or configuration interface. These parameters include specifying the target process identifier that needs rate limiting, setting the maximum allowed bandwidth (rate), clarifying whether the restriction applies to inbound or outbound traffic (direction), and setting the maximum capacity of the token bucket to control the tolerance for short-term bursts of traffic (time scale). These parameters constitute the foundational rules for all subsequent automated processing.

[0267] User-mode control program: Loads and mounts Socket operation eBPF program, loads and mounts Netfilter eBPF program, writes process rate limiting rules and local IP, polls events, outputs flow control and observation results.

[0268] The user-space control program acts as a management intermediary and monitoring center. First, it translates user-configured parameters into kernel-executable instructions, loading and mounting the Socket eBPF program (responsible for process association) and the Netfilter eBPF program (responsible for flow control) into the Linux kernel. Next, it writes rate-limiting rules and the local IP address to the shared memory region and continuously monitors kernel-reported status changes, ultimately transforming the complex kernel status into administrator-readable statistical reports and alarm information.

[0269] BPF Map: Stores sock-to-process information mappings, stores UDP local tuple-to-process information mappings, query rules, and process ownership.

[0270] The BPF Map acts as a shared database in kernel space, persistently storing critical state data. It primarily maintains two types of mappings: one binding kernel socket object pointers to process information for identifying connected or established processes; the other binding UDP protocol's local IP address, port, and protocol number to process information for determining the attribution of connectionless UDP traffic. Simultaneously, the BPF Map is the sole data source for eBPF programs to read rate-limiting rules and query attribution results.

[0271] Socket operation hooks: save socket to process information mapping, save UDP local tuple to process information mapping.

[0272] Socket operation hooks are trigger points in the kernel that listen for socket lifecycle events (such as creation, connection, sending, and receiving). When a network communication-related socket operation occurs, the hook is activated. Its core task is to capture the current process context (PID, process name) and the socket object pointer, establishing and updating the socket pointer-process mapping. For the UDP protocol, the hook also extracts local IP and port information, establishing a local network tuple-process mapping, thus providing a basis for subsequent packet attribution.

[0273] Netfilter hooks: query rules and process ownership, execute direction gates and target gates, calculate ownership confidence, update hierarchical token buckets and determine limits, record token debt or perform aging-out reclamation when necessary, and write release or discard events.

[0274] Netfilter hooks are core filtering points located on the local transmit / receive path of the network protocol stack, responsible for executing specific flow control logic. When a packet passes through, it first queries the BPF Map for rules and target process attribution, performing initial filtering by matching direction and target. Then, it calculates the attribution confidence to ensure control security. Next, it accesses the hierarchical token bucket state, replenishes tokens based on the time difference, and determines whether the current packet is within its limit. If the limit is insufficient, it decides whether to record a debt or drop the packet based on the policy. Finally, it writes the control result (allow or drop) and statistical information to the event buffer.

[0275] The Ring Buffer (a circular buffer used by eBPF programs to asynchronously report events to user space) allows or discards events.

[0276] The ring buffer serves as a high-efficiency communication channel between kernel mode and user mode. After a Netfilter hook completes its flow control decision, it asynchronously writes critical events (such as packets being allowed, dropped, rule hits, and exceptions) into this ring buffer. These events include structured data, allowing user-mode control programs to obtain detailed logs and statistics on flow control in real time without polling the kernel, thus enabling system observability and auditing.

[0277] In summary, the embodiments of this application have the following technical effects.

[0278] First, by establishing a kernel-mode mapping from socket to process information in the socket operation path and looking up this mapping in the Netfilter packet path, the process context and packet context can be associated, thus elevating the rate-limiting object from the interface, IP, or port to the process dimension and reducing the probability of mistakenly limiting the traffic of other processes.

[0279] Second, by additionally maintaining the mapping of local IP, port, and protocol to process information for UDP inbound traffic, the accuracy of process attribution in connectionless communication scenarios can be improved, reducing the potential for missing process attribution due to relying solely on socket pointers.

[0280] Third, by directly performing direction gating, destination gating, and token bucket determination in the Netfilter local receive and local send paths, the decision to allow or discard packets can be made when the packets pass through the kernel path, reducing the latency caused by user-space polling, user-space statistics, and post-control.

[0281] Fourth, by writing rate, direction, and time scales into the BPF Map, it supports runtime configuration of different target processes, control directions, and burst tolerance windows. The time scale and rate together limit the maximum bucket capacity, allowing strict rate limiting and long-term average rate limiting to adapt to different business scenarios.

[0282] Fifth, by using the PID as the primary token bucket key, multiple TCP connections, UDP ports, and short connection traffic of the same target process are merged into the same bandwidth budget, reducing the possibility of the target process bypassing the rate limiting policy through connection splitting, port changing, or temporary port reuse.

[0283] Sixth, through the hierarchical rate limiting structure of process bucket, direction bucket and protocol bucket, the bandwidth usage of inbound direction, outbound direction and different protocols can be further constrained in addition to the total bandwidth constraint, so as to avoid a single direction or a single protocol from filling the entire budget of the target process.

[0284] Seventh, through the token debt mechanism and cold start protection mechanism, the frequent dropping of large packets in boundary cases can be reduced, making the rate limiting behavior smoother, while still maintaining long-term average rate constraints through the debt threshold.

[0285] Eighth, by using the attribution confidence determination and anomaly protection modules, a conservative release strategy is adopted when parsing fails, mapping is missing, confidence is insufficient, or rules are unavailable. This ensures that the discard action only occurs when the target is clear and the quota is insufficient, thereby improving the security boundary of the kernel-mode control logic.

[0286] Ninth, through protocol-aware packet loss control, excess packet loss can be transformed into TCP sender congestion window adjustment and retransmission behavior, thereby automatically reducing the actual TCP sending rate; for UDP, taking advantage of its protocol characteristic of not guaranteeing reliable delivery, the dropping is limited to excess data packets, which are tolerated by real-time services or retransmitted by application-layer reliable mechanisms, thereby achieving rate limiting without requiring the application to modify its logic.

[0287] Tenth, by cleaning up long-term unhappened process mappings, network tuple mappings, and token bucket states through the state aging and recycling module, the kernel state occupancy in long-running scenarios can be reduced, and the risk of incorrect attribution caused by stale mappings can be reduced.

[0288] Eleventh, by outputting process mapping, network tuple parsing, pass-through, debt pass-through, drop-through, and anomaly protection events through Ring Buffer, it provides observability while performing rate limiting, making it easier for administrators to confirm rule hits, analyze packet attribution, and locate abnormal configurations.

[0289] Twelfth, through eBPF validator constraints and BPF Map state storage, the deployment risk of kernel extensions can be reduced without modifying the kernel body or loading traditional kernel modules, and it is easy to dynamically enable or uninstall on systems that support eBPF Netfilter.

[0290] Figure 10 This is a structural diagram of a network traffic control device according to an embodiment of this application, such as... Figure 10 As shown, the device includes:

[0291] The acquisition module 1001 is used to acquire rate limiting rules for network traffic; wherein, the rate limiting rules include: rate threshold, target process identifier, control direction and burst tolerance parameter; the burst tolerance parameter is used to characterize the number of tokens that a process is allowed to accumulate.

[0292] Module 1002 is used to establish a first mapping relationship between a network connection object identifier and a target process identifier, and to establish a second mapping relationship between a local network tuple and the target process identifier.

[0293] The extraction module 1003 is used to extract the data packet direction, transport layer protocol type, and the first local network tuple and the first network connection object identifier corresponding to the network data packet from the network data packet.

[0294] The query module 1004 is used to query the first target process identifier corresponding to the first network connection object identifier based on the first mapping relationship when the transport layer protocol type is Transmission Control Protocol; and to query the first target process identifier corresponding to the first local network tuple based on the second mapping relationship when the transport layer protocol type is User Datagram Protocol.

[0295] The execution module 1005 is used to determine whether the direction of the data packet matches the control direction and whether the first target process identifier matches the target process identifier; if they all match, the number of tokens in the token bucket state storage structure is limited to the maximum bucket capacity determined by the rate threshold and the burst tolerance parameter.

[0296] The determination module 1006 is used to determine the processing method for the network data packet based on the relationship between the updated number of tokens and the data packet length of the network data packet.

[0297] It should be noted that the above Figure 10 The modules in can be program modules (e.g., a set of program instructions that implements a specific function) or hardware modules. For the latter, they can be represented in the following forms, but are not limited to these: each of the above modules is represented by a processor, or the functions of each of the above modules are implemented by a processor.

[0298] It should be noted that, Figure 10 Preferred embodiments of the shown examples can be found in [reference needed]. Figure 1 The relevant descriptions of the embodiments shown will not be repeated here.

[0299] Figure 11 A hardware block diagram of a computer terminal for implementing a network flow control method is shown. Figure 11 As shown, the computer terminal 110 may include a processor 1102, a memory 1104 for storing data, and a transmission module 1106 for communication functions. The processor 1102 may include one or more processors. For ease of explanation, Figure 11The diagram illustrates multiple processors, including a first processor 1102a, a second processor 1102b, ..., an nth processor 1102n. The processor 1102 may be a processing device including, but not limited to, a microcontroller unit (MCU) or a field programmable gate array (FPGA).

[0300] In addition, a computer terminal may also include: a display, an input / output interface (I / O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 11 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, the computer terminal 110 may also include... Figure 11 The more or fewer components shown, or having the same Figure 11 The different configurations shown.

[0301] It should be noted that the aforementioned one or more processors 1102 and / or other data processing circuits may be referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 110. As involved in the embodiments of this application, the data processing circuits serve as processor control (e.g., selection of a variable resistor termination path connected to an interface).

[0302] The memory 1104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the network traffic control method in this embodiment. The processor 1102 executes various functional applications and data processing by running the software programs and modules stored in the memory 1104, thereby implementing the aforementioned network traffic control method. The memory 1104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 1104 may further include memory remotely located relative to the processor 1102, and these remote memories can be connected to the computer terminal 110 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0303] The transmission module 1106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 110. In one example, the transmission module 1106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission module 1106 may be a Radio Frequency (RF) module, used for data interaction with external networks or devices via wired and / or wireless network connections.

[0304] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows the user to interact with the user interface of the computer terminal 110. In addition, the computer terminal 110 can also connect to a cursor control device and a keyboard via an input / output interface. The cursor control device (e.g., a mouse, trackball, or touchpad) is primarily used to transmit directional information and command selections to the terminal and control the movement of the cursor on the display; the keyboard is primarily used to receive letters, numbers, and other control commands input by the user, thereby enabling interaction between the user and the computer terminal 110.

[0305] It should be noted here that, in some optional embodiments, the above... Figure 11 The computer terminal shown may include hardware components (including circuitry), software components (including computer code stored on a computer-readable medium), or a combination of both hardware and software components. It should be noted that... Figure 11 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computer terminal.

[0306] It should be noted that, Figure 11 The computer terminal shown is used to execute Figure 1 The network traffic control method shown above applies to this electronic device as well, and will not be repeated here.

[0307] This application also provides a non-volatile storage medium, which includes a stored program, wherein the program, when running, controls the device where the storage medium is located to execute the above-mentioned network traffic control method.

[0308] A non-volatile storage medium performs the following functions: It acquires rate-limiting rules for network traffic; wherein the rate-limiting rules include: a rate threshold, a target process identifier, a control direction, and a burst tolerance parameter; the burst tolerance parameter characterizes the number of tokens a process is allowed to accumulate; it establishes a first mapping relationship between network connection object identifiers and target process identifiers, and establishes a second mapping relationship between local network tuples and target process identifiers; it extracts the packet direction, transport layer protocol type, and the first local network tuple and first network connection object identifier corresponding to the network packet from the network packet; if the transport layer protocol type is Transmission Control Protocol, it queries the first target process identifier corresponding to the first network connection object identifier based on the first mapping relationship; if the transport layer protocol type is User Datagram Protocol, it queries the first target process identifier corresponding to the first local network tuple based on the second mapping relationship; it determines whether the packet direction matches the control direction, and whether the first target process identifier matches the target process identifier; if both match, it limits the number of tokens in the token bucket state storage structure to within the maximum bucket capacity determined by the rate threshold and the burst tolerance parameter; and it determines the processing method for the network packet based on the relationship between the updated number of tokens and the packet length of the network packet.

[0309] This application also provides an electronic device, including a memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the program executes the above-described network traffic control method during runtime.

[0310] The processor runs a program that performs the following functions: acquiring rate-limiting rules for network traffic; wherein the rate-limiting rules include: a rate threshold, a target process identifier, a control direction, and a burst tolerance parameter; the burst tolerance parameter characterizes the number of tokens a process is allowed to accumulate; establishing a first mapping relationship between network connection object identifiers and target process identifiers, and establishing a second mapping relationship between local network tuples and target process identifiers; extracting the packet direction, transport layer protocol type, and the first local network tuple and first network connection object identifier corresponding to the network packet from the network packet; if the transport layer protocol type is Transmission Control Protocol, querying the first target process identifier corresponding to the first network connection object identifier based on the first mapping relationship; if the transport layer protocol type is User Datagram Protocol, querying the first target process identifier corresponding to the first local network tuple based on the second mapping relationship; determining whether the packet direction matches the control direction, and whether the first target process identifier matches the target process identifier; if both match, limiting the number of tokens in the token bucket state storage structure to within the maximum bucket capacity determined by the rate threshold and the burst tolerance parameter; and determining the processing method for the network packet based on the relationship between the updated number of tokens and the packet length of the network packet.

[0311] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0312] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0313] In the above embodiments of this application, the information collected is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with relevant laws, regulations and standards, take necessary protective measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0314] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0315] 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 units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0316] Furthermore, the functional units in the various embodiments of this application 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.

[0317] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0318] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A network traffic control method, characterized in that, include: Obtain rate limiting rules for network traffic; wherein, the rate limiting rules include: rate threshold, target process identifier, control direction, and burst tolerance parameter; the burst tolerance parameter is used to characterize the number of tokens that a process is allowed to accumulate; Establish a first mapping relationship between network connection object identifiers and target process identifiers, and establish a second mapping relationship between local network tuples and the target process identifiers; Extract the packet direction, transport layer protocol type, and the first local network tuple and first network connection object identifier corresponding to the network packet from the network packet; When the transport layer protocol type is Transmission Control Protocol, the first target process identifier corresponding to the first network connection object identifier is queried based on the first mapping relationship; when the transport layer protocol type is User Datagram Protocol, the first target process identifier corresponding to the first local network tuple is queried based on the second mapping relationship. Determine whether the data packet direction matches the control direction and whether the first target process identifier matches the target process identifier; if they all match, limit the number of tokens in the token bucket state storage structure to within the maximum bucket capacity determined by the rate threshold and the burst tolerance parameter. The processing method for the network data packet is determined based on the relationship between the updated number of tokens and the length of the network data packet.

2. The method according to claim 1, characterized in that, Determining whether the data packet direction matches the control direction and whether the first target process identifier matches the target process identifier includes: Determine a target mapping relationship for obtaining the first target process identifier; wherein the target mapping relationship is either the first mapping relationship or the second mapping relationship; The type of the target mapping relationship is determined as the mapping source; Obtain the process mapping record corresponding to the first target process identifier in the target mapping relationship; A timeliness factor is determined based on the time difference between the target time when processing the network data packet and the first timestamp; wherein, the first timestamp is the timestamp of the most recent update or hit recorded in the process mapping record that is closest to the target time; Based on the binding information of local network addresses and local ports recorded in the process mapping record, determine the binding precision factor; Based on the consistency relationship between the learning direction and protocol type recorded in the process mapping record and the data packet direction and transport layer protocol type in the network data packet, a direction protocol consistency factor is determined. The attribution confidence of the first target process identifier is determined based on the mapping source, the timeliness factor, the binding accuracy factor, and the direction protocol consistency factor, wherein the attribution confidence is used to characterize the degree of consistency between the first target process identifier and the actual process to which the network data packet belongs; If the attribution confidence is greater than or equal to the first preset control threshold, it is determined whether the data packet direction matches the control direction and whether the first target process identifier matches the target process identifier.

3. The method according to claim 1, characterized in that, Limiting the number of tokens in the token bucket state storage structure to within the maximum bucket capacity determined jointly by the rate threshold and the burst tolerance parameter includes: Query or create a bucket state associated with the hierarchical status key corresponding to the network data packet; wherein, the bucket state includes the status information of the token bucket; the hierarchical status key is used to characterize the hierarchical position of the token bucket; If the bucket state is being created for the first time, the number of currently available tokens in the bucket state is initialized according to a preset cold start strategy; wherein, the cold start strategy is configured to initialize the number of currently available tokens to a preset proportion of the maximum bucket capacity; The maximum bucket capacity is determined based on the rate threshold and the burst tolerance parameter; Obtain the last update time in the bucket state, and calculate the number of tokens to be replenished based on the time difference between the target time when processing the network data packet and the last update time; The number of currently available tokens in the bucket state is increased by the number of tokens to be replenished, and the increased number of currently available tokens is limited to the maximum bucket capacity. The limited number of currently available tokens is then used as the updated number of tokens.

4. The method according to claim 3, characterized in that, The method further includes: When calculating the number of tokens to be replenished, if the time difference is greater than the preset time limit, the time difference is corrected to the preset time limit. When determining the maximum tank capacity, if the maximum tank capacity determined according to the rate threshold and the burst tolerance parameter is greater than the preset maximum capacity, the maximum tank capacity is set to the preset maximum capacity. If the drop rate of the target process within a preset time window is less than a preset threshold, the burst tolerance parameter is increased. If the proportion of the target process being dropped within a preset time window is greater than a preset threshold, the burst tolerance parameter is reduced.

5. The method according to claim 3, characterized in that, Based on the relationship between the updated number of tokens and the length of the network data packet, the processing method for the network data packet is determined, including: A basic state key is generated based on the target process identifier; wherein, the basic state key is used to characterize the identifier of the target process; Based on the basic state key, a direction field is superimposed to form a second-level direction state key, or a protocol field is superimposed on the second-level direction state key to form a third-level protocol state key, so as to construct a hierarchical token bucket state structure; wherein, the token bucket corresponding to the basic state key is used to represent the total bandwidth budget of the process, the token bucket corresponding to the direction state key is used to represent the bandwidth budget in a specified direction, and the token bucket corresponding to the protocol state key is used to represent the bandwidth budget on a specified protocol. Based on the characteristics of the network data packet, determine the hierarchical status key corresponding to the network data packet, and obtain the updated token quantity in the bucket state associated with the hierarchical status key; wherein, the hierarchical status key is one of the basic status key, the second-level directional status key, or the third-level protocol status key; The token limits of each enabled level are checked in hierarchical order. If the updated token count of all enabled levels is greater than or equal to the length of the network data packet, the tokens corresponding to each level are deducted and the network data packet is allowed to pass. The enabled levels include: the level corresponding to the basic status key, the level corresponding to the second-level directional status key, and the level corresponding to the third-level protocol status key, and the combination of levels enabled according to a preset policy. If the updated number of tokens at any level is less than the length of the data packet, the network data packet is subjected to an overdraft-allowing operation, a statistical alarm, or a discard operation. The overdraft-allowing operation includes: allowing the network data packet to pass and recording the number of available tokens as a negative value or recording the overdraft limit, with subsequent replenished tokens prioritizing repayment of the overdraft limit. The statistical alarm includes: collecting abnormal event information of the network data packet and sending an alarm event to the user space, without performing a discard operation.

6. The method according to claim 5, characterized in that, Performing an overdraft-allowing operation on the network data packets includes: Calculate the difference between the length of the network data packet and the updated number of tokens to obtain the number of excess bytes in a single transaction; Determine whether the number of bytes exceeding the limit in a single transaction is less than or equal to a preset single overdraft threshold; If the number of bytes exceeding the limit in a single transaction is less than or equal to the single overdraft threshold, it is determined to perform an overdraft allowance operation and update the bucket state associated with the hierarchical status key. The overdraft limit is obtained by subtracting the data packet length from the current available tokens in the bucket state, and the overdraft limit is recorded in the bucket state; wherein, the tokens replenished in subsequent cycles are used first to offset the overdraft limit.

7. The method according to claim 6, characterized in that, Performing a dropping operation on the network data packets includes: Determine if any of the following discard conditions are met: The cumulative overdraft limit in the hierarchical bucket state corresponding to the network data packet exceeds the preset cumulative overdraft threshold, the number of bytes exceeding the single overdraft exceeds the preset single overdraft threshold, the overdraft allowance function is not enabled, and the data packet length of the network data packet is greater than the updated token quantity. If any one of the discard conditions is met, the discard operation is performed; When performing a drop operation, the transport layer protocol type of the network data packet is obtained, and a corresponding packet loss statistics event is sent to the user space according to the transport layer protocol type; wherein, if the transport layer protocol type is Transmission Control Protocol, a packet loss statistics event including the Transmission Control Protocol identifier is sent to the user space; if the transport layer protocol type is User Datagram Protocol, a packet loss statistics event including the User Datagram Protocol identifier is sent to the user space.

8. The method according to claim 1, characterized in that, After querying the first target process identifier corresponding to the first network connection object identifier, the method further includes: Perform a state aging check on the process mapping or network tuple mapping; wherein the state aging check includes: Obtain the most recent hit time or most recent update time of the process map or network tuple map; If the difference between the most recent hit time or the most recent update time and the target time when processing the network data packet exceeds a first preset aging threshold, the corresponding mapping relationship is deleted. After limiting the number of tokens in the token bucket state storage structure to within the maximum bucket capacity determined jointly by the rate threshold and the burst tolerance parameter, the method further includes: Obtain the most recent hit time or most recent update time from the token bucket status; If the difference between the most recent hit time or the most recent update time and the target time when processing the network data packet exceeds the second preset aging threshold, the corresponding token bucket state is deleted.

9. The method according to claim 1, characterized in that, Before determining whether the data packet direction matches the control direction and whether the first target process identifier matches the target process identifier, the method further includes: Determine if any of the following abnormal conditions exist: network packet parsing failure, the query result of the first target process identifier is empty, the query result of the rate limiting rule is empty, or the attribution confidence corresponding to the first target process identifier is less than the preset control threshold. If any of the above-mentioned abnormal situations exist, the network data packets are allowed to pass, and an abnormal diagnostic event is sent to the user space; wherein, the abnormal diagnostic event includes at least one of the following: network packet parsing failure event, process mapping missing event, rule missing event, insufficient confidence event, and abnormal release statistics event; the process mapping missing event is used to indicate that the first target process identifier was not found; the rule missing event is used to indicate that the corresponding rate limiting rule was not found; the insufficient confidence event is used to indicate that the attribution confidence corresponding to the first target process identifier is less than the preset control threshold; the abnormal release statistics event is used to indicate the network data packet information that was allowed to pass due to the above-mentioned abnormal situation.

10. The method according to claim 1, characterized in that, After obtaining the rate-limiting rules for network traffic, the method further includes: Load a dynamically executable kernel-mode program, attach the first subroutine of the kernel-mode program to the process and network connection association path, attach the second subroutine of the kernel-mode program to the network packet processing path, and simultaneously write the rate limiting rule into the first shared memory structure; wherein, the first subroutine and the second subroutine are different subroutines; The following steps are executed through the first subroutine: Establish a first mapping relationship between network connection object identifiers and target process identifiers, and establish a second mapping relationship between local network tuples and target process identifiers; write the first mapping relationship into a second shared storage structure, and write the second mapping relationship into a third shared storage structure; The following steps are executed through the second subroutine: Extract the packet direction, transport layer protocol type, and the first local network tuple and first network connection object identifier corresponding to the network packet from the network packet; When the transport layer protocol type is User Datagram Protocol, the first target process identifier corresponding to the first local network tuple is queried based on the second mapping relationship stored in the third shared storage structure; when the transport layer protocol type is Transmission Control Protocol, the first target process identifier corresponding to the first network connection object identifier is queried based on the first mapping relationship stored in the second shared storage structure. Read the rate limiting rule from the first shared storage structure and determine whether the data packet direction matches the control direction and whether the first target process identifier matches the target process identifier; if they all match, limit the number of tokens in the token bucket state storage structure to within the maximum bucket capacity determined by the rate threshold and the burst tolerance parameter. The processing method for the network data packet is determined based on the relationship between the updated number of tokens and the length of the network data packet.

11. A network traffic control device, characterized in that, include: The acquisition module is used to acquire rate limiting rules for network traffic; wherein, the rate limiting rules include: rate threshold, target process identifier, control direction, and burst tolerance parameter; the burst tolerance parameter is used to characterize the number of tokens that a process is allowed to accumulate; A module is established to establish a first mapping relationship between a network connection object identifier and a target process identifier, and to establish a second mapping relationship between a local network tuple and the target process identifier; The extraction module is used to extract the data packet direction, transport layer protocol type, and the first local network tuple and the first network connection object identifier corresponding to the network data packet from the network data packet; The query module is configured to, when the transport layer protocol type is Transmission Control Protocol, query the first target process identifier corresponding to the first network connection object identifier based on the first mapping relationship; and when the transport layer protocol type is User Datagram Protocol, query the first target process identifier corresponding to the first local network tuple based on the second mapping relationship. The execution module is used to determine whether the direction of the data packet matches the control direction and whether the first target process identifier matches the target process identifier; if they all match, the number of tokens in the token bucket state storage structure is limited to the maximum bucket capacity determined by the rate threshold and the burst tolerance parameter. The determination module is used to determine the processing method for the network data packet based on the relationship between the updated number of tokens and the data packet length of the network data packet.

12. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored program, wherein, when the program is executed, it controls the device containing the non-volatile storage medium to perform the network traffic control method according to any one of claims 1 to 10.

13. An electronic device, characterized in that, include: A memory and a processor, the processor being configured to run a program stored in the memory, wherein the program, when executed, performs the network traffic control method according to any one of claims 1 to 10.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the network traffic control method according to any one of claims 1 to 10.

Images