A network traffic governance method, device and equipment

Abstract

This application discloses a network traffic management method, apparatus, and device. The method includes: acquiring a traffic management configuration instruction input by a user; performing management operations on network traffic based on the traffic management configuration instruction; wherein the management operations include one or more of the following: network traffic classification; network traffic bandwidth guarantee; network traffic bandwidth sharing; and network traffic bandwidth rate limiting.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a method, apparatus and device for network traffic management. Background Technology

[0002] With the development of Extended Berkeley Packet Filter (eBPF) technology, capturing, counting, and rate limiting traffic in the kernel data path using eBPF has become a key research area. Common approaches include attaching fast data path hooks (eXpress Data Path Hook, XDPHook) or traffic control ingress / egress hooks (TC Ingress / Egress Hook) to the eBPF program, recording traffic status through hash tables, and rate limiting specific traffic flows. However, these methods are mostly focused on rate limiting of single flows or simple restrictions on specific Quality of Service (QoS) categories, resulting in relatively limited application scope and limitations such as insufficient flexibility, limited granularity, and low resource utilization. Summary of the Invention

[0003] To address the aforementioned technical problems, embodiments of this application provide a network traffic management method, apparatus, and device.

[0004] The network traffic management method provided in this application embodiment is applied to a kernel-mode module, including: Obtain user-inputted traffic management configuration commands; The network traffic is managed based on the traffic management configuration instructions; wherein the management operations include one or more of the following: network traffic classification; network traffic bandwidth guarantee; network traffic bandwidth sharing; and network traffic bandwidth rate limiting.

[0005] The network traffic management device provided in this application embodiment is applied to a kernel-mode module and includes: The acquisition unit is used to acquire traffic management configuration commands input by the user; The processing unit is configured to perform governance operations on network traffic based on the traffic governance configuration instructions; wherein the governance operations include one or more of the following: network traffic classification; network traffic bandwidth guarantee; network traffic bandwidth sharing; and network traffic bandwidth rate limiting.

[0006] The processing device provided in this application includes a processor and a memory. The memory is used to store computer programs, and the processor is used to call and run the computer programs stored in the memory to execute any of the above-described network traffic management methods.

[0007] The computer-readable storage medium provided in this application embodiment is used to store a computer program that causes a computer to execute any of the above-described network traffic management methods.

[0008] The computer program product provided in this application includes computer program instructions that cause a computer to execute any of the above-described network traffic management methods.

[0009] In the technical solution of this application embodiment, the kernel-mode module obtains the traffic governance configuration command input by the user; and performs governance operations on network traffic based on the traffic governance configuration command; wherein, the governance operations include one or more of the following: network traffic classification; network traffic bandwidth guarantee; network traffic bandwidth sharing; and network traffic bandwidth rate limiting. In this way, not only can network traffic classification be implemented in the kernel data path, but also bandwidth guarantee, bandwidth sharing, and bandwidth rate limiting for different types of traffic can be achieved, thereby avoiding the problems of functional fragmentation and incompatibility in traditional solutions. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating a network traffic management method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the architecture of a traffic governance system based on eBPF provided in an embodiment of this application; Figure 3 This is a flowchart illustrating the average bandwidth calculation logic in the traffic shaping module provided in this application embodiment; Figure 4 This is a flowchart illustrating the bandwidth calculation algorithm provided in an embodiment of this application; Figure 5 This is a flowchart illustrating the token filling logic in the traffic shaping module provided in this application embodiment; Figure 6 This is a flowchart illustrating the security token calculation algorithm provided in an embodiment of this application; Figure 7 This is a flowchart illustrating the token consumption logic in the traffic shaping module provided in this application embodiment; Figure 8 This is a flowchart illustrating the packet loss calculation algorithm provided in the embodiments of this application; Figure 9 This is a schematic diagram of the structure of a network traffic management device provided in an embodiment of this application; Figure 10 This is a schematic diagram of the processing device provided in the embodiments of this application. Detailed Implementation

[0011] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0012] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and they all fall within the protection scope of the embodiments of this application.

[0013] Network traffic management is mainly achieved through the following technical means: (1) Traditional kernel flow control method The Linux kernel's TC framework employs queue rules (qdisc), classifiers, and actions to classify and schedule traffic. Common queue rules include Hierarchical Token Bucket (HTB), Class Based Queuing (CBQ), and Token Bucket Filter (TBF), enabling rate limiting and priority scheduling for different traffic categories. In such schemes, traffic classification typically relies on 5-tuples (source IP, destination IP, source port, destination port, protocol) and Virtual Local Area Network (VLAN) tags.

[0014] (2) Centralized control method based on Software Defined Networking (SDN) In some data center environments, flow table rules are centrally distributed by a controller using protocols such as OpenFlow to classify and rate-limit traffic on switches or virtual switches (such as OVS). This approach enables unified management and flexible policy distribution across devices.

[0015] With the development of eBPF technology, capturing, counting, and rate limiting traffic in the kernel data path using eBPF has become a key research area. Common methods include attaching XDP hooks or TC ingress / egress hooks to eBPF programs, recording traffic status through hash tables, and rate limiting specific traffic flows. However, existing practices largely focus on rate limiting of single flows or simple rate limiting for specific QoS categories, resulting in relatively limited application scope and specific limitations: (1) Insufficient flexibility While kernel-based TC mechanisms such as HTB / CBQ offer rich functionality, they are complex to configure and suffer from significant performance degradation in high-concurrency or large-scale classification scenarios. SDN / OpenFlow relies on a centralized controller, has poor real-time performance, and requires additional network equipment support.

[0016] (2) Particle size priority Most eBPF-based solutions only implement rate limiting for a single type of traffic, lacking more complex governance capabilities such as bandwidth guarantee and bandwidth sharing for multiple traffic types. Traffic classification methods are limited, mostly focusing on five-tuples, and lacking more flexible classification support for VLANs, application protocol characteristics, and other factors.

[0017] (3) Low resource utilization rate In traditional mechanisms, rate limiting and bandwidth protection are often implemented independently, which can easily lead to insufficient utilization of bandwidth resources. For example, when protected bandwidth is not in use, it cannot be flexibly shared by other traffic. Some solutions cannot simultaneously achieve bandwidth rate limiting, bandwidth protection, and bandwidth sharing, making it difficult to balance fairness and quality of service under high load conditions.

[0018] In summary, the solution proposed in this application aims to solve the following technical problems: (1) How to implement high-performance and flexible traffic classification in the kernel data path, and support multi-dimensional classification based on five-tuples, VLANs and other features.

[0019] (2) How to simultaneously achieve bandwidth limiting, bandwidth guarantee and bandwidth sharing for different types of traffic, avoiding the problems of functional fragmentation and incompatibility in traditional solutions.

[0020] (2) How to improve the utilization rate of bandwidth resources, while ensuring the minimum bandwidth guarantee for critical traffic, so that unused guaranteed bandwidth can be shared by other traffic, taking into account both fairness and efficiency.

[0021] To address the aforementioned technical challenges, this application proposes a network traffic governance method. First, it employs multiple classification methods, such as five-tuples, VLANs, and Differentiated Services Code Points (DSCPs), to independently calculate bandwidth and tokens for each traffic category, enabling refined traffic governance. Next, by calculating the average bandwidth of each traffic category in real-time and generating committed bandwidth, it provides rigid bandwidth guarantees for critical traffic under varying load conditions. Second, while ensuring critical traffic, unused bandwidth is dynamically converted into shared tokens for other traffic, improving overall link utilization. Then, a probabilistic packet loss mechanism based on high and low thresholds and a cubic function is adopted to ensure almost no packet loss under low load, while gradually accelerating packet loss under high load, effectively suppressing overload traffic, ensuring system stability, and providing more precise control over the packet loss curve. Finally, eBPF technology is used to separate user space and kernel space, combined with map channels for configuration and state synchronization, enabling high-frequency, low-latency traffic governance, thus achieving refined bandwidth management for multi-category traffic.

[0022] To facilitate understanding of the technical solutions of the embodiments of this application, the technical solutions of this application are described in detail below through specific embodiments. The above-mentioned related technologies are optional solutions and can be arbitrarily combined with the technical solutions of the embodiments of this application, all of which fall within the protection scope of the embodiments of this application. The embodiments of this application include at least some of the following contents.

[0023] This application proposes a network traffic management method, which is applied to kernel-mode modules. Figure 1 This is a flowchart illustrating a network traffic management method provided in an embodiment of this application, as shown below. Figure 1 As shown, the method includes the following steps: Step 101: Obtain the traffic management configuration command input by the user.

[0024] Here, kernel-mode modules mainly include eBPF Maps and eBPF programs. The eBPF Map is the core mechanism in eBPF for sharing data between kernel space and user space, or among multiple eBPF programs; it is essentially a key-value pair storage structure. An eBPF program is a sandboxed program that runs securely and efficiently within the kernel, extending kernel functionality without modifying the kernel source code or loading kernel modules.

[0025] The user-space module mainly includes a configuration management module and an eBPF management module. The configuration management module receives traffic governance configuration commands input by the user, parses and verifies these commands to obtain configuration information. The eBPF management module is responsible for mounting the corresponding eBPF program and passing the configuration information parsed by the configuration management module to the kernel-space part through the eBPF Map.

[0026] In this embodiment, the eBPF Map in the user-space module kernel-space module receives the configuration information corresponding to the traffic governance configuration instruction sent by the user-space module, and sends the configuration information to the eBPF program for subsequent traffic classification and control operations.

[0027] Traffic governance configuration directives refer to commands or rule definitions used in network or microservice architectures to control traffic through operations such as classification, rate limiting, scheduling, circuit breaking, and degradation. In the kernel, traffic governance uses a tree-structured set of configuration directives to implement operations such as queuing, scheduling, rate limiting, policy setting, and dropping of network data packets.

[0028] Step 102: Perform governance operations on network traffic based on traffic governance configuration instructions; wherein, the governance operations include one or more of the following: network traffic classification; network traffic bandwidth guarantee; network traffic bandwidth sharing; network traffic bandwidth rate limiting.

[0029] In this embodiment, the eBPF program in the kernel-mode module also has a built-in traffic shaping module. This module is used to classify and control traffic. After the eBPF program receives the configuration information corresponding to the traffic governance configuration instruction, it can perform one or more of the following on the network traffic according to the relevant rules specifically defined in the configuration information: network traffic classification, network traffic bandwidth guarantee, network traffic bandwidth sharing, and network traffic bandwidth rate limiting.

[0030] Network traffic classification refers to dividing traffic into different types by identifying the characteristics of network data packets or data flows, in order to implement differentiated QoS, security policies, resource allocation, or billing rules. In this application, network traffic classification refers to identifying and classifying traffic based on specific fields in the packet (such as five-tuple information, VLAN ID, etc.).

[0031] Network traffic bandwidth assurance refers to using technical means to ensure that specific users, services, or applications obtain the minimum available bandwidth resources in the network to maintain their QoS and avoid performance degradation due to competition from other traffic. In this application, network traffic bandwidth assurance refers to providing rigid bandwidth guarantees for critical traffic under different load conditions by calculating the average bandwidth of each category of traffic in real time and generating a committed bandwidth.

[0032] Network bandwidth sharing refers to a network resource configuration method in which multiple users, devices, or services share the same physical or logical bandwidth resource pool. Its core lies in achieving bandwidth reuse through a dynamic allocation mechanism to improve resource utilization and reduce costs. In this application, network bandwidth sharing refers to dynamically converting unused bandwidth into shared tokens for use by other traffic, while ensuring critical traffic flow, thereby improving overall link utilization.

[0033] Network traffic bandwidth limiting refers to restricting the data transmission rate of users or devices in a network to control resource usage and ensure QoS; its essence is to suppress overload traffic. In this application, network traffic bandwidth limiting refers to using a preset packet loss calculation mechanism to ensure almost no packet loss under low load, while gradually accelerating packet loss under high load, thereby effectively suppressing overload traffic and ensuring system stability.

[0034] In some embodiments, step 102 may include: After the first message enters the preset program in the kernel mode module, obtain the arrival time of the first message; If the time interval between the arrival time of the first message and the arrival time of the second message is greater than the preset prediction period, then the first preset algorithm, combined with the message statistics results, is used to calculate the average bandwidth of the traffic type to which the first message belongs, to obtain the first average bandwidth; wherein, The second message arrives before the first message arrives.

[0035] Here, the default program refers to the eBPF program in the kernel-mode module, and the message arrival time refers to the arrival timestamp corresponding to when the message arrives at the eBPF program.

[0036] Specifically, after the first packet enters the eBPF program in the kernel-mode module, the arrival timestamp corresponding to the arrival of the first packet (i.e., the arrival time of the first packet) and the arrival timestamp corresponding to the arrival of the previous packet (i.e., the arrival time of the second packet) are obtained. Then, the time interval between the arrival times of the first and second packets is calculated. If this time interval is greater than a preset prediction period, an average bandwidth calculation process is triggered to accurately assess the rate of each type of traffic. This includes using a first preset algorithm combined with packet statistics to calculate the average bandwidth of the traffic type to which the first packet belongs, thus obtaining the first average bandwidth. Based on the above process, the average bandwidth of each traffic category can be calculated to guide subsequent token filling operations.

[0037] Specifically, calculating the average bandwidth of the traffic type to which the first message belongs involves calculating the average bandwidth for each traffic type (such as video, voice, data, etc.). This means first grouping the first messages according to their type, then averaging the bandwidth data (such as the bit rate within a time window) within each group to obtain the average bandwidth for each traffic type.

[0038] In some embodiments, the message statistics result includes the traffic type to which the first message belongs; the first average bandwidth is calculated by combining the first preset algorithm with the message statistics result to the traffic type to which the first message belongs, including: Obtain the first cumulative traffic consumption of the first packet in the first period, the second cumulative traffic consumption of the first packet in the second period, and the second average bandwidth of the first packet in the second period; Based on the first cumulative traffic consumption and the second cumulative traffic consumption, the first traffic consumption of the first message in the first period is determined. Based on the first consumed traffic and the average calculation period, determine the first instantaneous rate of the first message within the first period; The first instantaneous rate is corrected for anomalies to obtain the second instantaneous rate; The first average bandwidth is obtained by updating the exponentially weighted moving average based on the second instantaneous rate and the second average bandwidth.

[0039] Here, the first preset algorithm is specifically a traffic bandwidth calculation algorithm, used to calculate the average bandwidth of each type of traffic. The packet statistics results specifically include the traffic type to which the first packet belongs. The first period is the current period in which the first packet is located, and the second period, preceding the first period, is the historical period.

[0040] Specifically, in the average bandwidth calculation process, an average calculation period is first set to control the time window for bandwidth statistics. Within each average calculation period, the first cumulative traffic consumption of the first packet in the first period (current period), the second cumulative traffic consumption of the first packet in the second period (historical period), and the second average bandwidth of the first packet in the second period (historical average bandwidth) are obtained. The first cumulative traffic consumption is subtracted from the second cumulative traffic consumption to obtain the traffic consumption of the first packet in the first period. Next, the traffic consumption of the first packet in the first period is divided by the average calculation period (time window) to obtain the first instantaneous rate of the first packet in the first period. Anomaly correction is applied to the first instantaneous rate to obtain the second instantaneous rate, in order to limit outliers and avoid statistical distortion caused by sudden traffic. Then, an exponentially weighted moving average method is used to smoothly update the data based on the second instantaneous rate and the second average bandwidth of the first packet in the second period to obtain the first average bandwidth, which is the average bandwidth of the traffic type to which the first packet belongs in the first period. The second average bandwidth of the first packet in the second period is the second average bandwidth of the traffic type to which the first packet belongs in the second period.

[0041] The above average bandwidth calculation process enables a smooth and robust average bandwidth estimation mechanism that effectively suppresses interference caused by sudden jitter while ensuring real-time performance.

[0042] In some embodiments, the above method further includes: If the time interval between the arrival time of the first message and the arrival time of the second message is greater than the preset token filling period, then the second preset algorithm is used in combination with the first average bandwidth to calculate the guarantee token for the traffic type to which the first message belongs, and one or more first guarantee tokens are obtained. One or more first security tokens are populated into the first security token bucket, the type of which corresponds to the traffic type to which the first message belongs.

[0043] Specifically, after the first message enters the eBPF program in the kernel-mode module, the arrival timestamp corresponding to the arrival of the first message to the eBPF program, i.e., the arrival time of the first message, is obtained, as well as the arrival timestamp corresponding to the arrival of the previous message before the first message to the eBPF program, i.e., the arrival time of the second message, is obtained. Then, the time interval between the arrival time of the first message and the arrival time of the second message is calculated. If the time interval is greater than the preset token filling period (the time interval between two token additions), the guarantee token calculation and filling process is triggered to ensure the minimum bandwidth requirement of the first message. This includes using a second preset algorithm combined with the average bandwidth of the traffic type to which the first message belongs (first average bandwidth) to calculate the guarantee tokens that need to be filled for the traffic type to which the first message belongs, obtaining one or more first guarantee tokens, and filling one or more first guarantee tokens one by one into the first guarantee token bucket corresponding to the traffic type to which the first message belongs.

[0044] Each type of traffic corresponds to a different security token bucket, and each security token bucket carries a corresponding category tag. Traffic of each type can find its corresponding security token bucket according to the category tag.

[0045] In some embodiments, a second preset algorithm is used in conjunction with a first average bandwidth to calculate a guarantee token for the traffic type to which the first packet belongs, resulting in one or more first guarantee tokens, including: If the first average bandwidth is less than the preset bandwidth threshold, the first average bandwidth is doubled to obtain the third average bandwidth. If the third average bandwidth is greater than the preset bandwidth threshold, the preset bandwidth threshold is determined as the target bandwidth; otherwise, the third average bandwidth is determined as the target bandwidth, which is the committed bandwidth of the traffic type to which the first message belongs. Within a preset time interval, a guarantee token is calculated based on the traffic type of the first packet according to the target bandwidth, resulting in one or more first guarantee tokens.

[0046] Here, the second preset algorithm is specifically a guarantee token calculation algorithm, which is used to calculate the number of guarantee tokens that need to be filled for each type of traffic.

[0047] Specifically, firstly, a committed bandwidth upper limit is set for each type of traffic as a preset bandwidth threshold. Then, the average bandwidth (first average bandwidth) of the traffic type to which the first packet belongs is compared with the preset bandwidth threshold. When the first average bandwidth is less than the preset threshold, the first average bandwidth is allowed to be doubled (e.g., ...). The process begins by obtaining a third average bandwidth to gradually approach the committed bandwidth limit. Next, the third average bandwidth is compared with a preset bandwidth threshold. If the third average bandwidth is greater than the preset bandwidth threshold, the preset bandwidth threshold is determined as the target bandwidth, serving as the committed bandwidth for the traffic type to which the first message belongs. Otherwise, the third average bandwidth is also determined as the target bandwidth, serving as the committed bandwidth for the traffic type to which the first message belongs. Then, within a time interval, the guarantee tokens that should be filled for the traffic type to which the first message belongs are calculated based on the target bandwidth, resulting in one or more first guarantee tokens.

[0048] Through the above-mentioned guarantee token calculation process, hard guarantees can be provided for critical traffic in high-concurrency scenarios, while also taking into account the dynamic recovery and redistribution of underutilized bandwidth, thereby realizing a bandwidth governance mechanism of "guarantee first, shared elasticity".

[0049] In some embodiments, the above method further includes: If the number of one or more first security tokens is greater than the capacity of the first security token bucket, then the number of one or more first security tokens is subtracted from the capacity of the first security token bucket to obtain one or more first surplus tokens. Add one or more first excess tokens to the shared token bucket.

[0050] Specifically, before filling one or more first guarantee tokens into the first guarantee token bucket corresponding to the traffic type of the first message, the quantity of one or more first guarantee tokens can be compared with the capacity of the first guarantee token bucket. If the quantity of one or more first guarantee tokens is greater than the capacity of the first guarantee token bucket, the quantity of one or more first guarantee tokens is subtracted from the capacity of the first guarantee token bucket to obtain one or more first surplus tokens. Then, these one or more first surplus tokens are filled into the shared token bucket one by one. Through the above process, surplus tokens can be transferred to the shared token bucket for use by other types of traffic when needed, thereby realizing dynamic sharing and reuse of bandwidth resources.

[0051] In some embodiments, step 102 further includes: After the first message enters the preset program in the kernel mode module, the five-tuple information of the first message is obtained, and the traffic type of the first message is determined based on the five-tuple information of the first message. The first safeguard token bucket is determined based on the traffic type to which the first message belongs, and the type of the first safeguard token bucket corresponds to the traffic type to which the first message belongs; The first message is processed based on the number of tokens in the first security token bucket and the size of the first message.

[0052] Here, the 5-tuple information is a key parameter combination used to uniquely identify a network session or data stream in network communication. The 5-tuple information usually consists of the following five elements: source IP address (the IP address of the host that sends the message), destination IP address (the IP address of the host that receives the message), source port number (the port number used by the sending application), destination port number (the port number listened to by the receiving application), and transport layer protocol (such as TCP (6), UDP (17), ICMP (1), etc., identified by the "protocol number" field in the IP header).

[0053] Specifically, after the first packet enters the eBPF program in the kernel-mode module, it obtains the five-tuple information of the first packet and determines the traffic type (such as video, voice, data, etc.) based on the source IP address, destination IP address, source port number, destination port number, and transport layer protocol included in the five-tuple information. Then, it searches for the corresponding first guarantee token bucket based on the traffic type of the first packet and processes the first packet according to the number of tokens in the first guarantee token bucket and the number of tokens required for the size of the first packet, including allowing the first packet to pass or discarding it.

[0054] In some embodiments, the first message is processed based on the number of tokens in the first security token bucket and the size of the first message, including: One or more first guarantee tokens are determined based on the size of the first message, and the one or more first guarantee tokens are the guarantee tokens consumed for forwarding the first message; If the number of one or more first security tokens is less than or equal to the number of tokens in the first security token bucket, then one or more first security tokens are obtained from the first security token bucket, and one or more first security tokens are consumed to allow the first message to pass; or, If the number of one or more first security tokens is greater than the number of tokens in the first security token bucket, the third preset algorithm is used to calculate the packet loss of the first message to obtain the packet loss probability of the first message; and the first message is processed based on the packet loss probability of the first message.

[0055] Specifically, since each byte of a message requires one token, the number of security tokens required for the first message conversion can be directly determined based on the size of the first message (in bytes). That is, one or more first security tokens are determined based on the size of the first message. Then, the number of one or more first security tokens is compared with the number of tokens in the first security token bucket. If the number of one or more first security tokens is less than or equal to the number of tokens in the first security token bucket, it means that there are enough tokens in the first security token bucket. One or more first security tokens can be obtained from the first security token bucket and consumed to allow the first message to pass. Otherwise, it means that there are not enough tokens in the first security token bucket. The third preset algorithm needs to be used to calculate the packet loss of the first message to obtain the packet loss probability of the first message. The first message is then processed according to the packet loss probability, including trying to obtain a token from the shared token bucket to allow the first message to pass, or discarding the first message.

[0056] In some embodiments, a third preset algorithm is used to calculate the packet loss probability of the first message, including: If the index of the first message is less than or equal to the first threshold, then the probability of packet loss for the first message is determined to be zero; or, If the index of the first message is greater than or equal to the second threshold, then the packet loss probability of the first message is determined to be the maximum packet loss probability; or, If the index of the first message is greater than the first threshold and less than the second threshold, the index of the first message is normalized to obtain the normalized index of the first message; the target probability is determined based on the normalized index of the first message and the maximum packet loss probability, and the target probability is determined as the packet loss probability of the first message.

[0057] Here, the third preset algorithm is specifically a packet loss calculation algorithm, which is used to calculate the packet loss probability of a message.

[0058] Specifically, firstly, two threshold parameters are set: a first threshold and a second threshold, as well as a maximum packet loss probability. Then, the metrics of the first packet, such as queue length and rate estimation, are obtained, and the metrics of the first packet are compared with the first threshold and the second threshold respectively. If the metrics of the first packet are less than or equal to the first threshold, the packet loss rate of the first packet is determined to be 0, that is, the first packet is not discarded. If the metrics of the first packet are greater than or equal to the second threshold, the packet loss probability of the first packet is determined to be the maximum packet loss probability, that is, the first packet needs to be discarded. If the metrics of the first packet are greater than the first threshold and less than the second threshold, normalization processing is performed based on the first threshold, the second threshold, and the metrics of the first packet to obtain the normalized progress parameter, which is the normalized metric of the first packet. The target probability is calculated using a cubic function based on the normalized metric of the first packet and the maximum packet loss probability. This target probability is the packet loss probability of the first packet. Then, the comparison result between the packet loss probability of the first packet and the preset packet loss threshold can be used to determine whether the first packet needs to be discarded.

[0059] It should be noted that if the calculated target probability exceeds 1,000,000 ppm, the calculated result needs to be truncated to ensure that the packet loss probability of the first message does not exceed 100%.

[0060] Through the above packet loss calculation process, a nonlinear packet loss mechanism based on threshold segmentation control can be realized. This mechanism can ensure transmission reliability under low load while rapidly increasing the packet loss probability under high load, thereby effectively suppressing overload traffic and ensuring the overall stability and fairness of the system.

[0061] In some embodiments, the first packet is processed based on the packet loss probability of the first packet, including: If the packet loss probability of the first packet is the maximum packet loss probability, or if the packet loss probability of the first packet is greater than or equal to a preset packet loss threshold, then the first packet is discarded; or... If the packet loss probability of the first packet is zero, or if the packet loss probability of the first packet is less than the preset packet loss threshold, then: Obtain a shared token bucket; if the number of one or more first security tokens is greater than the number of tokens in the shared token bucket, discard the first message; or, if the number of one or more first security tokens is less than or equal to the number of tokens in the shared token bucket, obtain one or more shared tokens from the shared token bucket and consume one or more shared tokens to allow the first message to pass, wherein the number of one or more shared tokens is the same as the number of one or more first security tokens.

[0062] Specifically, if the packet loss probability of the first packet reaches the maximum packet loss probability, or if the packet loss probability of the first packet is greater than or equal to a preset packet loss threshold, it indicates that there may be network congestion or insufficient bandwidth, and the first packet needs to be dropped; or, If the probability of packet loss for the first packet is zero, or if the probability of packet loss for the first packet is less than a preset packet loss threshold, then the first packet does not need to be discarded. However, since the number of tokens in the first guaranteed token bucket is insufficient, it is necessary to attempt to obtain a sufficient number of tokens from the shared token bucket to forward the first packet. The number of one or more first guaranteed tokens required for the first packet is compared with the number of tokens in the shared token bucket to determine if the number of tokens in the shared token bucket is sufficient. If the number of one or more first guaranteed tokens is greater than the number of tokens in the shared token bucket, then the number of tokens in the shared token bucket is insufficient, and the first packet needs to be discarded; otherwise, the number of tokens in the shared token bucket is sufficient. In this case, one or more shared tokens equal to the number of one or more first guaranteed tokens can be obtained from the shared token bucket, and one or more shared tokens can be consumed to allow the first packet to pass. Through the above process, it is ensured that traffic receives priority bandwidth while non-guaranteed traffic can also be fairly utilized when network resources are idle.

[0063] In the technical solution of this application embodiment, the kernel-mode module obtains the traffic governance configuration command input by the user; and performs governance operations on network traffic based on the traffic governance configuration command; wherein, the governance operations include one or more of the following: network traffic classification; network traffic bandwidth guarantee; network traffic bandwidth sharing; and network traffic bandwidth rate limiting. In this way, not only can network traffic classification be implemented in the kernel data path, but also bandwidth guarantee, bandwidth sharing, and bandwidth rate limiting for different types of traffic can be achieved, thereby avoiding the problems of functional fragmentation and incompatibility in traditional solutions.

[0064] This application also provides a traffic management system based on eBPF. Figure 2 This application provides an embodiment of an architecture diagram of a traffic governance system based on eBPF, as shown below. Figure 2 As shown, the system mainly consists of two parts: user space and kernel space. The user space includes a configuration management module and an eBPF management module. The configuration management module receives traffic governance configuration commands input by the user, parses and verifies these commands to obtain configuration information. The eBPF management module is responsible for mounting the corresponding eBPF program and transmitting the configuration information parsed by the configuration management module to the kernel space via the eBPF Map. The kernel space mainly includes the eBPF Map and the eBPF program. The eBPF Map serves as an information transmission channel between user space and kernel space, storing and synchronizing the configuration and status information sent by the eBPF management module. The eBPF program has a built-in traffic shaping module for classifying and controlling traffic, including bandwidth limiting, bandwidth guarantee, and bandwidth sharing.

[0065] The traffic shaping module specifically includes the following three core logics: (1) Average bandwidth calculation logic In the average bandwidth calculation logic, when a packet enters the eBPF program, if the arrival time interval between the current packet and the previous packet is greater than the preset prediction period, the average bandwidth calculation process is triggered. The average bandwidth of the traffic type to which the current packet belongs is calculated by combining the traffic bandwidth calculation algorithm with the packet statistics results, which is used to guide the subsequent token filling operation.

[0066] Figure 3 This is a flowchart illustrating the average bandwidth calculation logic in the traffic shaping module provided in this application embodiment, as shown below. Figure 3 As shown, the average bandwidth calculation logic specifically includes the following steps: Step 301: The message enters the eBPF program.

[0067] Step 302: Calculate the time interval between the arrival time of the current message and the arrival time of the previous message.

[0068] Step 303: Determine whether the time interval is greater than the preset prediction period. If yes, proceed to step 304; otherwise, proceed to step 305.

[0069] Step 304: Calculate the average bandwidth of the traffic type to which the current packet belongs using a traffic bandwidth calculation algorithm combined with packet statistics results.

[0070] Step 405: End the process.

[0071] In order to accurately assess the rate of traffic in each category during the average bandwidth calculation process, an average bandwidth calculation mechanism based on periodic sampling and smooth updates is introduced. Figure 4 This is a flowchart illustrating the traffic bandwidth calculation algorithm provided in the embodiments of this application, as shown below. Figure 4 As shown, the bandwidth calculation algorithm specifically includes the following steps: Step 401: Calculate the traffic consumption within the current message's cycle.

[0072] Set the average calculation period as Used to control the time window for bandwidth statistics; sets historical average values. This is used to store the statistical results (historical average bandwidth) of the previous period. In each... Inside, record the current cumulative consumption. and the cumulative value of the previous period Subtracting them gives the traffic consumption for the current period. The calculation formula is as follows: (1) Step 402: Calculate the instantaneous rate within the current message's period based on the consumed traffic and time window within the current message's period.

[0073] Based on the traffic consumption within the current message's cycle With time window Calculate the instantaneous rate within the current message's period. The calculation formula is as follows: (2) Step 403: Perform anomaly correction on the instantaneous rate within the current message period to obtain the corrected instantaneous rate within the current message period.

[0074] Instantaneous rate within the current message's period Perform anomaly correction, including using The algorithm limits outliers to avoid statistical distortion caused by sudden traffic surges.

[0075] Step 404: Perform a smooth update based on the corrected instantaneous rate within the current period and the historical average bandwidth of the previous period to obtain the average bandwidth within the current period.

[0076] The method uses an exponentially weighted moving average combined with the instantaneous rate adjusted for the current message's period. To update the historical average bandwidth of the previous period This yields the average bandwidth within the current message's period. Its update formula is: (3) The above algorithm enables a smooth and robust average bandwidth estimation mechanism that effectively suppresses interference caused by sudden jitter while ensuring real-time performance.

[0077] (2) Token filling logic Figure 5 This is a flowchart illustrating the token filling logic in the traffic shaping module provided in this application embodiment, as shown below. Figure 5 As shown, the token filling logic specifically includes the following steps: When a message enters the eBPF program, if the arrival interval between the current message and the previous message is greater than the preset token filling period, the token filling process is triggered. The number of guarantee tokens to be filled for the current message's traffic type is calculated based on the average bandwidth of the traffic type to which the current message belongs and the guarantee token calculation algorithm. All the calculated guarantee tokens are then filled into each guarantee token bucket. Excess tokens are transferred to the root shared bucket for use by other traffic types when needed, thereby realizing dynamic sharing and reuse of bandwidth resources.

[0078] Step 501: The message enters the eBPF program.

[0079] Step 502: Calculate the time interval between the arrival time of the current message and the arrival time of the previous message.

[0080] Step 503: Determine whether the time interval is greater than the preset token filling period. If yes, proceed to step 504; otherwise, proceed to step 507.

[0081] Step 504: Calculate the number of guarantee tokens required for the current traffic type by using the guarantee token calculation algorithm and the average bandwidth of the traffic type to which the current packet belongs, and fill all the calculated guarantee tokens into the guarantee token bucket one by one.

[0082] Step 505: Determine whether the number of guarantee tokens required to fill the traffic type of the current message is greater than the capacity of the guarantee token bucket. If yes, it means there are extra tokens, proceed to step 506; otherwise, proceed to step 507.

[0083] Step 506: Subtract the capacity of the guarantee token bucket from the number of guarantee tokens required for the traffic type to which the current packet belongs, and fill the excess tokens into the root shared bucket.

[0084] Step 507: End the process.

[0085] To ensure the minimum bandwidth requirements of categorized traffic during the guarantee token calculation process, committed bandwidth calculation logic is introduced. This logic prioritizes allocating guarantee tokens to each category of traffic during each bucket filling. Figure 6 This is a flowchart illustrating the security token calculation algorithm provided in an embodiment of this application, as shown below. Figure 6 As shown, the guarantee token calculation algorithm includes the following steps: Step 601: Determine the committed bandwidth for the traffic type of the current message based on the committed bandwidth limit and the average bandwidth within the current message period.

[0086] Set the committed bandwidth limit for categorized traffic as follows: The target bandwidth is estimated based on the average bandwidth within the current message period. ,when Less than At that time, it is allowed to Try doubling (e.g.) ( ), to gradually approach the bandwidth limit. If More than double Then take Otherwise take The value after doubling. The final result serves as the committed bandwidth for the traffic type to which the current message belongs. The calculation formula is as follows: (4) Step 602: Within a preset time interval, calculate the number of guarantee tokens that need to be filled for the traffic type to which the current message belongs, based on the committed bandwidth of the traffic type to which the current message belongs.

[0087] In time interval Within, the committed bandwidth is based on the traffic type of the current message. Calculate the number of guarantee tokens to be filled for the traffic type to which the current message belongs. The calculation formula is as follows: (5) The algorithm described above can provide hard protection for critical traffic in high-concurrency scenarios, while also taking into account the dynamic recovery and reallocation of underutilized bandwidth, thereby achieving a bandwidth governance mechanism of "prioritizing protection and sharing flexibility".

[0088] (3) Token consumption logic Figure 7 This is a flowchart illustrating the token consumption logic in the traffic shaping module provided in this application embodiment, as shown below. Figure 7 As shown, the token consumption logic specifically includes the following steps: When a message arrives at the eBPF program, it first attempts to consume the tokens in the guarantee bucket of its class. If there are not enough tokens in the guarantee bucket, a preset packet loss algorithm is used to determine whether to drop the message directly; if not dropped, it continues to try to obtain tokens from the shared bucket to forward the current message.

[0089] Step 701: The message enters the eBPF program.

[0090] Step 702: Extract the five-tuple information or VLAN ID of the current packet as the traffic category marker for the current packet.

[0091] Step 703: Look up the corresponding security token bucket for the current packet according to the traffic category tag of the current packet.

[0092] Step 704: Compare the number of guarantee tokens required for the traffic type to which the current message belongs with the number of guarantee tokens in the guarantee token bucket to determine whether the number of guarantee tokens in the guarantee token bucket is sufficient. If the former is greater than the latter, it means that the number of guarantee tokens in the guarantee token bucket is insufficient, and proceed to step 706; otherwise, it means that the number of guarantee tokens in the guarantee token bucket is sufficient, and proceed to step 705.

[0093] Step 705: Consume the security token required for the current packet's traffic type in the security token bucket, allow the current packet to pass, and proceed to step 711.

[0094] Step 706: Calculate the packet loss probability of the current packet using a preset packet loss algorithm. Determine whether the current packet needs to be discarded based on the packet loss probability. If yes, proceed to step 707; otherwise, proceed to step 708.

[0095] Step 707: Discard the current message and proceed to step 711.

[0096] Step 708: Attempt to obtain a shared token from the root shared bucket.

[0097] Step 709: Compare the number of guarantee tokens required for the traffic type to which the current packet belongs with the number of tokens in the root shared bucket to determine whether the number of tokens in the root shared bucket is sufficient. If the former is greater than the latter, it means that the number of tokens in the root shared bucket is insufficient, and return to step 707; otherwise, it means that the number of tokens in the root shared bucket is sufficient, and proceed to step 710.

[0098] Step 710: Consume the token required for the traffic type to which the current packet belongs within the root shared bucket to allow the current packet to pass.

[0099] Step 711: End the process.

[0100] During packet loss calculation, a packet loss judgment logic is triggered when the number of guarantee tokens in the guarantee bucket is insufficient. To avoid sudden large-scale packet loss, a probability-based packet loss mechanism is proposed. Figure 8 This is a flowchart illustrating the packet loss calculation algorithm provided in the embodiments of this application, as shown below. Figure 8 As shown, the packet loss calculation algorithm includes the following steps: Step 801: Obtain the current message metrics.

[0101] Step 802: Compare the current message metrics with the low / high threshold.

[0102] Step 803: If the current message index is less than or equal to the low threshold, proceed to step 806.

[0103] Step 804: If the current message index is greater than or equal to the high threshold, proceed to step 807.

[0104] Step 805: If the current message index is greater than the low threshold and less than the high threshold, proceed to step 808.

[0105] Set two threshold parameters: low threshold and high threshold and maximum packet loss probability (Expressed in parts per million (PPM), ranging from 0 to 1,000,000 ppm, or 0%–100%).

[0106] Step 806: Determine that the packet loss probability of the current message is 0, and proceed to step 811.

[0107] If the current message index (e.g., queue length or rate estimate) less than or equal to a low threshold If the probability of packet loss for the current message is 0, then the current message will not be discarded.

[0108] Step 807: Determine that the packet loss probability of the current message has reached the maximum packet loss probability, and proceed to step 812.

[0109] If the current message index (e.g., queue length or rate estimate) greater than or equal to a high threshold If the packet loss probability of the current message has reached the maximum packet loss probability, then it is determined that the packet loss probability of the current message has reached the maximum packet loss probability. The current message needs to be discarded.

[0110] Step 808: Perform normalization processing based on the current message metrics, low threshold, and high threshold to obtain the normalized progress parameters of the current message.

[0111] If the current message index Greater than the low threshold And less than the high threshold Based on the current message metrics Low threshold and high threshold Perform normalization processing and calculate the current message index. Normalized progress parameters The calculation formula is as follows: (6) in, This indicates the current message index. At low threshold and high threshold The relative positions between them.

[0112] Step 809: Calculate the maximum packet loss probability and the normalized progress parameter of the current packet using a cubic function to obtain the packet loss probability of the current packet.

[0113] Using a cubic function based on the maximum packet loss probability and the normalized progress parameters of the current message Calculate the packet loss rate of the current message. The calculation formula is as follows: (7) This design ensures that the packet loss probability increases slowly when approaching a low threshold, while it increases rapidly when approaching a high threshold, thus forming a "smooth + accelerated" packet loss curve.

[0114] If the calculation result (the packet loss rate of the current message) If the concentration exceeds 1,000,000 ppm, a safety cutoff will be performed to ensure that the packet loss probability does not exceed 100%.

[0115] Step 810: Determine whether the packet loss probability of the current message is less than the preset packet loss threshold. If yes, proceed to step 811; otherwise, proceed to step 812.

[0116] Step 811: Without discarding the current message, attempt to obtain a shared token from the root shared bucket.

[0117] Step 812: Discard the current message.

[0118] The algorithm described above enables a nonlinear packet loss mechanism based on threshold segmentation control. This mechanism ensures transmission reliability under low load while rapidly increasing the packet loss probability under high load, thereby effectively suppressing overload traffic and guaranteeing the overall stability and fairness of the system.

[0119] By employing the three logics of average bandwidth calculation, token filling, and token consumption, it is possible to ensure that guaranteed traffic has priority access to bandwidth, while non-guaranteed traffic can be fairly utilized when network resources are idle.

[0120] The technical solution provided in this application implements a traffic shaping mechanism that ensures bandwidth for critical traffic and dynamically shares remaining bandwidth by calculating dynamically committed bandwidth for each category of traffic and filling it into a guarantee bucket, while converting unused bandwidth into shared tokens and filling it into a shared bucket. Simultaneously, a smooth and robust average bandwidth estimation mechanism is provided to effectively suppress interference caused by sudden jitter while ensuring real-time performance. Furthermore, by providing a guarantee token calculation mechanism, hard guarantees are provided for critical traffic in multi-traffic concurrent scenarios, while also considering the dynamic recovery and reallocation of underutilized bandwidth, thus achieving a bandwidth governance mechanism of "priority guarantee, flexible sharing." In addition, by providing a non-linear packet loss mechanism based on threshold segmentation control, transmission reliability under low load is ensured while rapidly increasing the packet loss probability under high load, thereby effectively suppressing overload traffic and ensuring the overall stability and fairness of the system.

[0121] This application also proposes a network traffic management device, which is applied to a kernel-mode module. Figure 9 This is a schematic diagram of the structure of a network traffic management device provided in an embodiment of this application, as shown below. Figure 9 As shown, the device includes: The acquisition unit 901 is used to acquire the traffic management configuration instructions input by the user.

[0122] The processing unit 902 is used to perform governance operations on network traffic based on traffic governance configuration instructions; wherein the governance operations include one or more of the following: network traffic classification; network traffic bandwidth guarantee; network traffic bandwidth sharing; and network traffic bandwidth rate limiting.

[0123] In some embodiments, the processing unit 902 is specifically used for: After the first message enters the preset program in the kernel mode module, obtain the arrival time of the first message; If the time interval between the arrival time of the first message and the arrival time of the second message is greater than the preset prediction period, then the first preset algorithm, combined with the message statistics results, is used to calculate the average bandwidth of the traffic type to which the first message belongs, to obtain the first average bandwidth; wherein, The second message arrives before the first message arrives.

[0124] In some embodiments, the processing unit 902 is further specifically used for: If the time interval between the arrival time of the first message and the arrival time of the second message is greater than the preset token filling period, then the second preset algorithm is used in combination with the first average bandwidth to calculate the guarantee token for the traffic type to which the first message belongs, and one or more first guarantee tokens are obtained. One or more first security tokens are populated into the first security token bucket, the type of which corresponds to the traffic type to which the first message belongs.

[0125] In some embodiments, the processing unit 902 is further specifically used for: If the number of one or more first security tokens is greater than the capacity of the first security token bucket, then the number of one or more first security tokens is subtracted from the capacity of the first security token bucket to obtain one or more first surplus tokens. Add one or more first excess tokens to the shared token bucket.

[0126] In some embodiments, the processing unit 902 is further specifically used for: After the first message enters the preset program in the kernel mode module, the five-tuple information of the first message is obtained, and the traffic type of the first message is determined based on the five-tuple information of the first message. The first safeguard token bucket is determined based on the traffic type to which the first message belongs, and the type of the first safeguard token bucket corresponds to the traffic type to which the first message belongs; The first message is processed based on the number of tokens in the first security token bucket and the size of the first message.

[0127] In some embodiments, the processing unit 902 is further specifically used for: One or more first guarantee tokens are determined based on the size of the first message, and the one or more first guarantee tokens are the guarantee tokens consumed for forwarding the first message; If the number of one or more first security tokens is less than or equal to the number of tokens in the first security token bucket, then one or more first security tokens are obtained from the first security token bucket, and one or more first security tokens are consumed to allow the first message to pass; or, If the number of one or more first security tokens is greater than the number of tokens in the first security token bucket, the third preset algorithm is used to calculate the packet loss of the first message to obtain the packet loss probability of the first message; and the first message is processed based on the packet loss probability of the first message.

[0128] In some embodiments, the processing unit 902 is further specifically used for: If the packet loss probability of the first packet is the maximum packet loss probability, or if the packet loss probability of the first packet is greater than or equal to a preset packet loss threshold, then the first packet is discarded; or... If the packet loss probability of the first packet is zero, or if the packet loss probability of the first packet is less than the preset packet loss threshold, then: Obtain a shared token bucket; if the number of one or more first security tokens is greater than the number of tokens in the shared token bucket, discard the first message; or, if the number of one or more first security tokens is less than or equal to the number of tokens in the shared token bucket, obtain one or more shared tokens from the shared token bucket and consume one or more shared tokens to allow the first message to pass, wherein the number of one or more shared tokens is the same as the number of one or more first security tokens.

[0129] In some embodiments, the message statistics result includes the traffic type to which the first message belongs; wherein, Processing unit 902 is also specifically used for: Obtain the first cumulative traffic consumption of the first packet in the first period, the second cumulative traffic consumption of the first packet in the second period, and the second average bandwidth of the first packet in the second period; Based on the first cumulative traffic consumption and the second cumulative traffic consumption, the first traffic consumption of the first message in the first period is determined. Based on the first consumed traffic and the average calculation period, determine the first instantaneous rate of the first message within the first period; The first instantaneous rate is corrected for anomalies to obtain the second instantaneous rate; The first average bandwidth is obtained by updating the exponentially weighted moving average based on the second instantaneous rate and the second average bandwidth.

[0130] In some embodiments, the processing unit 902 is further specifically used for: If the first average bandwidth is less than the preset bandwidth threshold, the first average bandwidth is doubled to obtain the third average bandwidth. If the third average bandwidth is greater than the preset bandwidth threshold, the preset bandwidth threshold is determined as the target bandwidth; otherwise, the third average bandwidth is determined as the target bandwidth, which is the committed bandwidth of the traffic type to which the first message belongs. Within a preset time interval, a guarantee token is calculated based on the traffic type of the first packet according to the target bandwidth, resulting in one or more first guarantee tokens.

[0131] In some embodiments, the processing unit 902 is further specifically used for: If the index of the first message is less than or equal to the first threshold, then the probability of packet loss for the first message is determined to be zero; or, If the index of the first message is greater than or equal to the second threshold, then the packet loss probability of the first message is determined to be the maximum packet loss probability; or, If the index of the first message is greater than the first threshold and less than the second threshold, the index of the first message is normalized to obtain the normalized index of the first message; the target probability is determined based on the normalized index of the first message and the maximum packet loss probability, and the target probability is determined as the packet loss probability of the first message.

[0132] Those skilled in the art should understand that Figure 9 The functions of each unit in the communication device shown can be understood by referring to the relevant description of the aforementioned method. Figure 9 The functions of each unit in the communication device shown can be implemented by a program running on a processor or by specific logic circuits.

[0133] Figure 10 This is a schematic diagram of the processing device provided in an embodiment of this application. The processing device may be a terminal device or a network device. Figure 10 The processing device shown includes a processor 1001, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0134] Optionally, such as Figure 10 As shown, the processing device may further include a memory 1002. The processor 1001 can retrieve and run computer programs from the memory 1002 to implement the methods described in the embodiments of this application.

[0135] The memory 1002 can be a separate device independent of the processor 1001, or it can be integrated into the processor 1001.

[0136] Optionally, such as Figure 10As shown, the processing device may also include a transceiver 1003, which the processor 1001 can control to communicate with other devices. Specifically, it can send information or data to other devices or receive information or data sent by other devices.

[0137] The transceiver 1003 may include a transmitter and a receiver. The transceiver 1003 may further include an antenna, and the number of antennas may be one or more.

[0138] The processing device may specifically be the network traffic management device of this application embodiment, and the processing device can implement the corresponding processes of the various methods implemented in this application embodiment. For the sake of brevity, it will not be described in detail here.

[0139] It should be understood that the processor in the embodiments of this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0140] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0141] This application also provides a computer-readable storage medium for storing a computer program. This computer-readable storage medium can be applied to the processing device in this application embodiment, and the computer program causes the computer to execute the corresponding processes implemented by the various methods in this application embodiment; for brevity, further details are omitted here.

[0142] This application also provides a computer program product, including computer program instructions. This computer program product can be applied to the processing device in this application embodiment, and the computer program instructions cause the computer to execute the corresponding processes implemented by the various methods in this application embodiment; for brevity, further details are omitted here.

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

[0144] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

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

[0147] In addition, 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.

[0148] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they 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 the prior art, or a portion 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, 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, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0149] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A network traffic management method, characterized in that, Applied to kernel-mode modules, the method includes: Obtain user-inputted traffic management configuration commands; The network traffic is managed based on the traffic management configuration instructions; wherein the management operations include one or more of the following: network traffic classification; network traffic bandwidth guarantee; network traffic bandwidth sharing; and network traffic bandwidth rate limiting.

2. The method according to claim 1, characterized in that, The process of performing network traffic governance operations based on the traffic governance configuration instructions includes: After the first message enters the preset program in the kernel mode module, the arrival time of the first message is obtained; If the time interval between the arrival time of the first message and the arrival time of the second message is greater than a preset prediction period, then a first preset algorithm is used in conjunction with message statistics to calculate the average bandwidth of the traffic type to which the first message belongs, thereby obtaining a first average bandwidth; wherein, The arrival time of the second message is earlier than the arrival time of the first message.

3. The method according to claim 2, characterized in that, The method further includes: If the time interval between the arrival time of the first message and the arrival time of the second message is greater than the preset token filling period, then the second preset algorithm is used in combination with the first average bandwidth to calculate the guarantee token for the traffic type to which the first message belongs, and one or more first guarantee tokens are obtained. The one or more first security tokens are filled into a first security token bucket, the type of which corresponds to the traffic type to which the first message belongs.

4. The method according to claim 3, characterized in that, The method further includes: If the number of the one or more first security tokens is greater than the capacity of the first security token bucket, then the number of the one or more first security tokens is subtracted from the capacity of the first security token bucket to obtain one or more first surplus tokens; Fill the shared token bucket with the one or more first excess tokens.

5. The method according to claim 2, characterized in that, The message statistics result includes the traffic type to which the first message belongs; the step of using a first preset algorithm to combine the message statistics result to calculate the average bandwidth of the traffic type to which the first message belongs, and obtaining the first average bandwidth, includes: Obtain the first cumulative traffic consumption of the first packet in the first period, the second cumulative traffic consumption of the first packet in the second period, and the second average bandwidth of the first packet in the second period; Based on the first cumulative traffic consumption and the second cumulative traffic consumption, the first traffic consumption of the first message within the first period is determined; Based on the first consumed traffic and the average calculation period, the first instantaneous rate of the first message within the first period is determined; Anomaly correction is performed on the first instantaneous rate to obtain the second instantaneous rate; The first average bandwidth is obtained by performing an exponentially weighted moving average update based on the second instantaneous rate and the second average bandwidth.

6. The method according to claim 3, characterized in that, The method employs a second preset algorithm combined with the first average bandwidth to calculate the guarantee token for the traffic type to which the first packet belongs, resulting in one or more first guarantee tokens, including: If the first average bandwidth is less than a preset bandwidth threshold, the first average bandwidth is doubled to obtain a third average bandwidth. If the third average bandwidth is greater than the preset bandwidth threshold, then the preset bandwidth threshold is determined as the target bandwidth; otherwise, the third average bandwidth is determined as the target bandwidth, where the target bandwidth is the committed bandwidth of the traffic type to which the first message belongs. Within a preset time interval, a guarantee token is calculated based on the target bandwidth for the traffic type to which the first message belongs, to obtain one or more first guarantee tokens.

7. The method according to claim 1, characterized in that, The process of performing network traffic governance operations based on the traffic governance configuration instructions includes: After the first message enters the preset program in the kernel mode module, the five-tuple information of the first message is obtained, and the traffic type to which the first message belongs is determined based on the five-tuple information of the first message. The first guarantee token bucket is determined based on the traffic type to which the first message belongs, and the type of the first guarantee token bucket corresponds to the traffic type to which the first message belongs. The first message is processed based on the number of tokens in the first security token bucket and the size of the first message.

8. The method according to claim 7, characterized in that, The processing of the first message based on the number of tokens in the first security token bucket and the size of the first message includes: One or more first guarantee tokens are determined based on the size of the first message, and the one or more first guarantee tokens are the guarantee tokens consumed for forwarding the first message; If the number of the one or more first security tokens is less than or equal to the number of tokens in the first security token bucket, then the one or more first security tokens are retrieved from the first security token bucket and consumed to allow the first message to pass; or, If the number of the one or more first security tokens is greater than the number of tokens in the first security token bucket, the first message is calculated for packet loss using a third preset algorithm to obtain the packet loss probability of the first message; and the first message is processed based on the packet loss probability of the first message.

9. The method according to claim 8, characterized in that, The step of using a third preset algorithm to calculate the packet loss probability of the first packet includes: If the index of the first message is less than or equal to the first threshold, then the packet loss probability of the first message is determined to be zero; or, If the index of the first message is greater than or equal to the second threshold, then the packet loss probability of the first message is determined to be the maximum packet loss probability; or, If the index of the first message is greater than the first threshold and less than the second threshold, the index of the first message is normalized to obtain the normalized index of the first message; the target probability is determined based on the normalized index of the first message and the maximum packet loss probability, and the target probability is determined as the packet loss probability of the first message.

10. The method according to claim 9, characterized in that, The processing of the first packet based on the packet loss probability of the first packet includes: If the packet loss probability of the first packet is the maximum packet loss probability, or if the packet loss probability of the first packet is greater than or equal to a preset packet loss threshold, then the first packet is discarded; or, If the packet loss probability of the first message is zero, or if the packet loss probability of the first message is less than a preset packet loss threshold, then: Obtain a shared token bucket; if the number of the one or more first security tokens is greater than the number of tokens in the shared token bucket, then discard the first message; or, if the number of the one or more first security tokens is less than or equal to the number of tokens in the shared token bucket, then obtain one or more shared tokens from the shared token bucket and consume the one or more shared tokens to allow the first message to pass, wherein the number of the one or more shared tokens is the same as the number of the one or more first security tokens.

11. A network traffic management device, characterized in that, Applied to a kernel module, the device includes: The acquisition unit is used to acquire traffic management configuration commands input by the user; The processing unit is configured to perform governance operations on network traffic based on the traffic governance configuration instructions; wherein the governance operations include one or more of the following: network traffic classification; network traffic bandwidth guarantee; network traffic bandwidth sharing; and network traffic bandwidth rate limiting.

12. A processing apparatus, characterized in that, include: A processor and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to perform the method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, Used to store a computer program that causes a computer to perform the method as described in any one of claims 1 to 10.

14. A computer program product, characterized in that, It includes computer program instructions that cause a computer to perform the method as described in any one of claims 1 to 10.

Images