A Linux-based intelligent dynamic network bandwidth allocation method

Abstract

The application provides a Linux-based intelligent dynamic network bandwidth allocation method, and belongs to the technical field of computers, and comprises the following steps: step S1, constructing a closed-loop dynamic regulation system; step S2, obtaining current running network data of an application; step S3, when no new application is opened in the foreground, the system maintains a steady-state observation window state; when a new application is opened, the system maintains a fast response window state to collect new state traffic, and judges whether a racing condition occurs in the foreground application; step S4, if the racing condition does not occur, network traffic is maintained at the highest value required by the current application, and if it is judged that the racing condition occurs, the next step is entered; step S5, triggering an intelligent suppression state machine to limit the network rate of the background application until the foreground application can stably run; and step S6, when the foreground application continuously and stably runs within a predetermined time, the network rate of the background application is restored in a probe mode. The method of the application guarantees the foreground experience and eliminates bandwidth waste.

Description

Technical Field

[0001] This invention relates to a network bandwidth allocation method, and more particularly to an intelligent dynamic network bandwidth allocation method based on Linux, belonging to the field of computer technology. Background Technology

[0002] In Linux desktop operating systems, the disorderly competition for network bandwidth remains a core pain point affecting user experience in scenarios with multiple applications and concurrent network transmission. Traditional flow control technologies mainly rely on the following two solutions:

[0003] 1. Static QoS Priority Queues: Fixed priority rules are configured via the `tc` command, mapping traffic from different ports to different priority queues. This technology uses the HTB as the root queue, working in conjunction with a classifier to achieve basic traffic isolation.

[0004] 2. cgroup network priority: Using the net_prio subsystem of cgroup, packet priority fields are set for different process groups, which, together with the mqprio queue scheduler, enables traffic classification.

[0005] The aforementioned existing technical solutions have the following disadvantages:

[0006] Unregulated and unreliable bandwidth contention: Background download applications (such as cloud storage and BitTorrent) often consume available bandwidth without restraint, causing lag in foreground interactive applications (video conferencing, collaborative desktops). Traditional priority systems only control relative scheduling order; when total bandwidth reaches physical bottlenecks, high-priority queues will still experience packet loss due to congestion, and the foreground bandwidth guarantee rate is often less than 60%.

[0007] Static configurations are rigid, making process identification difficult: Existing tc combined with iptables filtering rules are mostly based on static IPs and ports. In desktop environments, application ports are dynamically allocated and frequently started and stopped. Static rules cannot automatically detect the switching of desktop focus windows, resulting in cumbersome configuration and a high likelihood of failure.

[0008] The lack of real-demand learning capabilities leads to significant resource waste: Current technologies cannot automatically learn the actual burst bandwidth demands of foreground applications. For example, playing 4K video may only require 25Mbps, but static rules often conservatively reserve 50Mbps, resulting in over 40% bandwidth waste, or insufficient reservation causing stuttering. Summary of the Invention

[0009] To address the aforementioned issues, this invention provides a Linux-based intelligent dynamic network bandwidth allocation method to ensure a smooth user experience and eliminate bandwidth waste.

[0010] To achieve the above objectives, the technical solution of the present invention is: a Linux-based intelligent dynamic network bandwidth allocation method, comprising the following steps:

[0011] Step S1: Construct a closed-loop dynamic control system, which includes a control plane and a data plane. The control plane consists of user-mode daemons, and the data plane includes kernel-mode cgroup v2, eBPF, and TC HTB.

[0012] Step S2: Obtain the network data of the application currently running based on the data plane and execute the bandwidth dynamic monitoring algorithm: including obtaining the current application's V_eth, V_capacity, V_i(t) and the background V_actual_bg;

[0013] Step S3: When no new application is opened in the foreground, the system maintains the steady-state observation window state; when a new application is opened, the system maintains the fast response window state to collect new state traffic, calculates the actual stability requirements of the application, and then obtains the coefficient of variation (CV) through V_i(t), performs stability judgment based on the coefficient of variation (CV), and combines V_capacity to determine whether the foreground application is experiencing a race condition.

[0014] Step S4: If no speed-racing occurs, the network traffic will be maintained at the highest value required by the current application; if a speed-racing is detected, proceed to the next step.

[0015] Step S5: Trigger the intelligent suppression state machine, and limit the network rate of the background application by adjusting the background V_actual_bg until the foreground application can run stably;

[0016] Step S6: When the background application continues to run stably for a predetermined period of time, the network rate of the background application is restored by adjusting the background V_actual_bg.

[0017] Furthermore, in step S1, cgroup v2 is used to naturally group all main processes and child threads generated by the same desktop application into the same control group directory; the eBPF program of type BPF_PROG_TYPE_CGROUP_SKB is mounted at the cgroup entry and exit point; TC HTB is used to implement the limitation of network bandwidth rate of background applications; and the user-mode daemon is used to obtain the network data of the application currently running and write it to the shared eBPF Map.

[0018] Furthermore, in step S2,

[0019] V_eth is obtained by reading the kernel's / sys / class / net / interface name / speed and is used to assess whether the hardware can support the network bandwidth usage of all applications.

[0020] V_capacity is the actual outbound capacity. The system monitors the total network card aggregate throughput through a long-term sliding window of 300 seconds. If the measured peak value is continuously lower than 50% of V_eth, it is determined that there is an external ISP bottleneck, and the actual capacity is set as: V_capacity = peak rate x 1.10.

[0021] V_i(t) is obtained by reading the byte increment of application i from the eBPF Map every 2 seconds and dividing by 2 seconds;

[0022] V_actual_bg is the measured rate of the background application when it is in a stable state, as recorded by the system before the foreground application is switched.

[0023] Furthermore, in step S3, the steady-state observation window automatically enters when the foreground application does not switch UIs, and is used to absorb TCP sawtooth fluctuations; the fast response window is triggered when the user opens a new application or switches focus, and is used to quickly collect new state traffic; the application's actual stability requirements are calculated as follows: collect all rate samples within the window, sort them in ascending order, and directly extract the P95 value as V_predict.

[0024] Furthermore, in step S3, CV = sequence standard deviation / sequence mean;

[0025] If CV >= 0.15, it is determined to be "unstable state", indicating that the front end is experiencing congestion or is in a large-scale buffer. At this time, the intelligent suppression state machine is activated.

[0026] If CV < 0.15, it is determined to be in a "stable state", indicating that the foreground has obtained sufficient bandwidth. At this time, suppression can be suspended, and after the conditions are met, it will switch to the gradual recovery state machine.

[0027] Furthermore, step S5 specifically includes the following steps:

[0028] All cgroups are sorted according to a multi-level priority model. When the highest priority application in the foreground is in an "unstable state" and the total bandwidth is approaching V_capacity, suppression is strictly implemented according to the following timing steps:

[0029] Step 1, First Stage Strong Suppression of 10%: Lock the lowest priority background application with the highest current throughput and drastically reduce its rate limiting threshold in the TC layer to 10% of its historical stable rate V_actual_bg;

[0030] Step 2, Observation and Second-Stage Suppression of 5%: After suppression, wait for a 10-second observation period and recalculate the front-end CV. If the front-end CV is still >= 0.15, it indicates that the concession is insufficient. Further compress the rate limiting threshold of the background application to 5% of its historical stable rate.

[0031] Step 3, Priority Cascade Deprivation: If the foreground application remains unstable after a single background application is pushed down to 5%, then search upwards for the next lowest priority set of applications and repeat steps 1 and 2 until the foreground CV drops below 0.15.

[0032] The multi-level priority model is: manual specification > UI focus state > application business type.

[0033] Furthermore, step S6 includes the following steps:

[0034] If the foreground application is in a steady-state window, its CV value is strictly < 0.15 in two consecutive calculations, and the current total system allocation has a safety margin of at least 10% from V_capacity, then perform the following steps:

[0035] Step 1, fixed-step release: Increase the threshold of the highest priority suppressed background application by a fixed step size Delta_rho, typically 5% to 15% of V_actual_bg;

[0036] Step 2, Perturbation Verification: After release, a 5-second verification period begins. If the front-end CV remains < 0.15 and throughput does not drop, the recovery is accepted and the next release is prepared.

[0037] Step 3, Emergency Rollback: If the front-end CV spikes to >= 0.15, indicating that the dark bandwidth ceiling has been reached, immediately roll back the back-end threshold to the safe value of the previous step and lock it.

[0038] The beneficial effects of the Linux-based intelligent dynamic network bandwidth allocation method of the present invention are as follows:

[0039] 1. Completely solve the problem of process identity drift and achieve zero system configuration: Compared with the traditional iptables rules that rely on manually setting static ports and IPs, this invention introduces cgroup v2, which realizes natural isolation and tracking at the application level. When users start or close any unknown port program, the system can adaptively sense and perform control without any manual intervention.

[0040] 2. Precise supply and demand matching, eliminating bandwidth waste and lag: Unlike traditional technologies that use crude arithmetic averages, this invention uses the P95 quantile algorithm to extract features from traffic, perfectly absorbing the inherent burstiness of the TCP protocol, ensuring that the bandwidth allocated to foreground applications is neither wasted nor 100% covered by sudden demand.

[0041] 3. Guaranteed front-end experience and significantly improved link utilization: Unlike simple QoS priority scheduling, which can still lead to overall packet loss during congestion, this invention's "intelligent suppression state machine" clears the hardware queue for the front-end through a 10% cliff-like proactive yield, achieving a front-end bandwidth guarantee rate exceeding 98%. Subsequently, the "progressive recovery algorithm," verified in real-time by CV values, fully utilizes the system's previously idle "hidden bandwidth" without sacrificing the front-end experience, resulting in a substantial 30% to 50% increase in total system throughput under multi-application concurrent environments.

[0042] 4. Extremely low system overhead: By introducing eBPF and per-CPU array mechanism in the data plane, the traditional bypass packet capture path of sending data packets from kernel mode to user mode for analysis is avoided, lock contention and context switching are eliminated, and full-port line-rate traffic monitoring and scheduling can be achieved with extremely low CPU resource consumption. Detailed Implementation

[0043] The technical solutions in the embodiments of the present invention will be clearly and completely described below. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Those skilled in the art can make similar extensions without departing from the spirit of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0044] Definitions of abbreviations and key terms:

[0045] cgroup v2: Linux Control Groups version 2, used to restrict, record, and isolate the resource usage of process groups in a hierarchical tree structure.

[0046] eBPF: Extended Berkeley Packet Filter, a secure programmable execution environment in the Linux kernel.

[0047] TC: Traffic Control, the Linux kernel network packet scheduling subsystem.

[0048] HTB: Hierarchical Token Bucket, a queue scheduling algorithm that supports absolute bandwidth borrowing and limiting.

[0049] CV: Coefficient of Variation, the ratio of standard deviation to mean, used to quantify the dispersion of dimensionless data.

[0050] P95: 95th Percentile, a data point in a statistical distribution that is greater than or equal to 95% of the observed values.

[0051] The present invention provides a Linux-based intelligent dynamic network bandwidth allocation method to overcome the shortcomings of existing technologies, such as static and rigid bandwidth allocation, inability to adapt to changes in desktop focus applications, and lack of precise process-level control. The method achieves the following:

[0052] 1. Automatic learning: Based on mathematical models, it learns the actual bandwidth requirements of front-end applications in real time, with a demand prediction accuracy of over 95%.

[0053] 2. Intelligent suppression: When network speed competition occurs, the stable state is accurately quantified, and high-speed background applications are suppressed dynamically and in a graded manner to ensure that the bandwidth guarantee rate of the foreground is > 98%.

[0054] 3. Gradual recovery: After the foreground application reaches a steady state, the background bandwidth is gradually restored using a probe-like approach with safe step sizes, increasing the total system throughput by 30%-50%.

[0055] 4. Zero-configuration kernel acceleration: Deeply integrates cgroup v2 and eBPF technologies to achieve application-level lock-free traffic management without manual intervention.

[0056] Example 1

[0057] The overall concept of the Linux-based intelligent dynamic network bandwidth allocation method of the present invention is introduced in this embodiment as follows:

[0058] The method of this invention abandons the original static network configuration and constructs a closed-loop dynamic control system consisting of a control plane (user-space daemons) and a data plane (kernel-space cgroup v2 + eBPF + TC HTB). Specifically:

[0059] I. Solving the problems of disconnect and overhead of existing technologies through underlying converged architecture

[0060] 1. Process identification and grouping: By using cgroup v2 to unify the hierarchical structure, all main processes and child threads generated by the same desktop application are naturally grouped into the same control group directory, completely eliminating the dependence on dynamic ports.

[0061] 2. Microsecond-level lock-free monitoring: An eBPF program of type BPF_PROG_TYPE_CGROUP_SKB is mounted at the entry and exit points of a cgroup. The program directly extracts the byte length from the data packet (sk_buff) and accumulates it into the eBPF Map (a per-CPU array structure). This avoids any system calls and spinlocks, achieving real-time rate statistics with extremely low overhead.

[0062] 3. Action Execution Feedback: After calculating the rate limiting threshold, the user-space daemon writes it into the shared eBPF Map. The eBPF classifier mounted on the TC layer reads this Map and dynamically modifies the rate limiting parameters of the HTB queue or directly executes packet loss (TC_ACT_SHOT), thus forming a control closed loop.

[0063] II. The method of this invention is designed with the following core network parameter acquisition and definition to solve the problem of fuzzy computational logic.

[0064] The algorithm of this invention operates based on the following precisely calculated parameters:

[0065] 1. V_eth (Physical Negotiation Rate): Obtained by reading kernel / sys / class / net / NIC name / speed; specifically refers to the network interface support, which is a hardware constraint, meaning a theoretical bottleneck, used to assess whether the network bandwidth usage of all applications can be supported.

[0066] 2. V_capacity (Actual Egress Capacity): The system monitors the total network interface card aggregate throughput through a long-term sliding window of 300 seconds. If the measured peak value is continuously lower than 50% of V_eth, it is determined that there is an external ISP bottleneck, and the actual capacity is set as: V_capacity = peak rate x 1.10 (10% is reserved for absorbing TCP probes).

[0067] 3. V_i(t) (current instantaneous rate of application): The increment of bytes of application i is read from the eBPF Map every 2 seconds and divided by 2 seconds; application i includes all applications in the system, including foreground applications and background applications. V_i(t) is used for the subsequent calculation of V_predict.

[0068] 4. V_actual_bg (Background Historical Stable Rate): The measured rate of the background application when it is in a stable state, as recorded by the system before the foreground application is switched.

[0069] III. Solving the problem of fuzzy statistical objects in learning algorithms by using a dual-mode sliding window and the P95 demand forecasting algorithm.

[0070] Instead of taking a simple average of instantaneous traffic, the system maintains a sliding window with two states to calculate the actual demand of the foreground application (V_predict, which represents the bandwidth throughput required by the current application and is used to determine whether the bandwidth obtained by the current application meets its expected needs):

[0071] 1. Quick Response Window (10 seconds / 5 samples): Triggered when a user opens a new application or switches focus, used to quickly collect new state traffic.

[0072] 2. Steady-state observation window (60 seconds / 30 samples): Automatically enters when the foreground application does not switch UI, used to absorb TCP sawtooth fluctuations.

[0073] 3. Calculation Method: Collect all rate samples within the window, sort them in ascending order, and directly extract the 95th percentile (P95) value as V_predict. This method can effectively eliminate the top 5% of abnormal TCP handshake spikes, accurately identifying the application's true stability requirements.

[0074] IV. A stability determination method based on the coefficient of variation (CV) is adopted to solve the problem of quantitative indicators for scene switching.

[0075] To determine whether the foreground application is being squeezed by background downloads (i.e., whether malicious speed-running is occurring), the system calculates the coefficient of variation (CV = standard deviation of the sequence / mean of the sequence) of the rate sequence within the sliding window. The system sets a strict threshold: CV < 0.15; where the standard deviation and mean of the sequence refer to the standard deviation and mean of the rate sequence within the sliding window mentioned above.

[0076] 1. If CV >= 0.15, it is judged as "unstable state", indicating that the foreground is encountering congestion or is in a large-scale buffer. At this time, the [Intelligent Suppression State Machine] must be started.

[0077] 2. If CV < 0.15, it is determined to be in a "stable state", indicating that the foreground has obtained sufficient bandwidth. At this time, suppression can be suspended, and after the conditions are met, it will switch to the [asymptotic recovery state machine].

[0078] Fifth, a multi-level priority system and a background intelligent suppression state machine are adopted to solve the problem of lack of causality and steps in the suppression process.

[0079] A multi-level priority model (manually specified > UI focus state > application business type) sorts all cgroups. When the foreground top application (highest priority) is in an "unstable state" (CV >= 0.15) and the total bandwidth approaches V_capacity, suppression is strictly implemented according to the following timing steps:

[0080] Step 1 (First Phase Strong Suppression 10%): Lock the lowest priority background application with the highest current throughput and drastically reduce its rate limiting threshold in the TC layer to 10% of its historical stable rate V_actual_bg. The goal is to forcibly clear the hardware router congestion queue within microseconds.

[0081] Step 2 (Observation and Second-Stage Suppression of 5%): After suppression, wait for a 10-second observation period and recalculate the front-end CV. If the front-end CV is still >= 0.15, it indicates insufficient concession, and the rate limiting threshold of the background application is further compressed to 5% of its historical stable rate.

[0082] Step 3 (Priority Cascade Deprivation): If the foreground application remains unstable after a single background application is pushed down to 5%, then search upwards for the next lowest priority application set and repeat steps 1 and 2 until the foreground CV drops below 0.15.

[0083] VI. A progressive probe recovery algorithm is adopted to solve the problems of recovery triggering conditions and quantization execution.

[0084] The recovery algorithm and the suppression algorithm never run simultaneously; rather, the recovery algorithm is the next stage after successful suppression. Triggering conditions: The foreground application is in a steady-state window, its CV value is strictly < 0.15 in two consecutive calculations, and the current total system allocation has a safety margin of at least 10% from V_capacity.

[0085] Step 1 (Fixed step release): Increase the threshold of the highest priority suppressed background application by a fixed step Delta_rho (usually 5% to 15% of V_actual_bg).

[0086] Step 2 (Perturbation Verification): After release, a 5-second verification period begins. If the front-end CV remains < 0.15 and throughput does not drop, the recovery is accepted and preparations are made for the next release.

[0087] Step 3 (Emergency Rollback): If the front-end CV spikes to >= 0.15, it is determined that the dark bandwidth ceiling has been reached. Immediately roll back the back-end threshold to the safe value of the previous step and lock it.

[0088] Based on the above ideas, this invention provides a Linux-based intelligent dynamic network bandwidth allocation method, comprising the following steps:

[0089] Step S1: Construct a closed-loop dynamic control system, including a control plane and a data plane. The control plane consists of user-mode daemons, and the data plane includes kernel-mode cgroup v2, eBPF, and TC HTB. Using the unified hierarchical structure of cgroup v2, all main processes and child threads generated by the same desktop application are naturally grouped into the same control group directory. eBPF programs of type BPF_PROG_TYPE_CGROUP_SKB are mounted at the cgroup entry and exit points, allowing the program to directly extract byte lengths from data packets (sk_buff) and accumulate them into the eBPF Map (a per-CPU array structure). TC HTB is used to limit the network bandwidth rate of background applications. The user-mode daemons are used to obtain the network data currently running in the application and write it to the shared eBPF Map.

[0090] Step S2: Obtain the network data of the application currently running based on the data plane and execute the bandwidth dynamic monitoring algorithm: including obtaining the current application's V_eth, V_capacity, V_i(t) and the background V_actual_bg;

[0091] Step S3: When no new application is opened in the foreground, the system maintains the steady-state observation window state; when a new application is opened, the system maintains the fast response window state to collect new state traffic, calculates the actual stability requirements of the application, and then obtains the coefficient of variation (CV) through V_i(t), performs stability judgment based on the coefficient of variation (CV), and combines V_capacity to determine whether the foreground application is experiencing a race condition.

[0092] Step S4: If no speed-racing occurs, the network traffic will be maintained at the highest value required by the current application; if a speed-racing is detected, proceed to the next step.

[0093] Step S5: Trigger the intelligent suppression state machine, and limit the network rate of the background application by adjusting the background V_actual_bg until the foreground application can run stably;

[0094] Step S6: When the background application continues to run stably for a predetermined period of time, the network rate of the background application is restored by adjusting the background V_actual_bg.

[0095] Example 2

[0096] Based on Example 1, this example describes the method of the present invention in detail based on the specific application scenario of "desktop online high-definition video playback (foreground) + continuous download from Baidu Cloud (background)". The specific execution flow is as follows:

[0097] I. Baseline period (0-10 seconds):

[0098] 1. The user only runs Baidu Cloud downloads in the background, and the total demand of the entire operating system is close to the detected physical capacity (e.g., 10Mbps), so the cloud drive runs smoothly. The closed-loop dynamic control system (hereinafter, "system" refers to the closed-loop dynamic control system of this invention) records the historical stable rate of the cloud drive, V_actual_bg = 10Mbps. This historical stable rate is continuously collected by the data plane of the closed-loop dynamic control system of this invention.

[0099] II. Learning and Strong Inhibition Phase (10-20 seconds):

[0100] 1. When a user opens a new browser, it acts as the foreground application to play high-definition videos.

[0101] 2. The foreground browser begins to compete for bandwidth, entering a 10-second fast response window. Due to insufficient bandwidth, the browser experiences severe TCP packet loss. At this point, the system calculates its rate of variation coefficient (CV) to be 0.42 (>= 0.15, unstable).

[0102] 3. The system immediately triggers the suppression state machine (step 1), and notifies TC HTB through eBPF Map to forcibly limit the network disk speed to 10% of 10Mbps (i.e., 1Mbps).

[0103] 4. After freeing up space, the browser quickly obtains bandwidth, and the throughput reaches 8.5Mbps (i.e., the V_predict value).

[0104] III. Stability determination period (20-80 seconds):

[0105] 1. The browser enters a 60-second steady-state observation window. The system collects the rate every 2 seconds and calculates the P95 predicted demand as 8.8 Mbps (i.e., the V_predict value), while also calculating its CV = 0.08 (< 0.15). The system determines that the foreground video playback is completely stable.

[0106] IV. Gradual recovery period (after 80 seconds):

[0107] 1. If the recovery conditions are met, the system triggers probe-based recovery. The step size is set to 10% (i.e., 1 Mbps).

[0108] 2. First restoration: The cloud drive speed limit was increased from 1Mbps to 2Mbps. A 5-second micro-disturbance verification showed the foreground video CV was still 0.09, indicating verification passed.

[0109] 3. Second recovery: The cloud storage speed limit was attempted to be increased to 3Mbps. It was found that this caused a sudden drop in foreground video throughput, and the CV rose to 0.18.

[0110] 4. Emergency rollback: When the system determines that the physical limit has been reached, it immediately rolls back the network drive speed limit and locks it safely at 2Mbps to optimize the overall link throughput.

[0111] Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

Claims

1. A Linux-based intelligent dynamic network bandwidth allocation method, characterized in that, Includes the following steps: Step S1: Construct a closed-loop dynamic control system, which includes a control plane and a data plane. The control plane consists of user-mode daemons, and the data plane includes kernel-mode cgroup v2, eBPF, and TC HTB. Step S2: Obtain the network data of the application currently running based on the data plane and execute the bandwidth dynamic monitoring algorithm: including obtaining the current application's V_eth, V_capacity, V_i(t) and the background V_actual_bg; Step S3: When no new application is opened in the foreground, the system maintains the steady-state observation window state; when a new application is opened, the system maintains the fast response window state to collect new state traffic, calculates the actual stability requirements of the application, and then obtains the coefficient of variation (CV) through V_i(t), performs stability judgment based on the coefficient of variation (CV), and combines V_capacity to determine whether the foreground application is experiencing a race condition. Step S4: If no speed-racing occurs, the network traffic will be maintained at the highest value required by the current application; if a speed-racing is detected, proceed to the next step. Step S5: Trigger the intelligent suppression state machine, and limit the network rate of the background application by adjusting the background V_actual_bg until the foreground application can run stably; Step S6: When the background application continues to run stably for a predetermined time, the network rate of the background application is restored by adjusting the background V_actual_bg. In step S2, V_eth is the physical negotiated speed, which is obtained by reading the kernel / sys / class / net / interface name / speed. It is used to assess whether the hardware can support the network bandwidth usage of all applications. V_capacity is the actual outbound capacity. The system monitors the total network card aggregate throughput through a long-term sliding window of 300 seconds. If the measured peak value is continuously lower than 50% of V_eth, it is determined that there is an external ISP bottleneck, and the actual capacity is set as: V_capacity = peak rate x 1.

10. V_i(t) is the current instantaneous rate of the application, which is obtained by reading the byte increment of application i from the eBPF Map every 2 seconds and dividing by 2 seconds; V_actual_bg is the historical stable background rate, which is the rate measured by the system when the background application is in a stable state before the foreground application is switched. In step S3, the steady-state observation window automatically enters when the foreground application does not switch UIs, and is used to absorb TCP sawtooth fluctuations; the fast response window is triggered when the user opens a new application or switches focus, and is used to collect new state traffic; the application's actual stability requirements are calculated as follows: collect all rate samples within the window, sort them in ascending order, and directly extract the value of P95 as V_predict.

2. The method according to claim 1, characterized in that, In step S1, cgroup v2 is used to naturally group all main processes and child threads generated by the same desktop application into the same control group directory; eBPF programs of type BPF_PROG_TYPE_CGROUP_SKB are mounted at the cgroup entry and exit points; TC HTB is used to limit the network bandwidth rate of background applications; the user-mode daemon's role includes obtaining the network data of the application currently running and writing it to the shared eBPF Map.

3. The method according to claim 1, characterized in that, In step S3, CV = sequence standard deviation / sequence mean, where the sequence refers to the dataset of rates within the sliding window; If CV >= 0.15, it is determined to be "unstable state", indicating that the front end is experiencing congestion or is in a large-scale buffer. At this time, the intelligent suppression state machine is activated. If CV < 0.15, it is determined to be in a "stable state", indicating that the foreground has obtained sufficient bandwidth. At this time, the suppression is suspended, and after the condition is met, it will switch to the gradual recovery state machine.

4. The method according to claim 3, characterized in that, Step S5 specifically includes the following steps: All cgroups are sorted according to a multi-level priority model. When the highest priority application in the foreground is in an "unstable state" and the total bandwidth is approaching V_capacity, suppression is strictly performed according to the following timing steps: Step 1, First Stage Strong Suppression of 10%: Lock the lowest priority background application with the highest current throughput and drastically reduce its rate limiting threshold in the TC layer to 10% of its historical stable rate V_actual_bg; Step 2, Observation and Second-Stage Suppression of 5%: After suppression, wait for a 10-second observation period and recalculate the front-end CV. If the front-end CV is still >= 0.15, it indicates that the concession is insufficient. Further compress the rate limiting threshold of the background application to 5% of its historical stable rate. Step 3, Priority Cascade Deprivation: If the foreground application remains unstable after a single background application is pushed down to 5%, then search upwards for the next lowest priority set of applications and repeat steps 1 and 2 until the foreground CV drops below 0.

15. The multi-level priority model is: manual specification > UI focus state > application business type.

5. The method according to claim 1, characterized in that, Step S6 includes the following steps: If the foreground application is in a steady-state window, its CV value is strictly < 0.15 in two consecutive calculations, and the current total system allocation has a safety margin of at least 10% from V_capacity, then perform the following steps: Step 1, fixed-step release: Increase the threshold of the highest priority suppressed background application by a fixed step size Delta_rho, typically 5% to 15% of V_actual_bg; Step 2, Perturbation Verification: After release, a 5-second verification period begins. If the front-end CV remains < 0.15 and throughput does not drop, the recovery is accepted and the next release is prepared. Step 3, Emergency Rollback: If the front-end CV spikes to >= 0.15, indicating that the dark bandwidth ceiling has been reached, immediately roll back the back-end threshold to the safe value of the previous step and lock it.