Flow control method and device based on dynamic queue weight and global overflow bucket

Abstract

The invention relates to a flow control method and device based on a dynamic queue weight and a global overflow bucket. The method comprises the following steps: distributing network messages to corresponding message queues according to a preset classification rule; dynamically generating the queue weight of each queue according to the real-time queue state of each queue; calculating virtual completion time of each queue based on the queue weight; determining a target message to be sent according to the virtual completion time; when the number of the tokens in the queue where the target message is located is insufficient, the tokens are called from a global overflow bucket; and sending the target message based on the called token. According to the flow control method and device based on the dynamic queue weight and the global overflow bucket, time delay can be reduced, packet loss can be reduced, the utilization rate of network resources can be improved, burst flow processing can be optimized, real-time service experience can be guaranteed, token waste can be avoided, and queue bandwidth allocation can be balanced.

Description

Technical Field

[0001] This application relates to the field of computer information processing, and more specifically, to a flow control method and apparatus based on dynamic queue weights and a global overflow bucket. Background Technology

[0002] With the rapid growth of cloud computing, video streaming, and IoT services, network devices need to simultaneously meet the requirements of high bandwidth utilization and low latency transmission in high-concurrency, multi-service environments. Traditional network traffic control methods typically employ Weighted Fair Queuing (WFQ) and Token Bucket algorithms for traffic scheduling and shaping, respectively, to achieve bandwidth allocation and burst control among services of different priorities. However, these traditional methods have significant limitations in complex service scenarios.

[0003] In existing WFQ scheduling mechanisms, the weights of each service queue are typically set fixed during the configuration phase and cannot be dynamically adjusted based on real-time queue status. When network load fluctuates or sudden traffic surges occur, fixed weights can lead to high-priority queues occupying bandwidth for extended periods, while low-priority queues experience continuous backlog, resulting in increased latency and uneven resource utilization. Furthermore, WFQ has high computational complexity, leading to significant performance overhead in high-speed port or multi-queue scenarios.

[0004] On the other hand, traditional token bucket algorithms typically maintain a local token bucket independently for each queue. When traffic surges, tokens in a single queue can easily run out, while remaining tokens in other queues cannot be shared, resulting in reduced bandwidth utilization. Although some improved solutions introduce an "overflow bucket" mechanism to temporarily store excess tokens, most are still limited to use within a single queue, lacking global allocation capabilities and unable to effectively cope with competition from sudden traffic surges across multiple services. Existing technologies struggle to achieve a balance between ensuring real-time performance, fairness, and resource utilization.

[0005] Therefore, a new flow control method and device based on dynamic queue weights and a global overflow bucket is needed.

[0006] The information disclosed in the background section is only intended to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0007] In view of this, this application provides a traffic control method and apparatus based on dynamic queue weights and a global overflow bucket. By dynamically generating queue weights based on real-time queue status and combining this with a globally shared overflow bucket to achieve cross-queue token allocation, more flexible and efficient traffic scheduling and burst control are achieved in multi-service concurrent scenarios. This reduces latency, minimizes packet loss, improves network resource utilization, optimizes burst traffic handling, ensures real-time service experience, avoids token waste, and balances queue bandwidth allocation.

[0008] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0009] According to one aspect of this application, a flow control method based on dynamic queue weights and a global overflow bucket is proposed. The method includes: allocating network packets to corresponding packet queues according to preset classification rules; dynamically generating a queue weight for each queue based on the real-time queue status of each queue; calculating the virtual completion time of each queue based on the queue weights; determining the target packet to be sent based on the virtual completion time; retrieving a token from the global overflow bucket when the number of tokens in the queue containing the target packet is insufficient; and sending the target packet based on the retrieved token.

[0010] In one exemplary embodiment of this application, allocating network packets to corresponding packet queues according to preset classification rules includes: extracting the five-tuple information of the network packets; determining a target category based on the five-tuple information and the preset classification rules; and allocating the network packets to corresponding packet queues according to the target category.

[0011] In one exemplary embodiment of this application, the queue weight of each queue is dynamically generated based on the real-time queue status of each queue, including: counting the real-time number of network packets in each queue; and dynamically generating the queue weight of each queue based on the real-time number.

[0012] In one exemplary embodiment of this application, dynamically generating the queue weight of each queue based on the real-time quantity includes: maintaining the queue weight at an initial value when the queue length is less than a first threshold; increasing the queue weight according to a preset gain coefficient when the queue length is greater than the first threshold and less than a second threshold; and setting the queue weight to the maximum weight when the queue length is greater than the second threshold.

[0013] In one exemplary embodiment of this application, calculating the virtual completion time of each queue based on the queue weights includes: calculating the sum of the queue weights of each queue; updating the queue weights of each queue according to the sum of the queue weights; and calculating the virtual completion time of each queue according to the queue weights.

[0014] In one exemplary embodiment of this application, updating the queue weight of each queue according to the queue weight includes: when the sum of the weights is greater than 1, the queue weight of each queue is maintained at the initial value; when the sum of the weights is less than or equal to 1, the queue weight of each queue is maintained at the current value.

[0015] In one exemplary embodiment of this application, when the number of tokens in the queue where the target message is located is insufficient, retrieving tokens from the global overflow bucket further includes: configuring a corresponding independent token bucket for each queue; and setting a global overflow bucket shared by all queues.

[0016] In one exemplary embodiment of this application, when the number of tokens in the queue where the target message is located is insufficient, retrieving tokens from the global overflow bucket includes: obtaining the remaining number of tokens in the local token bucket corresponding to the queue where the target message is located; obtaining the number of tokens required for the target message; and when the remaining number of tokens is less than the required number of tokens, retrieving tokens from the global overflow bucket based on the queue weight corresponding to the queue where the target message is located.

[0017] In one exemplary embodiment of this application, retrieving tokens from the global overflow bucket based on the queue weight corresponding to the queue where the target message is located includes: when the number of tokens in the global overflow token bucket is insufficient to meet the needs of all queues, redistributing the remaining tokens based on a weighted maximum minimum fair allocation strategy.

[0018] According to one aspect of this application, a flow control device based on dynamic queue weights and a global overflow bucket is proposed. The device includes: a classification module for allocating network packets to corresponding packet queues according to preset classification rules; a weighting module for dynamically generating a queue weight for each queue based on the real-time queue status; a time module for calculating the virtual completion time of each queue based on the queue weights; a target module for determining a target packet to be sent based on the virtual completion time; a retrieval module for retrieving a token from the global overflow bucket when the number of tokens in the queue containing the target packet is insufficient; and a sending module for sending the target packet based on the retrieved token.

[0019] According to one aspect of this application, an electronic device is provided, comprising: one or more processors; a storage device for storing one or more programs; and, when the one or more programs are executed by the one or more processors, causing the one or more processors to implement the method as described above.

[0020] According to one aspect of this application, a computer-readable medium is provided having a computer program stored thereon that, when executed by a processor, implements the method described above.

[0021] According to the flow control method and apparatus based on dynamic queue weights and a global overflow bucket of this application, network packets are allocated to corresponding packet queues according to preset classification rules; a queue weight for each queue is dynamically generated based on the real-time queue status of each queue; the virtual completion time of each queue is calculated based on the queue weight; the target packet to be sent is determined based on the virtual completion time; when the number of tokens in the queue where the target packet is located is insufficient, a token is retrieved from the global overflow bucket; and the target packet is sent based on the retrieved token. This method can reduce latency, reduce packet loss, improve network resource utilization, optimize burst traffic handling, ensure real-time service experience, avoid token waste, and balance queue bandwidth allocation.

[0022] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit this application. Attached Figure Description

[0023] The above and other objects, features, and advantages of this application will become more apparent from the detailed description of exemplary embodiments with reference to the accompanying drawings. The drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0024] Figure 1 This is a flowchart illustrating a flow control method based on dynamic queue weights and a global overflow bucket, according to an exemplary embodiment.

[0025] Figure 2 This is a schematic diagram illustrating a flow control method based on dynamic queue weights and a global overflow bucket, according to an exemplary embodiment.

[0026] Figure 3 This is a schematic diagram illustrating a flow control method based on dynamic queue weights and a global overflow bucket, according to another exemplary embodiment.

[0027] Figure 4 This is a flowchart illustrating a flow control method based on dynamic queue weights and a global overflow bucket, according to another exemplary embodiment.

[0028] Figure 5 This is a block diagram illustrating a flow control device based on dynamic queue weights and a global overflow bucket, according to an exemplary embodiment.

[0029] Figure 6 This is a block diagram illustrating an electronic device according to an exemplary embodiment.

[0030] Figure 7 This is a block diagram illustrating a computer-readable medium according to an exemplary embodiment. Detailed Implementation

[0031] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided so that this application will be thorough and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.

[0032] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0033] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0034] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0035] It should be understood that although the terms first, second, third, etc., may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one component from another. Therefore, the first component discussed below may be referred to as the second component without departing from the teachings of this application. As used herein, the term "and / or" includes all combinations of any one and more of the associated listed items.

[0036] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of exemplary embodiments, and the modules or processes in the drawings are not necessarily essential for implementing this application, and therefore cannot be used to limit the scope of protection of this application.

[0037] The technical abbreviations used in this application are explained as follows: Traffic classification and labeling: Identifying objects based on certain matching rules is a prerequisite for differentiated service implementation, and is usually applied to the inbound direction of the interface.

[0038] Congestion management is a necessary measure to resolve resource contention. It involves placing packets in a queue for buffering and using a scheduling algorithm to arrange the forwarding order of packets. It is usually applied to the outbound direction of the interface.

[0039] Congestion avoidance: Excessive congestion can damage network resources. Congestion avoidance monitors the usage of network resources and takes the initiative to drop packets when it detects that congestion is about to worsen. It relieves network overload by adjusting traffic and usually works on the outbound direction of the interface.

[0040] Traffic policing: This involves regulating the specifications of specific traffic entering a device, typically operating on the inbound side of the interface. When traffic exceeds these specifications, restrictions or penalties can be imposed to protect the operator's business interests and network resources from damage.

[0041] Traffic shaping: A flow control measure that actively adjusts the output rate of a flow to adapt the traffic to the network resources available to downstream devices, avoiding unnecessary packet dropping and congestion. It is usually applied to the outbound direction of an interface.

[0042] Weighted Max-Min Fair Allocation Algorithm: Assume the bandwidth limit in the network system is C = 10 Mbps, and there are four tasks with bandwidth requirements of [3, 3, 4, 5] Mbps, with weights of [1, 2, 1, 1]. Algorithm Flow: With a total weight W=5, the resources are divided into 4 parts according to their weights, namely [2,4,2,2]. These resources are then allocated to tasks sequentially. Task 1 requires 3, so it is allocated to task 2 and 0 is recycled. Task 2 requires 3, so it is allocated to task 4 and 1 is recycled, and so on. Tasks 1-4 have vacant resources [1, 0, 2, 3]. The recycled resource 1 is then re-allocated to tasks 1, 3, and 4 according to their weights. This process 1-3 is repeated until all resources are allocated or all task requirements are met.

[0043] Figure 1 This is a flowchart illustrating a flow control method based on dynamic queue weights and a global overflow bucket according to an exemplary embodiment. The flow control method 10 based on dynamic queue weights and a global overflow bucket includes at least steps S102 to S112.

[0044] like Figure 1 Steps and Figure 2 As shown in the schematic diagram, in S102, network packets are allocated to corresponding packet queues according to preset classification rules. For example, the five-tuple information of the network packet can be extracted; the target category can be determined based on the five-tuple information and the preset classification rules; and the network packet can be allocated to the corresponding packet queue according to the target category.

[0045] To implement differentiated services, data packets must first be categorized or assigned different priorities. Packet classification divides data packets into different categories, which can be achieved through flow classification in MQC configuration. Packet tagging assigns different priorities to data packets, which can be achieved through priority mapping and priority re-marking. Different packets use different QoS priorities; for example, VLAN packets use 802.1p, IP packets use DSCP, and MPLS packets use EXP.

[0046] In this embodiment of the application, network packets can be assigned to different packet queues according to priority or packet type.

[0047] In one embodiment, after a data packet enters the queue, the virtual completion time (SN) of each data packet can also be calculated; The current packet's SN = the previous packet's SN + (weight * current packet length). Weight = 32384 / (IP priority + 1) As can be seen from the formula, the higher the priority, the smaller the SN value; the smaller the data packet length, the smaller the SN value. In other words, high priority and small data packets are easier to forward.

[0048] In S104, the queue weight of each queue is dynamically generated based on the real-time queue status of each queue. For example, the real-time number of network packets in each queue can be counted; the queue weight of each queue can then be dynamically generated based on the real-time number.

[0049] For example, services can be categorized, grouping similar types of services into the same queue, and assigning weights based on the importance of each service. Different services have different initial weights for their respective queues. During forwarding and scheduling, the weights can be dynamically adjusted based on the number of data packets in each queue, making the scheduling and forwarding more scientific and flexible. The structural principle of the transmitted data packets is shown in the figure. First, they are classified according to their header information and assigned to the corresponding queues. Then, the number of data packets in each queue is updated, and the weights are adjusted based on the actual situation in each queue.

[0050] More specifically, when the queue length is less than the first threshold, the queue weight is kept at the initial value; when the queue length is greater than the first threshold and less than the second threshold, the queue weight is increased according to a preset gain coefficient; when the queue length is greater than the second threshold, the queue weight is set to the maximum weight.

[0051] If the number of data packets is less than the minimum threshold, the weight remains unchanged.

[0052] If the number of data packets is less than the maximum threshold but greater than the minimum threshold, it means that data packets have started to accumulate in the queue, and the weight should be increased appropriately.

[0053] The current number of packets is pkts. The size of this queue before the weight was modified was prev_wt. The initial weight of this queue was init_wt. The minimum threshold for the number of packets is min, and the maximum threshold for the number of packets is max. The weight wt of this queue is then adjusted according to the following formula (equivalent to the weight calculated by differentiating the maximum and minimum weights). If the number of data packets exceeds the maximum threshold, the weight will be adjusted to the maximum weight.

[0054] In S106, the virtual completion time of each queue is calculated based on the queue weights. For example, the sum of the queue weights of each queue can be calculated; the queue weight of each queue can be updated according to the sum of the queue weights; and the virtual completion time of each queue can be calculated according to the queue weights.

[0055] More specifically, when the sum of the weights is greater than 1, the queue weight of each queue remains at its initial value; when the sum of the weights is less than or equal to 1, the queue weight of each queue remains at its current value. The sum of the weights of each queue is calculated, and bandwidth allocation is performed based on the sum of the weights; if the sum of the weights is greater than 1, the initial weights are still used for allocation. If the sum of the weights is less than or equal to 1, bandwidth allocation is performed as usual according to the adjusted weights described above.

[0056] In S108, the target message to be sent is determined based on the virtual completion time. The packet with the shortest virtual completion time among all data packets can be selected for dequeueing and forwarding.

[0057] In S110, if the number of tokens in the queue where the target message is located is insufficient, tokens are retrieved from the global overflow bucket.

[0058] More specifically, for example, the remaining number of tokens in the local token bucket corresponding to the queue where the target message is located can be obtained; the number of tokens required by the target message can be obtained; when the remaining number of tokens is less than the required number of tokens, tokens can be retrieved from the global overflow bucket based on the queue weight corresponding to the queue where the target message is located.

[0059] More specifically, when the number of tokens in the global overflow token bucket is insufficient to meet the needs of all queues, the remaining tokens are redistributed based on a weighted maximum-minimum fair allocation strategy.

[0060] In S112, the target message is sent based on the retrieved token.

[0061] According to the flow control method based on dynamic queue weights and a global overflow bucket of this application, network packets are allocated to corresponding packet queues according to preset classification rules; a queue weight for each queue is dynamically generated based on the real-time queue status; the virtual completion time for each queue is calculated based on the queue weights; the target packet to be sent is determined based on the virtual completion time; when the number of tokens in the queue containing the target packet is insufficient, a token is retrieved from the global overflow bucket; and the target packet is sent based on the retrieved token. This method can reduce latency, reduce packet loss, improve network resource utilization, optimize burst traffic handling, ensure real-time service experience, avoid token waste, and balance queue bandwidth allocation.

[0062] It should be clearly understood that this application describes how specific examples are formed and used, but the principles of this application are not limited to any details of these examples. Rather, based on the teachings of the disclosure of this application, these principles can be applied to many other embodiments.

[0063] In one embodiment, each queue can be configured with its own independent token bucket, and a global overflow bucket shared by all queues can be set up. The global overflow bucket is as follows: Figure 3 As shown, the overflow bucket setting has been modified based on the original token bucket. Previously, each queue had its own token bucket and overflow bucket. Now, all queues share one overflow bucket. When each queue uses overflow bucket resources, it also takes them according to their weight. When the weight allocation cannot meet the needs of the queue, the weighted maximum-minimum fair allocation algorithm is used to allocate them until all overflow bucket resources are used up.

[0064] Figure 4 This is a flowchart illustrating a flow control method based on dynamic queue weights and a global overflow bucket, according to another exemplary embodiment. Figure 4 The process shown in step 40 is... Figure 1 The flowchart shows a detailed description of S110, "When the number of tokens in the queue where the target message is located is insufficient, retrieve tokens from the global overflow bucket".

[0065] like Figure 4 As shown, in S402, the current number of tokens in the token bucket is obtained. When a data packet passes through, the number of tokens remaining in the token bucket at the current moment is first obtained. In S404, retrieve the number of tokens required for the current token bucket. Retrieve the number of tokens that need to be withdrawn from this token bucket at the current moment.

[0066] In S406, is there enough tokens? Compare the number of tokens remaining in the token bucket with the number of tokens taken from the token bucket.

[0067] In S408, tokens are allocated on demand. If the number of remaining tokens is greater than the number of tokens to be retrieved from the token bucket, then there are enough tokens, and the token is forwarded directly. If the number of remaining tokens is less than the number of tokens to be retrieved from the token bucket, then there are not enough tokens, and tokens are retrieved from the overflow bucket.

[0068] In S410, the entropy weight method is used to calculate the weight of each token bucket. The weight of each token bucket is calculated, and the number of tokens that can be taken from the overflow bucket is calculated according to the weight.

[0069] In S412, the initial phase token allocation strategy is executed.

[0070] In S414, is there any surplus token in the overflow bucket? If the number of tokens in the overflow bucket is sufficient, and there are still tokens remaining after satisfying this bucket, then we check if there are any unsatisfactory situations in other token buckets, and redistribute the tokens according to the weighted fair allocation algorithm. The surplus tokens are moved to other needed token buckets according to their weights. The full max-min fair allocation algorithm is used, which is equivalent to distributing the remaining tokens in the overflow bucket according to the weight of each queue's token bucket, until there are no remaining tokens in the overflow bucket.

[0071] In S416, are there any unsatisfied token buckets?

[0072] In S418, the next stage token allocation strategy is executed. If there are still unsatisfied token buckets after allocation, the unsatisfied data packets from this round are cached and allocation continues in the next round.

[0073] In S420, tokens are assigned based on the policy outcome.

[0074] In S422, is there a next cycle?

[0075] In S424, the end.

[0076] The technical solution of this application is suitable for high network load environments (such as enterprise or data center networks) and large file downloads. For example, it can guarantee a certain level of latency even when many short requests (such as web page requests, API calls, etc.) and a few large streams (such as video streams, file downloads, etc.) coexist simultaneously. Under high load conditions, when all queues have reached their maximum processing peak, a sudden surge in traffic can cause packet backlog. If the weight of the backlogged queues is relatively low, it will result in significant latency. This method can handle the backlogged packets... This application also addresses the issue of poor response to large bursts of traffic in traditional token buckets, demonstrating superior performance in applications requiring immediate response (such as real-time video and online games). It fully utilizes the resources in the overflow bucket, improving the responsiveness to bursts of traffic.

[0077] Those skilled in the art will understand that all or part of the steps of the above embodiments are implemented as a computer program executed by a CPU. When the computer program is executed by the CPU, it performs the functions defined by the method provided in this application. The program can be stored in a computer-readable storage medium, such as a read-only memory, a magnetic disk, or an optical disk.

[0078] Furthermore, it should be noted that the above figures are merely illustrative representations of the processes included in the method according to exemplary embodiments of this application, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0079] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0080] Figure 5 This is a block diagram illustrating a flow control device based on dynamic queue weights and a global overflow bucket, according to an exemplary embodiment. Figure 5 As shown, the flow control device 50 based on dynamic queue weights and a global overflow bucket includes: a classification module 502, a weighting module 504, a time module 506, a target module 508, a retrieval module 510, and a sending module 512.

[0081] The classification module 502 is used to allocate network packets to the corresponding packet queues according to preset classification rules; the classification module 502 is also used to extract the five-tuple information of the network packets; determine the target category according to the five-tuple information and the preset classification rules; and allocate the network packets to the corresponding packet queues according to the target category.

[0082] The weight module 504 is used to dynamically generate the queue weight of each queue based on the real-time queue status of each queue; the weight module 504 is also used to count the real-time number of network packets in each queue; and to dynamically generate the queue weight of each queue based on the real-time number.

[0083] The time module 506 is used to calculate the virtual completion time of each queue based on the queue weight; the time module 506 is also used to calculate the sum of the queue weights of each queue; update the queue weight of each queue according to the sum of the queue weights; and calculate the virtual completion time of each queue according to the queue weights.

[0084] The target module 508 is used to determine the target message to be sent based on the virtual completion time; The retrieval module 510 is used to retrieve tokens from the global overflow bucket when the number of tokens in the queue where the target message is located is insufficient; the retrieval module 510 is also used to obtain the remaining number of tokens in the local token bucket corresponding to the queue where the target message is located; obtain the number of tokens required for the target message; when the remaining number of tokens is less than the required number of tokens, retrieve tokens from the global overflow bucket based on the queue weight corresponding to the queue where the target message is located.

[0085] The sending module 512 is used to send the target message based on the retrieved token.

[0086] According to the flow control device based on dynamic queue weights and a global overflow bucket of this application, network packets are allocated to corresponding packet queues according to preset classification rules; a queue weight for each queue is dynamically generated based on the real-time queue status of each queue; the virtual completion time of each queue is calculated based on the queue weights; the target packet to be sent is determined based on the virtual completion time; when the number of tokens in the queue where the target packet is located is insufficient, a token is retrieved from the global overflow bucket; and the target packet is sent based on the retrieved token. This method can reduce latency, reduce packet loss, improve network resource utilization, optimize burst traffic handling, ensure real-time service experience, avoid token waste, and balance queue bandwidth allocation.

[0087] Figure 6 This is a block diagram illustrating an electronic device according to an exemplary embodiment.

[0088] The following reference Figure 6 To describe an electronic device 600 according to this embodiment of the present application. Figure 6 The electronic device 600 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0089] like Figure 6 As shown, the electronic device 600 is presented in the form of a general-purpose computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different system components (including storage unit 620 and processing unit 610), a display unit 640, etc.

[0090] The storage unit stores program code that can be executed by the processing unit 610, causing the processing unit 610 to perform the steps described in this specification according to various exemplary embodiments of this application. For example, the processing unit 610 can perform actions such as... Figure 1 , Figure 4 The steps are shown in the figure.

[0091] The storage unit 620 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 6201 and / or a cache storage unit 6202, and may further include a read-only memory unit (ROM) 6203.

[0092] The storage unit 620 may also include a program / utility 6204 having a set (at least one) program module 6205, such program module 6205 including but not limited to: an operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0093] Bus 630 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0094] Electronic device 600 can also communicate with one or more external devices 600' (e.g., keyboard, pointing device, Bluetooth device, etc.), enabling users to communicate with devices that interact with electronic device 600, and / or any device that allows electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 650. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 660. Network adapter 660 can communicate with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0095] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software, or by combining software with necessary hardware. Therefore, as... Figure 7 As shown, the technical solution according to the embodiments of this application can be embodied in the form of a software product. The software product can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, mobile hard drive, etc.) or on a network, and includes several instructions to cause a computing device (such as a personal computer, server, or network device, etc.) to execute the above-described method according to the embodiments of this application.

[0096] The software product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0097] The computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The readable storage medium may also be any readable medium other than a readable storage medium, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0098] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0099] The aforementioned computer-readable medium carries one or more programs. When these programs are executed by a device, the computer-readable medium performs the following functions: allocating network packets to corresponding packet queues according to preset classification rules; dynamically generating queue weights for each queue based on the real-time queue status; calculating the virtual completion time for each queue based on the queue weights; determining the target packet to be sent based on the virtual completion time; retrieving tokens from a global overflow bucket when the number of tokens in the queue containing the target packet is insufficient; and sending the target packet based on the retrieved tokens.

[0100] Those skilled in the art will understand that the above modules can be distributed in the device as described in the embodiments, or they can be modified accordingly and located in one or more devices that are unique to this embodiment. The modules in the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0101] Through the description of the above embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the methods according to the embodiments of this application.

[0102] Exemplary embodiments of this application have been specifically shown and described above. It should be understood that this application is not limited to the detailed structures, arrangements, or implementation methods described herein; rather, this application is intended to cover various modifications and equivalent arrangements contained within the spirit and scope of the appended claims.

Claims

1. A flow control method based on dynamic queue weights and a global overflow bucket, characterized in that, The method comprises the following steps: allocating network packets to corresponding packet queues according to preset classification rules; dynamically generating a queue weight of each queue according to real-time queue states of the queues; calculating a virtual completion time of each queue based on the queue weight; determining a target packet to be sent according to the virtual completion time; when the number of tokens in the queue where the target packet is located is insufficient, tokens are retrieved from a global overflow bucket; sending the target packet based on the retrieved tokens.

2. The method of claim 1, wherein, The step of allocating network packets to corresponding packet queues according to preset classification rules comprises the following steps: extracting five-tuple information of the network packets; determining a target category according to the five-tuple information and the preset classification rules; allocating the network packets to corresponding packet queues according to the target category.

3. The method of claim 1, wherein, The step of dynamically generating a queue weight of each queue according to real-time queue states of the queues comprises the following steps: counting real-time numbers of network packet packages in the queues; dynamically generating the queue weight of each queue according to the real-time numbers.

4. The method of claim 3, wherein, The step of dynamically generating the queue weight of each queue according to the real-time numbers comprises the following steps: when the queue length is less than a first threshold value, maintaining the queue weight at an initial value; when the queue length is greater than the first threshold value and less than a second threshold value, increasing the queue weight according to a preset gain coefficient; when the queue length is greater than the second threshold value, setting the queue weight as a maximum weight value.

5. The method of claim 1, wherein, The step of calculating a virtual completion time of each queue based on the queue weight comprises the following steps: calculating a queue weight sum of the queues; updating the queue weight of each queue according to the queue weight sum; calculating the virtual completion time of each queue according to the queue weight.

6. The method of claim 5, wherein, The step of updating the queue weight of each queue according to the queue weight sum comprises the following steps: when the weight sum is greater than 1, maintaining the queue weight of each queue at an initial value; when the weight sum is less than or equal to 1, maintaining the queue weight of each queue at a current value.

7. The method of claim 1, wherein, The step of retrieving tokens from a global overflow bucket when the number of tokens in the queue where the target packet is located is insufficient further comprises the following steps: configuring a corresponding independent token bucket for each queue; setting a global overflow bucket shared by all the queues.

8. The method of claim 1, wherein, The step of retrieving tokens from a global overflow bucket when the number of tokens in the queue where the target packet is located is insufficient comprises the following steps: obtaining a remaining token number of a local token bucket corresponding to the queue where the target packet is located; obtaining a required token number of the target packet; when the remaining token number is less than the required token number, retrieving tokens from the global overflow bucket based on the queue weight corresponding to the queue where the target packet is located.

9. The method of claim 8, wherein, The step of retrieving tokens from the global overflow bucket based on the queue weight corresponding to the queue where the target packet is located comprises the following steps: when the number of tokens in the global overflow token bucket is insufficient to meet the requirements of all the queues, re-distributing the remaining tokens based on a weighted maximum minimum fair allocation strategy.

10. A flow control apparatus based on dynamic queue weights and global spill buckets, comprising: The method comprises the following steps: a classification module, configured to allocate network packets to corresponding packet queues according to preset classification rules; a weight module, configured to dynamically generate a queue weight of each queue according to real-time queue states of the queues; a time module, configured to calculate a virtual completion time of each queue based on the queue weight. a target module, configured to determine a target packet to be sent according to the virtual completion time; a calling module, configured to call tokens from a global overflow bucket when the number of tokens in the queue where the target packet is located is insufficient; a sending module, configured to send the target packet based on the called tokens.

Images