TCP congestion control method, device, equipment, medium and product

Abstract

The embodiment of the invention provides a TCP (Transmission Control Protocol) congestion control method, device, equipment, medium and product, and relates to the field of computer networks, the method comprises the following steps: taking a bandwidth upper limit as a core constraint benchmark, combining the core constraint benchmark with smooth RTT and effective MSS to calculate a corresponding congestion window upper limit, and accurately regulating and controlling the congestion window through layered window constraint, so that the congestion control efficiency is improved. It is ensured that a congestion window always adapts to network transmission characteristics and resource allocation requirements, congestion caused by too large windows or resource waste caused by too small windows is avoided, meanwhile, the rhythm sending rate is calculated based on the bandwidth upper limit, the rhythm sending rate of a current application is dynamically updated through double judgment of a change rate threshold value and a minimum updating interval, and the user experience is improved. The real-time adaptation of the rhythm sending rate and the bandwidth upper limit is realized, the problem of insufficient collaboration of window adjustment and rate control in the prior art is solved, network resources are fully utilized while excessive sending is avoided and the transmission stability is guaranteed, and the TCP congestion control efficiency is improved.

Description

A TCP congestion control method, apparatus, device, medium, and product Technical Field

[0001] This application relates to the field of computer networks, and more particularly to a TCP congestion control method, apparatus, device, medium, and product. Background Technology

[0002] TCP congestion control refers to a mechanism that senses network congestion during data transmission and dynamically adjusts the sending behavior of the sending end to avoid excessive competition for network resources and ensure transmission stability and efficiency. How to rationally allocate bandwidth resources, suppress burst traffic, reduce queuing delays and jitter, and ensure transmission fairness among different services and users under complex and ever-changing network conditions has become a key issue in the field of network transmission. As the most widely used transmission protocol on the Internet, TCP's congestion control capabilities directly determine the throughput, latency, stability, and resource utilization efficiency of end-to-end transmission; therefore, TCP congestion control plays a crucial role in modern network architectures.

[0003] In existing technologies, TCP congestion control is mainly based on time-driven cubic functions to adjust the growth curve of the congestion window. When there are no congestion signals such as packet loss in the network, the sending window is gradually increased according to a preset functional relationship. When packet loss is detected or an explicit congestion notification (ECN) is issued, the congestion window is reduced by a certain proportion to adapt to changes in network bandwidth and avoid over-sending.

[0004] However, existing technologies suffer from low efficiency in TCP congestion control. Faced with real-world application demands such as high-bandwidth, low-RTT scenarios, and multi-user resource sharing, the coordination between window adjustment and rate control is insufficient. This makes it difficult to quickly adapt to dynamic changes in network conditions, and hinders the full utilization of network resources while ensuring transmission stability, thus impacting the overall efficiency of end-to-end data transmission. Summary of the Invention

[0005] This application provides a TCP congestion control method, apparatus, device, medium, and product to solve the problem of low efficiency in TCP congestion control in the prior art.

[0006] In a first aspect, embodiments of this application provide a TCP congestion control method, including:

[0007] Obtain smooth RTT, effective MSS, and bandwidth limit; wherein, smooth RTT is used to represent the transmission delay of the network path, effective MSS is used to represent the maximum number of payload bytes carried by a single TCP packet, and bandwidth limit is used to represent the maximum sending bandwidth of the TCP connection;

[0008] Based on the smoothed RTT, the effective MSS, and the bandwidth limit, calculate the congestion window limit corresponding to the bandwidth limit; wherein, the congestion window limit corresponding to the bandwidth limit is used to represent the maximum congestion window used by the TCP connection under the bandwidth limit condition;

[0009] A hierarchical window constraint is applied to the congestion window upper limit corresponding to the bandwidth upper limit to obtain the final effective congestion window upper limit; wherein, the final effective congestion window upper limit is used to limit the maximum congestion window actually used by the TCP connection;

[0010] Based on the bandwidth limit, calculate the first rhythm transmission rate and the rate of change between the first rhythm transmission rate and the preset second rhythm transmission rate; wherein, the first rhythm transmission rate is the rhythm transmission rate calculated based on the bandwidth limit, and the second rhythm transmission rate refers to the rhythm transmission rate applied at the current moment.

[0011] When the rate of change is greater than a preset rate of change threshold and the first time difference is greater than or equal to a preset minimum update interval, the second rhythm transmission rate is updated to the first rhythm transmission rate so that the rhythm transmission rate applied at the current moment is adapted to the bandwidth limit; wherein, the first time difference refers to the time difference between the current moment and the first moment, and the first moment refers to the rhythm rate update moment that is closest to the current moment before the current moment.

[0012] In one possible design, calculating the congestion window upper limit corresponding to the bandwidth upper limit based on the smoothed RTT, the effective MSS, and the bandwidth upper limit includes:

[0013] The bandwidth-delay product is calculated based on the smoothed RTT and the bandwidth limit; wherein the bandwidth-delay product is used to represent the maximum amount of data transmitted simultaneously on the network link;

[0014] Calculate the congestion window limit corresponding to the bandwidth limit based on the bandwidth-delay product and the effective MSS.

[0015] In one possible design, applying hierarchical window constraints to the congestion window upper limit corresponding to the bandwidth upper limit to obtain the final effective congestion window upper limit includes:

[0016] When the smoothed RTT is less than a preset RTT threshold, an RTT scenario constraint is applied to the congestion window upper limit corresponding to the bandwidth upper limit to obtain a first upper limit; wherein, the RTT scenario constraint refers to adjusting the congestion window upper limit corresponding to the bandwidth upper limit to a preset effective window range;

[0017] A fairness constraint is applied to the first upper limit to obtain a second upper limit; wherein, the fairness constraint refers to adjusting the first upper limit so that the first upper limit does not exceed a specific multiple of a preset BDP;

[0018] A memory protection constraint is applied to the second upper limit to obtain the final effective congestion window upper limit; wherein, the memory protection constraint refers to adjusting the second upper limit so that the second upper limit does not exceed a preset system memory safety upper limit value.

[0019] In one possible design, before applying a fairness constraint to the first upper limit to obtain the second upper limit, the process further includes:

[0020] Obtain the user priority identifier and real-time network load status corresponding to the TCP connection; wherein, the user priority identifier is used to indicate the resource allocation priority of the user to which the TCP connection belongs, and the real-time network load status is used to indicate the current network link occupancy level;

[0021] Based on the user priority identifier and the real-time network load status, the preset initial BDP is adjusted to a specific multiple to obtain the specific multiple of BDP.

[0022] In one possible design, after updating the second rhythm transmission rate to the first rhythm transmission rate so that the applied rhythm transmission rate at the current moment adapts to the bandwidth limit, the method further includes:

[0023] Obtain the updated rhythm transmission rate; wherein, the updated rhythm transmission rate refers to the rhythm transmission rate applied at the current moment after updating the second rhythm transmission rate to the first rhythm transmission rate;

[0024] The final effective congestion window upper limit is determined as the mandatory stopping condition for TCP congestion window growth, and the updated rhythm sending rate is determined as the time interval benchmark for TCP packet sending.

[0025] The forced stop condition and the time interval benchmark are used to jointly constrain the actual sending behavior of the preset TCP connection, so that the actual sending behavior of the TCP connection is adapted to the bandwidth limit.

[0026] In one possible design, after constraining the actual sending behavior of the preset TCP connection through the forced stop condition and the time interval reference to adapt the actual sending behavior of the TCP connection to the bandwidth limit, the design further includes:

[0027] Obtain the deviation between the actual sending rate of the TCP connection and the updated rhythm sending rate;

[0028] When the duration of the deviation exceeding the preset deviation threshold is greater than the preset time threshold, the direction and degree of the deviation are obtained, and the preset constraint parameters in the hierarchical window constraint are adjusted according to the direction and degree of the deviation so that the duration is less than the time threshold.

[0029] In one possible design, after adjusting the preset constraint parameters in the hierarchical window constraint according to the direction and degree of the deviation so that the duration is less than the time threshold, the method further includes:

[0030] Obtain the fluctuation frequency and fluctuation amplitude of the bandwidth limit within a preset historical time period;

[0031] When the fluctuation frequency is greater than a preset fluctuation frequency threshold and the fluctuation amplitude is less than a preset fluctuation amplitude threshold, the change rate threshold is reduced and the minimum update interval is shortened.

[0032] When the fluctuation frequency is less than the fluctuation frequency threshold and the fluctuation amplitude is greater than the fluctuation amplitude threshold, the change rate threshold is increased and the minimum update interval is extended.

[0033] In one possible design, prior to obtaining the smoothed RTT, effective MSS, and bandwidth cap, the following steps are also included:

[0034] Acquire the historical smoothed RTT, historical effective MSS, historical bandwidth limit, historical congestion window limit, and historical rhythmic transmission rate collected at a preset second time point; wherein, the second time point is earlier than the current time point;

[0035] Get the current smoothed RTT, current effective MSS, and current bandwidth limit at the current moment;

[0036] In response to the fact that the rate of change between the historical smoothed RTT and the current smoothed RTT is less than a preset first rate of change threshold, and the rate of change between the historical effective MSS and the current effective MSS is less than a preset second rate of change threshold, and the rate of change between the historical bandwidth limit and the current bandwidth limit is less than a preset third rate of change threshold, the historical congestion window limit is determined as the final effective congestion window limit, and the historical rhythm transmission rate is determined as the rhythm transmission rate applied at the current moment.

[0037] Secondly, embodiments of this application provide a TCP congestion control device, comprising:

[0038] The first acquisition module is used to acquire smooth RTT, effective MSS, and bandwidth limit; wherein, smooth RTT is used to represent the transmission delay of the network path, effective MSS is used to represent the maximum number of payload bytes carried by a single TCP packet, and bandwidth limit is used to represent the maximum sending bandwidth of the TCP connection;

[0039] The first calculation module is used to calculate the congestion window upper limit corresponding to the bandwidth upper limit based on the smoothed RTT, the effective MSS, and the bandwidth upper limit; wherein, the congestion window upper limit corresponding to the bandwidth upper limit is used to represent the maximum congestion window used by the TCP connection under the bandwidth upper limit condition;

[0040] The first constraint module is used to apply a hierarchical window constraint to the congestion window upper limit corresponding to the bandwidth upper limit to obtain the final effective congestion window upper limit; wherein, the final effective congestion window upper limit is used to limit the maximum congestion window actually used by the TCP connection;

[0041] The second calculation module is used to calculate a first rhythm transmission rate and a rate of change between the first rhythm transmission rate and a preset second rhythm transmission rate based on the bandwidth limit; wherein the first rhythm transmission rate is a rhythm transmission rate calculated based on the bandwidth limit, and the second rhythm transmission rate refers to the rhythm transmission rate applied at the current moment.

[0042] The update module is used to update the second rhythm transmission rate to the first rhythm transmission rate when the rate of change is greater than a preset rate of change threshold and the first time difference is greater than or equal to a preset minimum update interval, so that the rhythm transmission rate applied at the current moment is adapted to the bandwidth limit; wherein, the first time difference refers to the time difference between the current moment and the first moment, and the first moment refers to the rhythm rate update moment that is closest to the current moment before the current moment.

[0043] In one possible design, the first computing module includes:

[0044] The first calculation unit is used to calculate the bandwidth-delay product based on the smoothed RTT and the bandwidth limit; wherein the bandwidth-delay product is used to represent the maximum amount of data transmitted simultaneously on the network link;

[0045] The second calculation unit is used to calculate the congestion window upper limit corresponding to the bandwidth upper limit based on the bandwidth-delay product and the effective MSS.

[0046] In one possible design, the first constraint module includes:

[0047] The first constraint unit is used to apply an RTT scenario constraint to the congestion window upper limit corresponding to the bandwidth upper limit when the smoothed RTT is less than a preset RTT threshold, thereby obtaining a first upper limit; wherein, the RTT scenario constraint refers to adjusting the congestion window upper limit corresponding to the bandwidth upper limit to a preset effective window range;

[0048] The second constraint unit is used to apply a fairness constraint to the first upper limit to obtain a second upper limit; wherein, the fairness constraint refers to adjusting the first upper limit so that the first upper limit does not exceed a specific multiple of a preset BDP;

[0049] The third constraint unit is used to apply a memory protection constraint to the second upper limit to obtain the final effective congestion window upper limit; wherein, the memory protection constraint refers to adjusting the second upper limit so that the second upper limit does not exceed a preset system memory safety upper limit value.

[0050] In one possible design, the first constraint module further includes:

[0051] The first acquisition unit is used to acquire the user priority identifier and real-time network load status corresponding to the TCP connection; wherein, the user priority identifier is used to indicate the resource allocation priority of the user to which the TCP connection belongs, and the real-time network load status is used to indicate the degree of current network link occupancy;

[0052] The adjustment unit is used to adjust a preset initial BDP multiple based on the user priority identifier and the real-time network load status to obtain the specific multiple of the BDP.

[0053] In one possible design, the TCP congestion control device further includes:

[0054] The second acquisition module is used to acquire the updated rhythm transmission rate; wherein, the updated rhythm transmission rate refers to the rhythm transmission rate applied at the current moment after the second rhythm transmission rate is updated to the first rhythm transmission rate;

[0055] The first determining module is used to determine the final effective congestion window upper limit as the mandatory stopping condition for TCP congestion window growth, and to determine the updated rhythm sending rate as the time interval benchmark for TCP packet sending.

[0056] The second constraint module is used to coordinate the constraint of the preset actual sending behavior of the TCP connection through the forced stop condition and the time interval reference, so that the actual sending behavior of the TCP connection is adapted to the bandwidth limit.

[0057] In one possible design, the TCP congestion control device further includes:

[0058] The third acquisition module is used to acquire the deviation between the actual sending rate of the TCP connection and the updated rhythm sending rate;

[0059] The adjustment module is used to obtain the direction and degree of the deviation when the duration of the deviation exceeding the preset deviation threshold is greater than the preset time threshold, and adjust the preset constraint parameters in the hierarchical window constraint according to the direction and degree of the deviation so that the duration is less than the time threshold.

[0060] In one possible design, the TCP congestion control device further includes:

[0061] The fourth acquisition module is used to acquire the fluctuation frequency and fluctuation amplitude of the bandwidth upper limit within a preset historical time period;

[0062] The reduction module is used to reduce the rate of change threshold and shorten the minimum update interval when the fluctuation frequency is greater than a preset fluctuation frequency threshold and the fluctuation amplitude is less than a preset fluctuation amplitude threshold.

[0063] An enhancement module is used to increase the rate of change threshold and extend the minimum update interval when the fluctuation frequency is less than the fluctuation frequency threshold and the fluctuation amplitude is greater than the fluctuation amplitude threshold.

[0064] In one possible design, the TCP congestion control device further includes:

[0065] The fifth acquisition module is used to acquire historical smoothed RTT, historical effective MSS, historical bandwidth limit, historical congestion window limit, and historical rhythmic transmission rate collected at a preset second time; wherein, the second time is earlier than the current time;

[0066] The sixth acquisition module is used to acquire the current smoothed RTT, the current effective MSS, and the current bandwidth limit at the current moment;

[0067] The second determining module is configured to, in response to the following conditions: the rate of change between the historical smoothed RTT and the current smoothed RTT is less than a preset first rate of change threshold; the rate of change between the historical effective MSS and the current effective MSS is less than a preset second rate of change threshold; and the rate of change between the historical bandwidth limit and the current bandwidth limit is less than a preset third rate of change threshold, determine the historical congestion window limit as the final effective congestion window limit and determine the historical rhythm transmission rate as the rhythm transmission rate applied at the current moment.

[0068] Thirdly, embodiments of this application provide an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0069] The memory stores computer-executed instructions;

[0070] When the processor executes computer execution instructions stored in the memory, it is used to implement the TCP congestion control method as described in any of the first aspects.

[0071] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the TCP congestion control method as described in any of the first aspects.

[0072] Fifthly, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, is used to implement the TCP congestion control method as described in any of the first aspects.

[0073] This application provides a TCP congestion control method, apparatus, device, medium, and product. By using a bandwidth limit as the core constraint benchmark, it combines this limit with smoothed RTT and effective MSS to calculate the corresponding congestion window limit. Then, through hierarchical window constraints, it precisely adjusts the congestion window to ensure that it always adapts to network transmission characteristics and resource allocation needs, avoiding congestion caused by an excessively large window or resource waste caused by an excessively small window. Simultaneously, it calculates the rhythmic transmission rate based on the bandwidth limit and dynamically updates the rhythmic transmission rate of the current application through dual judgments of the rate of change threshold and the minimum update interval, achieving real-time adaptation between the rhythmic transmission rate and the bandwidth limit. This solves the problem of insufficient coordination between window adjustment and rate control in existing technologies. This approach can quickly respond to dynamic changes in network status in practical application scenarios such as high-bandwidth latency product links, low RTT scenarios, and multi-user resource sharing. While avoiding over-transmission and ensuring transmission stability, it fully utilizes network resources and improves the efficiency of TCP congestion control. Attached Figure Description

[0074] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0075] Figure 1 is a schematic diagram of an application scenario of the TCP congestion control method provided in the embodiments of this application;

[0076] Figure 2 is one of the flowcharts of the TCP congestion control method provided in the embodiments of this application;

[0077] Figure 3 is a flowchart of one of the TCP congestion control methods provided in the embodiments of this application;

[0078] Figure 4 is one of the flowcharts of the TCP congestion control method provided in the embodiments of this application;

[0079] Figure 5 is a flowchart of one of the TCP congestion control methods provided in the embodiments of this application;

[0080] Figure 6 is a flowchart of one of the TCP congestion control methods provided in the embodiments of this application;

[0081] Figure 7 is a flowchart of one of the TCP congestion control methods provided in the embodiments of this application;

[0082] Figure 8 is a block diagram of the TCP congestion control system structure provided in an embodiment of this application;

[0083] Figure 9 is a flowchart of one of the TCP congestion control methods provided in the embodiments of this application;

[0084] Figure 10 is a schematic diagram of the TX_START event interaction provided in an embodiment of this application;

[0085] Figure 11 is a flowchart of the clamping up and down adjustment process provided in an embodiment of this application;

[0086] Figure 12 is a special case diagram of low RTT provided in the embodiments of this application;

[0087] Figure 13 is a schematic diagram of caching and recalculation provided in an embodiment of this application;

[0088] Figure 14 is a schematic diagram of the deployment and working path of the cubiclimit congestion control plugin provided in the embodiments of this application;

[0089] Figure 15 is a schematic diagram of the TCP congestion control device provided in an embodiment of this application;

[0090] Figure 16 is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application.

[0091] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0092] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0093] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0094] In the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply difference. It should be noted that in the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner. In the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more.

[0095] It should be noted that the phrase "at...time" in the embodiments of this application can refer to the instant at which a certain situation occurs, or to a period of time after the occurrence of a certain situation; the embodiments of this application do not specifically limit this. Furthermore, the TCP congestion control method, apparatus, device, medium, and product provided in the embodiments of this application are merely examples; a TCP congestion control method, apparatus, device, medium, and product may also include more or fewer elements.

[0096] To facilitate a clear description of the technical solutions in the embodiments of this application, some terms and technologies involved in the embodiments of this application will be briefly introduced below:

[0097] Pace sending: Smoothly send packets at the target sending rate to reduce burst and queuing latency. Related fields include sk_max_pacing_rate (maximum pace sending rate, in bytes / second), pacing_mode (pace sending mode), and pacing_update_thresh_permil (pace update threshold, in per mille). It is often used in conjunction with sch_fq to achieve rate-based paced scheduling.

[0098] Hybrid slow start (HyStart / HyStart++): Based on ACK-train and / or time delay triggering, early exit from slow start is achieved. Relevant fields include hystart (HyStart function switch), hystart_detect (ACK flow detection mode), hystart_low_window (minimum window to trigger HyStart), and hystart_ack_delta_us (ACK interval threshold). It is an optimized slow start mechanism supported by Linux CUBIC.

[0099] Upper and lower limit constraint clamping: Limits the congestion window to the maximum allowed value. Related fields include snd_cwnd_clamp (global window upper limit) and cwnd_cap (connection-level window upper limit), which are used to prevent excessive window growth and excessive resource consumption.

[0100] Hysteresis: This technique prevents immediate updates for small changes to avoid jitter and ensure stability. Related fields include cwnd_upclamp_thresh_permil (threshold to ignore for small increases, in per mille) and permit (hysteresis enable / disable switch). It is commonly used in upscaling scenarios to avoid frequent small fluctuations in the window.

[0101] Congestion window (cwnd): The size of the packet window that the sender can currently fly. The relevant field is snd_cwnd, and the unit is packets. It is a core parameter of congestion control in the Transmission Control Protocol (TCP).

[0102] Slow start threshold (ssthresh): If the threshold is less than this threshold, slow start is used; if it is greater than this threshold, congestion avoidance is used. The relevant fields include snd_ssthresh (current slow start threshold) and init_ssthresh_factor_permil (initial threshold factor, in per mille). These are key parameters during startup and determine the switching point between slow start and congestion avoidance.

[0103] Round-Trip Time (RTT): The round-trip time of a message. It supports smoothing, measurement, minimum, and default multi-source. Related fields include smooth_rtt, srtt (smoothed round-trip time), delay_min (minimum round-trip time), and default_rtt_us (default round-trip time in microseconds). It is the core input parameter for calculating the Bandwidth-Delay Product (BDP).

[0104] Maximum Segment Size (MSS): The payload size of a single TCP segment. Related fields include mss_lower_bound_v4, mss_lower_bound_v6 (lower limit of IPv4 / IPv6 MSS), and mss_upper_bound (upper limit of MSS). These are key parameters that affect the BDP→cwnd mapping.

[0105] BDP: The product of link bandwidth and RTT, representing the amount of data in flight. The field can be represented as BDP_bytes / BDP_packets, and is used for the baseline calculation of window and rate.

[0106] Maximum bandwidth (max_bandwidth): The maximum allowed rate (bps) imposed on the connection. The related field is max_bandwidth, where 0 indicates no limit. It is the core constraint for window and rate calculation.

[0107] Minimum bandwidth (optional) (min_bandwidth): Minimum guaranteed rate (bps) during runtime. Related fields include min_bandwidth (minimum bandwidth value) and enable_runtime_min_bw_floor (minimum bandwidth enable switch). It can be converted into a window lower limit to guarantee the minimum transmission capacity of the connection.

[0108] Bandwidth compensation factor (bw_compensation_factor): This factor corrects the ratio of BDP to cwnd. The relevant field is bw_compensation_factor_permil (in thousands of percent). It is used to compensate for non-ideal characteristics of the link and make the window more closely match the actual bandwidth.

[0109] Fairness cap: Limits the window size to a multiple of BDP. The relevant field is bdp_cwnd_factor_permil (unit is per mille, such as 3000=3×BDP), used for fair resource allocation in multi-user scenarios.

[0110] The minimum fairness cap (fairness_floor) is the maximum window size for minimal BDPs. The relevant field is fairness_cap_floor_packets. It ensures that constraints do not fail and avoids transmission failures caused by excessively small windows.

[0111] Memory protection cap (memory_cap): This sets a maximum limit on the window based on memory / implementation safety. The relevant field is memory_cwnd_cap, which is used to prevent excessive resource consumption and ensure system stability.

[0112] Low RTT Special: When RTT is extremely low, a lower and upper limit are applied to the window. The relevant fields include enable_low_rtt_special (low RTT special enable switch), low_rtt_cap_divisor (window upper limit divisor), and min_effective_cwnd (minimum effective window). It takes effect when RTT < 1ms and is suitable for low latency scenarios.

[0113] Startup bandwidth factor (ss_bandwidth_factor): Uses the bandwidth limit to guide the initial window. The relevant field is ss_bandwidth_factor, where 1000 indicates that the limit is reached directly, which is used to quickly adapt to the bandwidth.

[0114] Initial threshold factor (init_ssthresh_factor): Sets ssthresh according to the initial cwnd ratio. The relevant field is init_ssthresh_factor_permil (in thousands of percent), which is used to optimize the window growth strategy during the slow start phase.

[0115] The rate update threshold (pacing_update_threshold) refreshes pacing only when the relative change exceeds the threshold. The relevant field is pacing_update_thresh_permil (in thousands of percent). Combined with the minimum update time, it avoids frequent updates.

[0116] Minimum recompute interval (min_recompute_interval): Limits the minimum time interval for parameter recompute. The relevant field is cap_recompute_min_interval_ms (in milliseconds). It is used to prevent excessive calculations and reduce system overhead.

[0117] RTT recompute threshold (rtt_recompute_threshold): When the relative change in RTT exceeds this threshold, a recompute is triggered. The relevant field is rtt_recompute_thresh_permil (in thousands of percent), which is used to trigger the recalculation of the window and rate.

[0118] Generation marker (params_generation): The parameter version number is used for cache invalidation broadcasting. The related field is params_generation, which is aligned to the lower 8 bits and is used for cache consistency management of parameter updates.

[0119] Effective MSS selection: Selects MSS based on the protocol lower bound and the optional upper bound. Relevant fields include mss_lower_bound_v4 / v6 and mss_upper_bound. Prioritizes using connection cached MSS to ensure that the MSS value is reasonable.

[0120] Window up step size (cwnd_up_step): Limits the maximum up step ratio. The relevant field is cwnd_upclamp_step_permil (in thousands of percent). It is used to prevent sudden large increases in window size from causing bursts of transmission.

[0121] Window downstep size (cwnd_down_step): Limits the maximum downstep ratio in a single step. The relevant field is cwnd_downclamp_step_permil (in thousands of percent). It is used to prevent transmission interruption caused by a sudden and significant drop in the window size.

[0122] Increase the suppression threshold (cwnd_up_threshold): Slightly increase the ignore threshold. The relevant field is cwnd_upclamp_thresh_permil (in thousands of percent). This is used to suppress small window increases and improve stability.

[0123] Lower the trigger threshold (cwnd_down_threshold): The trigger threshold that is significantly lowered. The relevant field is cwnd_downclamp_thresh_permil (in thousands of percent). It is used to trigger the corresponding control logic when the window drops below this threshold.

[0124] Maximum pacing rate (max_pacing_rate): The upper limit of pacing (bytes / second). The related field is sk_max_pacing_rate, which is usually set to max_bw / 8, consistent with the bandwidth limit.

[0125] Queue rules (fair queue) (sch_fq / fq): rhythmic allocation based on pacing rate. The relevant fields are configured by qdisc and work in conjunction with sk_pacing_rate to achieve smooth packet sending.

[0126] User-space maximum rate (SO_MAX_PACING_RATE): Sets the maximum pacing rate for a socket in user space. The relevant field is setsockopt(TCP, SO_MAX_PACING_RATE). It coexists with the kernel-side upper limit and provides user-space control capabilities.

[0127] Queue rules (qdisc): Linux packet queuing and allocation framework. Related fields are (no specific fields, just a general term for the framework), such as Fair Queue (fq), Token Bucket Filter (TBF), and Hierarchical Token Bucket (HTB), etc., used for flow control and allocation.

[0128] Network Interface Controller (NIC): A network interface controller, with related fields (no specific fields, a general term for hardware), responsible for physical layer data transmission and reception, affecting actual transmission performance.

[0129] ACK Train Detection: Continuous ACK arrivals are one of the congestion signals. The relevant field is hystart_detect, which is one of the HyStart modes and is used to exit slow start early.

[0130] Congestion avoidance: A window adjustment strategy for non-slow start phases, with related fields representing the CUBIC main algorithm (cubic growth curve), adapted for high-bandwidth scenarios.

[0131] Epoch: The growth adjustment cycle after each congestion in CUBIC. The relevant fields are (no specific fields, it is a logical cycle). It is reset when the window is significantly reduced, and is used to reset the growth strategy.

[0132] Send Start Event (TX_START): The critical timing for scheduling the send path. The relevant fields are (event hook / logic), used for debouncing updates and alignment to ensure consistency in sending behavior.

[0133] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0134] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0135] To clearly understand the technical solution of this application, the solutions of existing technologies are first described in detail. TCP congestion control refers to a mechanism that senses network congestion during data transmission and dynamically adjusts the packet sending behavior of the sending end, thereby avoiding excessive competition for network resources and ensuring transmission stability and efficiency. How to rationally allocate bandwidth resources, suppress burst traffic, reduce queuing delays and jitter, and ensure transmission fairness among different services and users under complex and ever-changing network conditions has become a key issue in the field of network transmission. As the most widely used transmission protocol on the Internet, TCP's congestion control capability directly determines the throughput, latency, stability, and resource utilization efficiency of end-to-end transmission; therefore, TCP congestion control plays a crucial role in modern network architectures.

[0136] In existing technologies, TCP congestion control primarily adjusts the growth curve of the congestion window based on a time-driven cubic function. When no congestion signals such as packet loss occur in the network, the sending window gradually increases according to a preset functional relationship. When packet loss is detected or an explicit congestion notification (ECN) is received, the congestion window is reduced proportionally to adapt to changes in network bandwidth and avoid over-transmission. However, in practical applications such as high-bandwidth, low-RTT scenarios and multi-user resource sharing, the coordination between window adjustment and rate control is insufficient. This makes it difficult to quickly adapt to dynamic changes in network conditions and to fully utilize network resources while ensuring transmission stability, thus affecting the overall efficiency of end-to-end data transmission. Therefore, existing technologies suffer from low TCP congestion control efficiency.

[0137] Therefore, addressing the issue of low efficiency in existing TCP congestion control technologies, this research found that a bandwidth upper limit can be introduced as a core constraint benchmark to solve this problem. This involves co-optimizing congestion window adjustment with rhythmic transmission rate control, enabling rapid adaptation to dynamic changes in network conditions. This improves network resource utilization and transmission efficiency while ensuring transmission stability: ① A dynamic constraint benchmark for the congestion window can be constructed using key network transmission parameters as the core. By combining key parameters such as network path transmission delay and packet payload characteristics, a reasonable range of the congestion window adapted to the current network condition is calculated, replacing the traditional fixed-function driven window growth model. Precisely defining the upper limit of the window avoids congestion or resource waste caused by a mismatch between window adjustment and the actual network carrying capacity. ② Based on the initial window constraint calculated using network parameters, a hierarchical management strategy can be used to further optimize the upper limit of the window. The constraint strength can be dynamically adjusted based on the dynamic characteristics of network changes, ensuring that the maximum threshold of the congestion window adapts to core network parameters such as bandwidth and delay, while also flexibly responding to network condition fluctuations, thus balancing transmission stability and resource utilization. ③ Based on the upper limit of the network's bandwidth capacity, the corresponding reasonable transmission rate can be derived. By setting the judgment conditions for rate changes and the update interval, the actual transmission rate can be dynamically adjusted, so that the transmission rate can quickly keep up with the bandwidth changes. This solves the problems of insufficient coordination and lag in rate control and window adjustment in traditional technologies, and optimizes the data transmission rhythm.

[0138] Specifically, a dynamic control system for congestion windows can be constructed based on core network transmission parameters and combined with bandwidth constraints. At the same time, an adaptive update mechanism for the transmission rate can be linked. By setting reasonable control judgment conditions, the congestion window and the transmission rate can be coordinated and adapted to each other, and the dynamic changes in network status can be responded to quickly. Under the premise of avoiding network congestion and ensuring transmission stability, network resources can be fully utilized to improve the efficiency of TCP congestion control.

[0139] Based on the above-mentioned inventive discovery, the technical solution of this application is proposed.

[0140] The following describes the application scenarios of the TCP congestion control method provided in this embodiment of the invention. Figure 1 is a schematic diagram of the application scenario of the TCP congestion control method provided in this application embodiment. As shown in Figure 1, the application scenario includes a kernel TCP sender 101 and a receiver 102. The kernel TCP sender 101 obtains the smoothed RTT, effective MSS, and bandwidth limit. Based on the smoothed RTT, effective MSS, and bandwidth limit, the kernel TCP sender 101 calculates the congestion window limit corresponding to the bandwidth limit. The kernel TCP sender 101 applies a hierarchical window constraint to the congestion window limit corresponding to the bandwidth limit to obtain the final effective congestion window limit. Based on the bandwidth limit, the kernel TCP sender 101 calculates the first rhythm transmission rate and the rate of change between the first rhythm transmission rate and the preset second rhythm transmission rate. When the rate of change is greater than the preset rate of change threshold and the first time difference is greater than or equal to the preset minimum update interval, the kernel TCP sender 101 updates the second rhythm transmission rate to the first rhythm transmission rate so that the rhythm transmission rate applied at the current moment adapts to the bandwidth limit. Based on the final effective congestion window limit and the rhythm transmission rate, the kernel TCP sender 101 sends TCP data packets to the receiver 102.

[0141] The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0142] Figure 2 is a flowchart illustrating one of the TCP congestion control methods provided in this embodiment. As shown in Figure 2, in this embodiment, the execution entity is the kernel TCP sender. The TCP congestion control method provided in this embodiment includes the following steps:

[0143] S201. Obtain the smoothed RTT, effective MSS, and bandwidth limit; where smoothed RTT represents the transmission delay of the network path, effective MSS represents the maximum number of payload bytes carried by a single TCP packet, and bandwidth limit represents the maximum sending bandwidth of the TCP connection.

[0144] Specifically, the smoothed RTT can be obtained by weighted averaging the round-trip times of multiple consecutive TCP segments, the valid MSS can be read from the parameter configuration of the current TCP connection, and the bandwidth limit can be obtained by probing the maximum available transmission capacity of the network path or receiving bandwidth indication information from the peer. This step is used to provide parameters for subsequent calculation of the congestion window limit and rhythmic transmission rate, ensuring that the congestion control adjustment fits the actual transmission conditions of the current network path.

[0145] Among them, Smooth RTT represents the round-trip latency of data packets on the network path, reflecting the stable transmission latency characteristics of the network path. Effective MSS represents the maximum number of payload bytes that a single TCP packet can carry, excluding invalid data portions such as the packet header, reflecting the actual data carrying capacity of a single TCP packet. Bandwidth limit represents the maximum sending bandwidth that a TCP connection can use in the current network path, determined by the physical transmission capacity of the network link and resource allocation rules, limiting the maximum bandwidth range for TCP connection data transmission.

[0146] S202. Calculate the congestion window limit corresponding to the bandwidth limit based on the smoothed RTT, effective MSS, and bandwidth limit; whereby the congestion window limit corresponding to the bandwidth limit is used to represent the maximum congestion window used by the TCP connection under the bandwidth limit condition.

[0147] Specifically, the bandwidth limit can be converted into the number of data packets that can be sent per second, and then multiplied by the smoothed RTT to obtain the total number of data packets that can be transmitted per unit time. Then, this total number is calibrated in combination with the effective MSS, that is, by dividing the bandwidth limit by the effective MSS to obtain the number of data packets that can be sent per second, and then multiplying this value by the smoothed RTT to obtain the congestion window limit corresponding to the bandwidth limit. This step is used to determine the maximum congestion window that the TCP connection can use under the current bandwidth limit conditions, providing a clear basis for subsequently applying tiered window constraints and limiting the actual congestion window range.

[0148] The congestion window limit corresponding to the bandwidth limit is used to represent the maximum congestion window that a TCP connection can use under the bandwidth limit condition. It reflects the maximum number of data packets that a TCP connection can send simultaneously without exceeding the bandwidth limit, and provides a basic numerical reference for subsequently applying hierarchical window constraints and determining the final effective congestion window limit.

[0149] S203. Apply a hierarchical window constraint to the congestion window limit corresponding to the bandwidth limit to obtain the final effective congestion window limit; wherein, the final effective congestion window limit is used to limit the maximum congestion window actually used by the TCP connection.

[0150] Specifically, the process first determines whether the smoothed RTT is less than a preset RTT threshold. If it is, an RTT scenario constraint is applied to the congestion window upper limit corresponding to the bandwidth upper limit, adjusting it to within a preset effective window range to obtain the first upper limit. Then, a fairness constraint is applied to the first upper limit, adjusting it to not exceed a specific multiple of the preset BDP to obtain the second upper limit. Finally, a memory protection constraint is applied to the second upper limit, adjusting it to not exceed the preset system memory safety upper limit. The final second upper limit is the effective congestion window upper limit. This step is used to precisely control the congestion window upper limit corresponding to the bandwidth upper limit in different scenarios and dimensions, adapting to the transmission requirements of different RTT scenarios, balancing transmission fairness and system memory safety, defining a reasonable and safe range for the congestion window actually used by the TCP connection, avoiding transmission problems caused by window anomalies, and ensuring that the congestion window adapts to network scenarios and system conditions.

[0151] Among them, applying layered window constraints is a multi-level progressive numerical limit strategy for congestion windows in TCP congestion control. That is, according to the preset priority and effective logic, multi-dimensional constraints such as the lower limit of low RTT special cases, the lower limit of minimum bandwidth switching window, the upper limit of fairness, and the upper limit of memory protection are superimposed in turn. The basic window value calculated based on BDP is clamped and modified layer by layer, and finally the effective upper limit of congestion window that meets the requirements of all scenarios is obtained. This not only ensures the effectiveness of the window in special scenarios such as ultra-low RTT and low bandwidth, but also avoids excessive window growth and resource consumption through fairness and system-level memory constraints, so as to achieve precise window control under different network environments and system security requirements.

[0152] The final effective congestion window upper limit represents the maximum congestion window actually used by a TCP connection after the layered window constraint processing. It is a value obtained by adjusting the congestion window upper limit corresponding to the bandwidth limit, combined with RTT scenario constraints, fairness constraints and memory protection constraints. It is used to limit the maximum number of data packets that the TCP connection sender can send at the same time, ensuring that the congestion window adapts to the network scenario, transmission fairness and system memory conditions, and provides a clear upper limit boundary for the congestion window adjustment of TCP connections.

[0153] S204. Calculate the first rhythm transmission rate and the rate of change between the first rhythm transmission rate and the preset second rhythm transmission rate based on the bandwidth limit; wherein, the first rhythm transmission rate is the rhythm transmission rate calculated based on the bandwidth limit, and the second rhythm transmission rate refers to the rhythm transmission rate applied at the current moment.

[0154] Specifically, the bandwidth limit can be divided by the effective MSS to obtain the number of data packets that can be sent per unit time. This value is used as the first rhythm transmission rate. Then, the absolute value of the difference between the first rhythm transmission rate and the second rhythm transmission rate is calculated. This absolute value is divided by the second rhythm transmission rate to obtain the rate of change between the first rhythm transmission rate and the second rhythm transmission rate. This step is used to determine the rhythm transmission rate that matches the bandwidth limit and to quantify the difference between the current application's rhythm transmission rate and the matching rate. This provides a numerical basis for subsequent judgment on whether to update the rhythm transmission rate, making the adjustment of the rhythm transmission rate have a clear calculation reference.

[0155] S205. When the rate of change is greater than a preset rate of change threshold and the first time difference is greater than or equal to the preset minimum update interval, the second rhythm transmission rate is updated to the first rhythm transmission rate so that the rhythm transmission rate applied at the current moment is adapted to the bandwidth limit; wherein, the first time difference refers to the time difference between the current moment and the first moment, and the first moment refers to the rhythm rate update moment that is closest to the current moment before the current moment.

[0156] Specifically, the arithmetic logic unit inside the TCP protocol stack can compare the rate of change with the rate of change threshold. At the same time, it can compare the first time difference between the current time and the most recent rhythm rate update time with the minimum update interval. When the rate of change is greater than the rate of change threshold and the first time difference is greater than or equal to the minimum update interval, the second rhythm sending rate of the current application is assigned the first rhythm sending rate, and the current time is recorded as the new most recent rhythm rate update time, thus completing the rhythm sending rate update. This step is used to replace the rhythm sending rate of the current application when the rate difference condition and time interval condition are met, so that the rhythm sending rate is consistent with the bandwidth limit, providing the TCP sender with a sending rate reference that adapts to the bandwidth limit.

[0157] Among them, the final effective congestion window upper limit and the final determined rhythmic transmission rate are two quantitative indicators in the TCP congestion control scheme for implementing coordinated and refined management of the transmission behavior on the sending side. They jointly constrain the packet sending behavior of the TCP sender from different dimensions: the final effective congestion window upper limit imposes a hard constraint on the total amount of data in flight, explicitly limiting the maximum number of data packets allowed to be transmitted in the network by the sender without receiving confirmation from the other end. This numerical constraint avoids network congestion and packet loss caused by excessive data in flight. Simultaneously, combined with the requirements of layered window constraints such as low RTT exceptions, minimum bandwidth, fairness, and memory protection, the upper limit... The control mechanism adapts to the transmission needs of different network scenarios while also considering system resource consumption and fairness in multi-user transmission. The final determined rhythmic sending rate is regulated from the perspective of packet sending timing, clearly defining the rate threshold for the sender to send packets outward. This rate constraint ensures that the sender sends packets continuously at a stable rhythm, replacing the bursty batch packet sending mode. This reduces the queue buffer pressure on network devices, reduces queuing latency, and minimizes packet loss due to queue overflow. Simultaneously, this rate is linked to the congestion window limit, with rate regulation optimized based on the window limit value. This avoids invalid packet sending due to excessively high rates but insufficient windows, or wasted link resources due to sufficient windows but excessively low rates. These two mechanisms work together to comprehensively constrain the TCP sender's transmission behavior from two core dimensions: total quantity and timing. This ensures that the sending behavior conforms to the network link's transmission capacity while also adapting to system resources, transmission fairness, and other requirements, ultimately guaranteeing the stability, efficiency, and smoothness of network transmission.

[0158] The TCP congestion control method of this application can be applied to large-scale distributed computing scenarios in the field of data center networks. Existing technologies in this scenario typically adopt fixed window or packet loss-based congestion control strategies, which are prone to problems such as unreasonable window settings, poor transmission fairness, and excessive system memory consumption on low-latency, high-bandwidth links. The TCP congestion control method of this application can adapt the congestion window to low RTT transmission characteristics, multi-user fairness requirements, and system memory safety boundaries through hierarchical window constraints and dynamic rate adjustment, while matching the sending rate with the real-time bandwidth limit, thus solving the technical problems of abnormal window fluctuations, resource allocation imbalance, and insufficient system stability.

[0159] The TCP congestion control method of this application can also be applied to high-definition video real-time transmission scenarios in the field of mobile communication networks. Existing technologies in this scenario mostly rely on congestion control mechanisms with fixed thresholds, which are difficult to adapt to dynamic changes in network load and differences in user priorities. This can easily lead to problems such as video stuttering, low bandwidth utilization, and resource contention among connections of different priorities. The TCP congestion control method of this application can dynamically adjust the congestion window constraint parameters by combining user priorities and real-time network load. At the same time, it can achieve accurate updates of the transmission rate through dual judgment of rate change rate and time interval, thus solving the technical problems of delayed congestion control response, unreasonable resource allocation, and unstable transmission quality in dynamic network environments.

[0160] This embodiment provides a TCP congestion control method that uses the bandwidth limit as the core constraint benchmark, combining it with smoothed RTT and effective MSS to calculate the corresponding congestion window limit. Then, it precisely adjusts the congestion window through hierarchical window constraints, ensuring that the congestion window always adapts to network transmission characteristics and resource allocation needs. This avoids congestion caused by an excessively large window or resource waste caused by an excessively small window. Simultaneously, it calculates the rhythmic transmission rate based on the bandwidth limit and dynamically updates the current application's rhythmic transmission rate through dual judgments of the rate of change threshold and minimum update interval, achieving real-time adaptation between the rhythmic transmission rate and the bandwidth limit. This solves the problem of insufficient coordination between window adjustment and rate control in existing technologies. This method can quickly respond to dynamic changes in network status in practical application scenarios such as high-bandwidth latency product links, low RTT scenarios, and multi-user resource sharing. While avoiding over-transmission and ensuring transmission stability, it fully utilizes network resources and improves the efficiency of TCP congestion control.

[0161] In one possible design, S202 calculates the congestion window upper limit corresponding to the bandwidth upper limit based on the smoothed RTT, effective MSS, and bandwidth upper limit, including:

[0162] S2021. Calculate the bandwidth-delay product based on the smoothed RTT and the bandwidth limit; whereby the bandwidth-delay product is used to represent the maximum amount of data transmitted simultaneously on the network link.

[0163] Specifically, the smoothed RTT can be multiplied by the bandwidth limit to obtain the bandwidth-delay product. When calculating, the units of the two are unified. The bandwidth limit is converted into bytes per second and then multiplied by the smoothed RTT in seconds. This step is used to obtain the maximum amount of data that can be transmitted simultaneously on the network link, providing a basis for the subsequent calculation of the congestion window limit corresponding to the bandwidth limit.

[0164] S2022. Calculate the congestion window limit corresponding to the bandwidth limit based on the bandwidth-delay product and the effective MSS.

[0165] Specifically, the bandwidth-delay product can be divided by the effective MSS to obtain the congestion window upper limit corresponding to the bandwidth upper limit. During the calculation, the units of the bandwidth-delay product and the effective MSS are kept in bytes. The congestion window upper limit value in units of data packets is obtained through division. This step is used to convert the maximum data carrying capacity of the network link into a congestion window value that the TCP sender can directly use, providing the basic calculation results for subsequent hierarchical window constraints and the determination of the final congestion window upper limit.

[0166] The technical effect of this scheme in this embodiment is as follows: by calculating the bandwidth-delay product based on smooth RTT and bandwidth limit, and further combining it with effective MSS to obtain the congestion window limit corresponding to the bandwidth limit, a quantitative mapping from the bandwidth limit to the congestion window is realized. This enables the congestion window limit to accurately reflect the matching relationship between link carrying capacity and bandwidth limit, ensuring the rationality of window calculation. It transforms bandwidth constraints into window parameters that can be directly used for TCP sending control, solving the problem in the prior art where the lack of a unified and accurate mapping relationship between the bandwidth limit and the congestion window leads to the disconnect between window adjustment and bandwidth limit, and the inability of the window size to truly match the bandwidth constraint.

[0167] In one possible design, S203 applies a hierarchical window constraint to the congestion window upper limit corresponding to the bandwidth upper limit to obtain the final effective congestion window upper limit, including:

[0168] S2031. When the smoothed RTT is less than the preset RTT threshold, apply the RTT scenario constraint to the upper limit of the congestion window corresponding to the upper limit of the bandwidth limit to obtain the first upper limit; wherein, the RTT scenario constraint refers to adjusting the upper limit of the congestion window corresponding to the upper limit of the bandwidth limit to the preset effective window range.

[0169] Specifically, we can first determine whether the smoothed RTT is less than the RTT threshold by numerical comparison. If the smoothed RTT is less than the RTT threshold, we compare the upper limit of the congestion window corresponding to the bandwidth limit with the lower and upper limits of the effective window range. If the upper limit of the congestion window corresponding to the bandwidth limit is less than the lower limit of the effective window range, then the lower limit of the effective window range is taken as the first upper limit. If the upper limit of the congestion window corresponding to the bandwidth limit is greater than the upper limit of the effective window range, then the upper limit of the effective window range is taken as the first upper limit. If the upper limit of the congestion window corresponding to the bandwidth limit is between the lower and upper limits of the effective window range, then the upper limit of the congestion window corresponding to the bandwidth limit is directly taken as the first upper limit. This step is used to limit the upper limit of the congestion window to the effective window range in low RTT scenarios, providing a window value adapted to the low RTT transmission characteristics for subsequent application of fairness constraints.

[0170] S2032. Apply a fairness constraint to the first upper limit to obtain a second upper limit; wherein, the fairness constraint refers to adjusting the first upper limit so that the first upper limit does not exceed a specific multiple of the preset BDP.

[0171] Specifically, the first upper limit can be compared with a preset multiple of BDP. If the first upper limit is greater than the preset multiple, the preset multiple is used as the second upper limit. If the first upper limit is less than or equal to the preset multiple, the first upper limit is used directly as the second upper limit. This step is used to limit the congestion window upper limit to a preset multiple of BDP, providing a window value that meets the requirements of transmission fairness for subsequent application of memory protection constraints.

[0172] S2033. Apply a memory protection constraint to the second upper limit to obtain the final effective congestion window upper limit; wherein, the memory protection constraint refers to adjusting the second upper limit so that the second upper limit does not exceed the preset system memory safety upper limit value.

[0173] Specifically, the second upper limit can be compared with the preset system memory safety upper limit. If the second upper limit is greater than the system memory safety upper limit, the system memory safety upper limit is used as the final effective congestion window upper limit. If the second upper limit is less than or equal to the system memory safety upper limit, the second upper limit is directly used as the final effective congestion window upper limit. This step is used to limit the congestion window upper limit to within the system memory safety upper limit, providing the maximum congestion window boundary that can be directly used for TCP connections.

[0174] Among them, RTT scenario constraints, fairness constraints, and memory protection constraints are the three core hierarchical constraint rules implemented on the congestion window in TCP congestion control. RTT scenario constraints are mainly aimed at ultra-low RTT network environments. By setting a minimum effective window and calculating the upper bound of the adapted window, it avoids window calculation failure and underutilization of link resources due to excessively small RTT. Fairness constraints calculate the fairness upper limit of the congestion window based on BDP and configure a minimum fair window value to prevent excessive growth of the single-stream window and its excessive occupation of network resources, and to ensure the fairness of bandwidth allocation during multi-stream transmission. Memory protection constraints limit the maximum value of the congestion window by setting an upper limit of the memory protection window, and avoid excessive occupation of system kernel memory due to excessive amount of data in flight, which can lead to memory resource shortages. The three types of constraints are superimposed according to a preset logic in the calculation process of the congestion window. Together with the minimum bandwidth constraint, they form a complete window constraint system. This system is used to modify and clamp the basic window value calculated based on BDP layer by layer. Finally, the upper limit of the congestion window is obtained, which takes into account the adaptability of network scenarios, the fairness of multi-stream transmission, and the security of system memory. This enables fine-grained and multi-dimensional management of the congestion window, ensuring that TCP transmission can efficiently utilize link resources in different network scenarios without affecting the overall fairness of the network and the stability of system operation.

[0175] The technical effect of this solution in this embodiment is as follows: by sequentially applying RTT scenario constraints, fairness constraints, and memory protection constraints to the upper limit of the congestion window, multi-dimensional fine-grained control of the window size is achieved: in low RTT scenarios, the window is limited to an effective range to avoid transmission failure due to an excessively small window; the BDP multiple constraint ensures fair resource allocation among multiple users; and the memory safety upper limit constraint prevents excessive occupation of system resources, so that the final effective upper limit of the congestion window not only meets bandwidth limitations but also adapts to network scenarios and balances fairness and system stability. This solves the problems of lack of scenario adaptability, insufficient fairness guarantee, and uncontrollable memory resource occupation in the existing technology for congestion window control.

[0176] Figure 3 is a flowchart illustrating one of the TCP congestion control methods provided in this application. In this embodiment, based on the embodiment provided in Figure 2, the TCP congestion control method is further explained. The TCP congestion control method includes:

[0177] S301. When the smoothed RTT is less than the preset RTT threshold, apply the RTT scenario constraint to the upper limit of the congestion window corresponding to the upper limit of the bandwidth to obtain the first upper limit; wherein, the RTT scenario constraint refers to adjusting the upper limit of the congestion window corresponding to the upper limit of the bandwidth to the preset effective window range.

[0178] S301 is similar to S2031, and will not be described again in this embodiment.

[0179] S302. Obtain the user priority identifier and real-time network load status corresponding to the TCP connection; wherein, the user priority identifier is used to indicate the resource allocation priority of the user to which the TCP connection belongs, and the real-time network load status is used to indicate the degree of current network link occupancy.

[0180] Specifically, a pre-configured user priority identifier can be read from the control block of the TCP connection. This identifier is written by the application layer or network management layer and stored in connection attributes when the connection is established. The real-time network load status is obtained by reading the ratio of the current link throughput to the total link capacity recorded in the network interface driver. This ratio is calculated and updated in real time by the driver based on the number of bytes sent and received by the interface. This step is used to provide a basis for adjusting the specific multiple of BDP for user priority and network occupancy, so that the parameters of fairness constraints can match the resource allocation level of the user to which the connection belongs with the actual current network occupancy.

[0181] The user priority identifier indicates the resource allocation priority of the user to which the TCP connection belongs. This identifier is configured by the application layer or network management layer and bound to the connection attributes when the connection is established. Different identifiers correspond to different resource allocation weights; the higher the identifier value, the higher the resource allocation priority of the user. Real-time network load status indicates the current network link occupancy level. This is reflected by the ratio of the current link throughput to the total link capacity recorded by the network interface driver. The closer the ratio is to 1, the higher the network link occupancy level; the closer the ratio is to 0, the lower the network link occupancy level.

[0182] S303. Based on the user priority identifier and real-time network load status, adjust the preset initial BDP specific multiple to obtain the BDP specific multiple.

[0183] Specifically, a priority coefficient can be determined based on the user's priority identifier. The higher the user's priority, the larger the priority coefficient. Then, a load adjustment coefficient can be determined based on the real-time network load status. The higher the network load, the smaller the load adjustment coefficient. The specific multiple of the initial BDP is multiplied by the priority coefficient and the load adjustment coefficient in sequence to obtain the adjusted specific multiple of BDP. This step is used to adjust the reference value of fairness constraints by combining the user's resource allocation level and network occupancy level, so that the specific multiple of BDP can match the priority needs of different users and the actual network load.

[0184] S304. Apply a fairness constraint to the first upper limit to obtain a second upper limit; wherein, the fairness constraint refers to adjusting the first upper limit so that the first upper limit does not exceed a specific multiple of the preset BDP.

[0185] S305. Apply a memory protection constraint to the second upper limit to obtain the final effective congestion window upper limit; wherein, the memory protection constraint refers to adjusting the second upper limit so that the second upper limit does not exceed the preset system memory safety upper limit value.

[0186] S304-S305 are similar to S2032-S2033, and will not be described again in this embodiment.

[0187] The technical effect of this solution in this embodiment is as follows: by introducing user priority identifiers and real-time network load status, the specific multiple of BDP in the fairness constraint is dynamically adjusted, so that the upper limit of the congestion window can be adaptively adjusted according to the user service level and the actual network occupancy, thereby realizing a differentiated resource allocation strategy. The fairness constraint is no longer a fixed value, but matches the business needs and network status. This solves the problem in the prior art that the fairness constraint parameters are fixed and cannot be dynamically adjusted according to user priority and network load, resulting in rigid resource allocation, insufficient guarantee of high-priority services, or low resource utilization under low load.

[0188] Figure 4 is a flowchart illustrating one of the TCP congestion control methods provided in this application. In this embodiment, based on the embodiment provided in Figure 2, the TCP congestion control method is further explained. The TCP congestion control method includes:

[0189] S401. Obtain smooth RTT, effective MSS, and bandwidth limit; where smooth RTT represents the transmission delay of the network path, effective MSS represents the maximum number of payload bytes carried by a single TCP packet, and bandwidth limit represents the maximum sending bandwidth of the TCP connection.

[0190] S402. Calculate the congestion window limit corresponding to the bandwidth limit based on the smoothed RTT, effective MSS, and bandwidth limit; whereby the congestion window limit corresponding to the bandwidth limit is used to represent the maximum congestion window used by the TCP connection under the bandwidth limit condition.

[0191] S403. Apply a hierarchical window constraint to the congestion window limit corresponding to the bandwidth limit to obtain the final effective congestion window limit; wherein, the final effective congestion window limit is used to limit the maximum congestion window actually used by the TCP connection.

[0192] S404. Calculate the first rhythm transmission rate and the rate of change between the first rhythm transmission rate and the preset second rhythm transmission rate based on the bandwidth limit; wherein, the first rhythm transmission rate is the rhythm transmission rate calculated based on the bandwidth limit, and the second rhythm transmission rate refers to the rhythm transmission rate applied at the current moment.

[0193] S405. When the rate of change is greater than the preset rate of change threshold and the first time difference is greater than or equal to the preset minimum update interval, the second rhythm transmission rate is updated to the first rhythm transmission rate so that the rhythm transmission rate applied at the current moment is adapted to the bandwidth limit; wherein, the first time difference refers to the time difference between the current moment and the first moment, and the first moment refers to the rhythm rate update moment that is closest to the current moment before the current moment.

[0194] S401-S405 are similar to S201-S205, and will not be described again in this embodiment.

[0195] S406. Obtain the updated rhythm transmission rate; wherein, the updated rhythm transmission rate refers to the rhythm transmission rate applied at the current moment after the second rhythm transmission rate is updated to the first rhythm transmission rate.

[0196] Specifically, after completing the update operation from the second rhythm transmission rate to the first rhythm transmission rate, the currently stored rhythm transmission rate value can be directly read from the transmission control module of the TCP protocol stack. This value is saved in real time by the internal registers or variables of the protocol stack after the update is completed. When reading, the updated rhythm transmission rate can be directly obtained through variable reference or register access operations. This step is used to obtain the reference rate that can be directly used for transmission control after the rate update, providing a specific value for subsequently determining the reference time interval for TCP packet transmission.

[0197] S407. The final effective congestion window upper limit is determined as the mandatory stopping condition for TCP congestion window growth, and the updated rhythm sending rate is determined as the time interval benchmark for TCP packet sending.

[0198] Specifically, the final effective congestion window upper limit can be written into the congestion control register of the TCP protocol stack as a comparison threshold for window growth logic. Each time the congestion window attempts to grow, the current congestion window value is compared with the upper limit value in the register. If the current congestion window reaches or exceeds the upper limit, window growth is stopped. This establishes the final effective congestion window upper limit as a forced stopping condition. Simultaneously, the updated rhythmic transmission rate is written into the rate reference register of the transmission allocation module. By calculating the ratio of unit time to the updated rhythmic transmission rate, the transmission time interval between two adjacent TCP packets is obtained. This establishes the updated rhythmic transmission rate as the time interval reference. This step provides a clear constraint on the congestion window growth and packet transmission timing of the TCP connection, giving the control of window growth and transmission interval a fixed reference standard.

[0199] S408. By coordinating the forced stop conditions and time interval benchmarks, the actual sending behavior of the preset TCP connection is constrained so that the actual sending behavior of the TCP connection is adapted to the bandwidth limit.

[0200] Specifically, in the TCP sender's protocol stack, the congestion control module can monitor the current congestion window value in real time. When the window value reaches the final effective congestion window limit, a forced stop condition is triggered, and the congestion window growth operation is paused. At the same time, the sending allocation module calculates the sending delay of adjacent data packets based on the time interval. After each data packet is sent, the module waits for the specified delay before starting the sending process of the next data packet. The two modules execute the constraint logic synchronously to jointly control the total number of data packets sent and the sending rate of the TCP connection. This step is used to limit the actual sending behavior of the TCP connection from two dimensions: window size and sending timing, so that the total number of packets sent does not exceed the bandwidth capacity and the sending rate matches the real-time bandwidth limit.

[0201] The technical effect of this solution in this embodiment is as follows: by setting the final effective congestion window upper limit as a mandatory stop condition for congestion window growth, and using the updated rhythmic sending rate as the benchmark for packet sending interval, the window upper limit and rhythmic rate are used to coordinately constrain the sending behavior. This ensures that the total number of packets sent by the TCP connection and the packet sending rhythm strictly match the bandwidth upper limit requirement, avoiding sudden sending or rate mismatch due to the independent control of the window and rhythm. This solves the problem in the prior art where congestion window constraints and rhythmic sending control are independent and difficult to form a unified constraint, resulting in inconsistency between actual sending behavior and bandwidth upper limit.

[0202] Figure 5 is a flowchart illustrating one of the TCP congestion control methods provided in this application. In this embodiment, based on the embodiment provided in Figure 4, the TCP congestion control method is further explained. The TCP congestion control method includes:

[0203] S501. Obtain the updated rhythm transmission rate; wherein, the updated rhythm transmission rate refers to the rhythm transmission rate applied at the current moment after the second rhythm transmission rate is updated to the first rhythm transmission rate.

[0204] S502, The final effective congestion window upper limit is determined as the mandatory stopping condition for TCP congestion window growth, and the updated rhythm sending rate is determined as the time interval benchmark for TCP packet sending.

[0205] S503. By coordinating the forced stop conditions and time interval benchmarks, the actual sending behavior of the preset TCP connection is constrained so that the actual sending behavior of the TCP connection is adapted to the bandwidth limit.

[0206] S501-S503 are similar to S406-S408, and will not be described again in this embodiment.

[0207] S504. Obtain the deviation between the actual sending rate of the TCP connection and the updated rhythm sending rate.

[0208] Specifically, in the TCP sender's protocol stack, the total number of data packets actually sent by the sending module within a preset period can be obtained. This total number can be divided by the period duration to obtain the actual sending rate. Then, the absolute value of the difference between the actual sending rate and the updated rhythm sending rate can be calculated. This absolute value can be divided by the updated rhythm sending rate to obtain the deviation between the actual sending rate and the rhythm sending rate. This step is used to obtain the deviation value between the actual sending behavior and the target sending rate, providing a quantitative basis for subsequent judgment on whether the constraint parameters need to be adjusted.

[0209] S505. When the duration of deviation exceeding the preset deviation threshold is greater than the preset time threshold, obtain the direction and degree of deviation, and adjust the preset constraint parameters in the layered window constraint according to the direction and degree of deviation so that the duration is less than the time threshold.

[0210] Specifically, the timing module within the TCP protocol stack can record the starting time when the deviation exceeds a preset deviation threshold. The duration is obtained by subtracting the starting time from the current time. This duration is then compared with a preset time threshold. When the duration is greater than the time threshold, the direction of the deviation is determined by comparing the actual sending rate with the updated rhythm sending rate. If the actual sending rate is greater than the rhythm sending rate, it is a positive deviation; otherwise, it is a negative deviation. The deviation value is used as the degree of deviation. If it is a positive deviation, the lower limit of the effective window range, the upper limit of system memory safety, and a specific multiple of BDP in the hierarchical window constraints are increased. If it is a negative deviation, the above constraint parameters are decreased. After adjustment, the final effective congestion window upper limit and rhythm sending rate are recalculated until the duration of the deviation exceeding the preset deviation threshold is less than the time threshold. This step is used to dynamically correct the parameters of the hierarchical window constraints when the actual sending behavior deviates from the target rate for a long time, so that the actual sending behavior of the TCP connection returns to the state of adapting to the bandwidth upper limit.

[0211] The technical effect of this solution in this embodiment is as follows: by monitoring the deviation between the actual transmission rate and the rhythmic transmission rate in real time, when the deviation continues to exceed the limit, the hierarchical window constraint parameters are dynamically adjusted according to the direction and degree of the deviation, thereby realizing closed-loop feedback and adaptive correction of the transmission behavior. This ensures that the actual transmission state can quickly return to the target range limited by the bandwidth limit, avoiding the loss of control of the transmission behavior due to long-term deviation. It solves the problem in the prior art of lacking an effective monitoring and dynamic correction mechanism for transmission rate deviation, which makes it difficult for the transmission behavior to continuously and stably adapt to the bandwidth limit.

[0212] Figure 6 is a flowchart illustrating one of the TCP congestion control methods provided in this application. In this embodiment, based on the embodiment provided in Figure 5, the TCP congestion control method is further explained. The TCP congestion control method includes:

[0213] S601. Obtain the deviation between the actual sending rate of the TCP connection and the updated rhythm sending rate.

[0214] S602. When the duration of deviation exceeding the preset deviation threshold is greater than the preset time threshold, obtain the direction and degree of deviation, and adjust the preset constraint parameters in the layered window constraint according to the direction and degree of deviation so that the duration is less than the time threshold.

[0215] S601-S602 are similar to S504-S505, and will not be described again in this embodiment.

[0216] S603. Obtain the fluctuation frequency and fluctuation amplitude of the bandwidth limit within a preset historical time period.

[0217] Specifically, the bandwidth limit value within a preset historical time period can be continuously collected at fixed time intervals in the bandwidth management module of the TCP protocol stack and stored in a circular buffer. The fluctuation frequency is obtained by dividing the number of times the bandwidth limit value in the buffer changes by the duration of the historical time period. Then, the difference between the maximum and minimum values ​​of the bandwidth limit in the buffer is calculated, and the fluctuation amplitude is obtained by dividing this difference by the average value of the bandwidth limit within the historical time period. This step is used to obtain the change characteristics of the historical bandwidth limit, providing a basis for subsequent adjustment of the change rate threshold and the minimum update interval.

[0218] S604. When the fluctuation frequency is greater than the preset fluctuation frequency threshold and the fluctuation amplitude is less than the preset fluctuation amplitude threshold, reduce the change rate threshold and shorten the minimum update interval.

[0219] Specifically, in the parameter adjustment module of the TCP protocol stack, the calculated fluctuation frequency is first compared with the preset fluctuation frequency threshold, and then the fluctuation amplitude is compared with the preset fluctuation amplitude threshold. When the fluctuation frequency is greater than the fluctuation frequency threshold and the fluctuation amplitude is less than the fluctuation amplitude threshold, the current rate of change threshold is multiplied by the preset downward adjustment coefficient to obtain the reduced rate of change threshold, and the current minimum update interval is multiplied by the preset shortening coefficient to obtain the shortened minimum update interval. Then, the adjusted rate of change threshold and minimum update interval are written into the rate control register of the protocol stack to replace the original parameters. This step is used to make the judgment condition of rate update more sensitive and the update cycle shorter in scenarios where bandwidth fluctuates frequently and slightly, so that the rhythm transmission rate can follow the bandwidth limit change more quickly.

[0220] S605. When the fluctuation frequency is less than the fluctuation frequency threshold and the fluctuation amplitude is greater than the fluctuation amplitude threshold, increase the change rate threshold and extend the minimum update interval.

[0221] Specifically, in the parameter adjustment module of the TCP protocol stack, the calculated fluctuation frequency is first compared with the preset fluctuation frequency threshold, and then the fluctuation amplitude is compared with the preset fluctuation amplitude threshold. When the fluctuation frequency is less than the fluctuation frequency threshold and the fluctuation amplitude is greater than the fluctuation amplitude threshold, the current rate of change threshold is multiplied by a preset upward adjustment coefficient to obtain the increased rate of change threshold, and the current minimum update interval is multiplied by a preset extension coefficient to obtain the extended minimum update interval. Then, the adjusted rate of change threshold and minimum update interval are written into the rate control register of the protocol stack to replace the original parameters and take effect. This step is used to increase the judgment threshold of rate update and extend the update cycle in scenarios with low-frequency and large fluctuations in bandwidth, so as to avoid frequent adjustments of the rhythm transmission rate due to instantaneous large fluctuations and improve the stability of transmission control.

[0222] The technical effect of this solution in this embodiment is as follows: by analyzing the fluctuation frequency and amplitude of the bandwidth upper limit within a historical time period, the change rate threshold and minimum update interval are adjusted in a targeted manner, so that the update strategy of the rhythm transmission rate can adaptively match the dynamic change characteristics of the bandwidth: when the bandwidth fluctuates frequently with small fluctuations, the response is accelerated, and when the bandwidth fluctuates at low frequencies with large fluctuations, the jitter is reduced, thereby making the rate update mechanism both sensitive and stable, avoiding response lag or frequent adjustments caused by a fixed update strategy, and solving the problem in the prior art where the rate update parameters are fixed and cannot be adaptively adjusted according to the bandwidth fluctuation characteristics, resulting in a difficulty in balancing response speed and stability.

[0223] Figure 7 is a flowchart illustrating one of the TCP congestion control methods provided in this application. In this embodiment, based on the embodiment provided in Figure 2, the TCP congestion control method is further explained. The TCP congestion control method includes:

[0224] S701. Obtain the historical smoothed RTT, historical effective MSS, historical bandwidth limit, historical congestion window limit, and historical rhythm transmission rate collected at a preset second time point; wherein, the second time point is earlier than the current time point.

[0225] Specifically, the storage entry corresponding to the second moment can be read from the historical parameter cache module of the TCP protocol stack according to the preset timestamp index. After the parameters are collected at the second moment, the protocol stack automatically writes the entry into the cache with a timestamp identifier. When reading, the corresponding storage location is located by matching the timestamp, and the historical smoothed RTT, historical effective MSS, historical bandwidth limit, historical congestion window limit, and historical rhythm transmission rate are extracted from it in sequence. This step is used to obtain the historical control parameters before the current moment, providing a data basis for subsequent judgment on whether to reuse historical parameters.

[0226] S702, obtain the current smoothed RTT, current effective MSS and current bandwidth limit at the current moment.

[0227] Specifically, in the real-time parameter acquisition module of the TCP protocol stack, the round-trip time of the current network link can be sampled multiple times and weighted by the RTT measurement unit to obtain the current smooth RTT. The maximum segment size after negotiation of the current link can be read from the MSS negotiation record of the TCP connection to obtain the current effective MSS. The physical link rate and the ratio of available bandwidth at the current moment can be read through the network interface driver. The two are multiplied to obtain the current bandwidth limit. The above three values ​​are synchronously stored in the real-time parameter register of the protocol stack. This step is used to obtain the basic network parameters at the current moment, providing real-time numerical basis for subsequent comparison of the rate of change with historical parameters.

[0228] S703. In response to the fact that the rate of change between the historical smoothed RTT and the current smoothed RTT is less than a preset first rate of change threshold, and the rate of change between the historical effective MSS and the current effective MSS is less than a preset second rate of change threshold, and the rate of change between the historical bandwidth limit and the current bandwidth limit is less than a preset third rate of change threshold, the historical congestion window limit is determined as the final effective congestion window limit, and the historical rhythm transmission rate is determined as the rhythm transmission rate applied at the current moment.

[0229] Specifically, in the parameter reuse judgment module of the TCP protocol stack, the rate of change between historical smoothed RTT and current smoothed RTT, the rate of change between historical effective MSS and current effective MSS, and the rate of change between historical bandwidth limit and current bandwidth limit can be calculated separately. Then, the three rates of change are compared with the corresponding first rate of change threshold, second rate of change threshold, and third rate of change threshold. When all three rates of change are less than their respective thresholds, the historical congestion window limit and historical rhythmic transmission rate are directly read from the historical parameter cache. The historical congestion window limit is written into the congestion control register as the final effective congestion window limit, and the historical rhythmic transmission rate is written into the transmission allocation module as the rhythmic transmission rate applied at the current moment. This step is used to directly reuse historical control parameters when the changes in network basic parameters are small, reducing redundant calculations and parameter update operations.

[0230] S704. Obtain smooth RTT, effective MSS, and bandwidth limit; where smooth RTT represents the transmission delay of the network path, effective MSS represents the maximum number of payload bytes carried by a single TCP packet, and bandwidth limit represents the maximum sending bandwidth of the TCP connection.

[0231] S705. Calculate the congestion window limit corresponding to the bandwidth limit based on the smoothed RTT, effective MSS, and bandwidth limit; whereby the congestion window limit corresponding to the bandwidth limit is used to represent the maximum congestion window used by the TCP connection under the bandwidth limit condition.

[0232] S706. Apply a hierarchical window constraint to the congestion window limit corresponding to the bandwidth limit to obtain the final effective congestion window limit; wherein, the final effective congestion window limit is used to limit the maximum congestion window actually used by the TCP connection.

[0233] S707. Calculate the first rhythm transmission rate and the rate of change between the first rhythm transmission rate and the preset second rhythm transmission rate based on the bandwidth limit; wherein, the first rhythm transmission rate is the rhythm transmission rate calculated based on the bandwidth limit, and the second rhythm transmission rate refers to the rhythm transmission rate applied at the current moment.

[0234] S708. When the rate of change is greater than a preset rate of change threshold and the first time difference is greater than or equal to the preset minimum update interval, the second rhythm transmission rate is updated to the first rhythm transmission rate so that the rhythm transmission rate applied at the current moment is adapted to the bandwidth limit; wherein, the first time difference refers to the time difference between the current moment and the first moment, and the first moment refers to the rhythm rate update moment that is closest to the current moment before the current moment.

[0235] S704-S708 are similar to S201-S205, and will not be described again in this embodiment.

[0236] The technical effect of this solution in this embodiment is that by comparing the rate of change of network parameters at the current time with that at historical time, the historical calculation results can be directly reused when the network state is stable and the parameter fluctuations are small. This avoids repeatedly calculating the congestion window upper limit and the rhythm transmission rate, reduces unnecessary computational overhead and parameter update frequency, and makes the control logic lighter and more stable. It solves the problem in the prior art that parameter calculation and updates are frequently performed regardless of whether the network state changes, resulting in wasted computing resources and decreased control stability.

[0237] Some existing algorithms for implementing TCP congestion control include:

[0238] 1. The foundation and representative algorithms of TCP congestion control:

[0239] 1.1 Reno / NewReno.

[0240] Reno and NewReno adjust the congestion window (cwnd) through additive increase (AI) and multiplicative decrease (MD), relying on signals such as packet loss / triple ACK for congestion determination. This type of algorithm has a simple structure and is easy to implement, but it has slow convergence and low utilization on high bandwidth-delay product (BDP) links, and is highly sensitive to latency.

[0241] 1.2BIC / CUBIC (RFC8312, etc.).

[0242] CUBIC uses a cubic function to drive cwnd growth, offering higher throughput and better fairness compared to the Reno series in high BDP (Browser-Driven Processing) links. Its approach is to adjust the growth curve according to a cubic function of time dimension t, using the previous maximum window as the origin; after a congestion event, it enters a new epoch and readjusts the curve. CUBIC is the long-term default algorithm in Linux, supporting HybridSlowStart (HyStart / HyStart++) to reduce congestion during startup. Its key features include time-driven window adjustment (rather than ACK count-driven), significant gains in high BDP environments, HyStart to improve slow start exit timing, and no inherent strong constraint mechanism on a "fixed bandwidth limit".

[0243] 1.3 Westwood / HTCP / YeAH, etc.

[0244] These algorithms typically focus on fine-tuning congestion window size (cwnd) or ssthresh from the perspectives of bandwidth estimation and RTT variation, achieving a better throughput / latency tradeoff in wireless and long-bandwidth environments. A common characteristic is that they do not transform the "externally specified bandwidth limit" into a unified upper bound for the congestion window, but instead focus on network measurements and end-to-end estimation.

[0245] 1.4BBR (Bottleneck Bandwidth, RTT).

[0246] BBR constructs a link model by estimating the bottleneck bandwidth and minimum RTT, and uses pacing and windowing to constrain the data plane rate, breaking the traditional assumption that packet loss equals congestion. It models and controls the transmission rate, emphasizing queue minimization and throughput maximization. Although BBR uses pacing, its goal is not to enforce an "external fixed bandwidth cap," but rather to adaptively explore and maintain the model rate.

[0247] 2. TCPpacing and kernel-related mechanisms:

[0248] 2.1 Overview of TCPpacing.

[0249] The Linux kernel introduces sk_pacing_rate and rhythmic scheduling capabilities based on queue rules (such as sch_fq), allowing the sending side to smoothly send packets at a target rate. The kernel can estimate a pacing rate based on cwnd and RTT, or the user space can specify an upper limit through SO_MAX_PACING_RATE, making the packet sending process uniform and reducing queuing and latency caused by bursts.

[0250] 2.2 Application / System Layer Rate Limiting.

[0251] In addition to kernel congestion control, common bandwidth control methods include:

[0252] TC queue rule rate limiting (such as TBF / HTB): Limits the rate at the device / queue level.

[0253] Policer / Shaper (tokenbucket, etc.): Controls peak and average traffic rates.

[0254] Application-level rate limiting: Control the send() rate or SO_MAX_PACING_RATE in user space.

[0255] The above methods are usually decoupled from TCP congestion control, making it difficult to achieve fine linkage with the evolution of cwnd, and there is a trade-off between overhead and accuracy in scenarios with multiple RTT / MSS changes and sudden events.

[0256] 3. Existing solutions similar to this application are:

[0257] 3.1 CUBIC + pacing (fq) + user-space maximum rate (SO_MAX_PACING_RATE) is a common combination in engineering. Congestion control is still driven by CUBIC (cwnd grows with the curve or shrinks due to congestion events); under queuing rules that support pacing, such as sch_fq, the kernel sends packets evenly according to sk_pacing_rate or SO_MAX_PACING_RATE; when "rate limiting" is needed, the user space can set the maximum pacing rate, or tc can be used to limit the rate at the device layer. Main structure and steps: CUBIC routine initialization and slow start / congestion avoidance, pacing rate derived / estimated based on RTT and cwnd, or the maximum rate limit set by the user space, and qdisc sending packets in time slices according to the rate. The limitations of this scheme are:

[0258] The "bandwidth limit" is not systematically converted into a unified upper bound for cwnd. When only the pacing limit is set without processing the upper bound for cwnd, the window curve may still continue to grow at the algorithm level (only suppressed by the actual sending rate), resulting in inconsistency between the window and the rate. The system does not provide combined constraints such as the lower bound (floor) for window effectiveness under low RTT, the fairness upper bound for the BDP multiple, and the memory protection upper bound. The change threshold and cache recalculation strategy are missing, which can easily generate unnecessary calculations or update jitter in hot paths. The system does not define a progressive alignment and epoch reset strategy for snd_cwnd when the upper bound decreases.

[0259] 3.2 Combination of BBR and pacing.

[0260] BBR uses model rate for pacing and window constraints, providing queue control and latency-friendly characteristics. Unlike external "fixed bandwidth caps," BBR's target rate is derived from network measurements and models, rather than being a strict enforcement of an external target cap. Therefore, in scenarios requiring "enforcing bandwidth limits (ceilings) according to external policies," BBR is not the most suitable solution.

[0261] 3.3 Combining HyStart / HyStart++ with CUBIC.

[0262] Linux CUBIC already supports the HyStart family to improve the timing of slow start exits, but this part does not involve the conversion of "external bandwidth limit → cwnd upper bound", nor does it specify the pacing upper limit threshold update and cache recalculation strategy.

[0263] The three existing TCP congestion control schemes can be compared and evaluated from six dimensions: unification of external bandwidth limit and cwnd, low RTT window effectiveness limitation, fairness / memory limit, pacing limit threshold update, caching and recalculation suppression control, and window alignment strategy for limit decrease.

[0264] 1. CUBIC+fq (with SO_MAX_PACING_RATE): In terms of unifying the external bandwidth limit and cwnd, it only sets the pacing rate limit in user space, usually limiting the rate without upper and lower limit constraints to support cwnd; there are no mechanisms related to limiting the validity of low RTT windows; there is no fair / memory limit unification strategy; pacing limit threshold updates usually do not involve direct write values; there are no caching and recalculation suppression control mechanisms; there is no window alignment strategy for limit decrease.

[0265] 2. BBR: Regarding the unification of external bandwidth limit and cwnd, it does not rely on an external limit, but rather adapts through model adaptation, without an external upper limit (ceiling); in terms of low RTT window effectiveness limits, some models maintain a minimum queue limit (floor), but do not have a fixed lower limit (floor); fairness / memory limits are related to the model / implementation; pacing upper limit threshold updates are adjusted through algorithmic intrinsic rate; caching and recalculation suppression control are internal model mechanisms; the window alignment strategy for upper limit descent is algorithmic intrinsic.

[0266] 3. Device Layer Shaping (TBF / HTB): Regarding the unification of external bandwidth limit and cwnd, the device layer is decoupled from TCP and no related unification is performed; there is no related mechanism for limiting the effectiveness of low RTT windows; there is no fair / memory limit, which needs to be configured separately; there is no related mechanism for updating the pacing limit threshold; there is no related mechanism for caching and recalculation suppression control; there is no window alignment strategy for limit reduction.

[0267] The closest solution (CUBIC+fqpacing+SO_MAX_PACING_RATE) provides smooth packet sending and user-space rate limiting capabilities, but it does not systematically map the "bandwidth limit" to the upper bound of cwnd, and it also lacks a combination mechanism such as a low RTT limit lower bound (floor), fair / memory limit and threshold recalculation.

[0268] Existing CUBI CTCP achieves high throughput and fairness on high bandwidth-delay product (BDP) links using cube function-driven window growth. However, it suffers from the following shortcomings in real-world production environments:

[0269] Configurable bandwidth caps need to be imposed on connections to meet tenant isolation, cost control, or provisioning strategies.

[0270] Relying solely on the congestion window may result in sudden transmissions, affecting queuing delays and jitter.

[0271] Carelessness during the startup phase can easily lead to queue expansion, resulting in a surge in latency.

[0272] Frequent calculations caused by changes in RTT, MSS, and dynamic configuration can easily lead to performance overhead.

[0273] In environments with extremely low RTT (<1ms), BDP is very small, and the small window leads to low TCP transmission efficiency.

[0274] This application proposes structural improvements in the following aspects:

[0275] Bandwidth cap converted to cwnd cap: Use BDP (combining smooth RTT and effective MSS) to convert max_bandwidth to snd_cwnd_clamp, and freeze growth after the CUBIC curve reaches the upper limit, so that the window and rate form a consistent upper limit.

[0276] Layered constraints: On top of cwnd_cap, low RTT special cases (lower and upper limits), fairness BDP multiple upper limit, and memory protection upper limit are superimposed to form a combined safety / fair boundary.

[0277] The pacing upper limit threshold is updated only when the change ratio exceeds the threshold and the minimum update interval is reached, thus reducing jitter and hot path overhead.

[0278] Caching and threshold recalculation: Set thresholds and caches for RTT / BW / MSS and time intervals to reduce the cost of recalculating per ACK.

[0279] Upper and lower bound constraints (clamping) and alignment: Define the strategies of up-adjustment suppression and single-step maximum up-adjustment, down-adjustment asymptotic convergence and epoch reset to enable the window to quickly and smoothly align with the upper bound when the outer upper bound changes.

[0280] Startup bandwidth factor: Allows initial cwnd / ssthresh settings based on bandwidth limits, avoiding sudden spikes or slowdowns during startup.

[0281] This application can achieve the following: implement a strict configurable bandwidth limit (ceiling) for the single connection transmission rate, smooth transmission with pacing to reduce burst and queuing latency, improve the stability of the startup phase with HyStart, avoid excessive occupation through fairness and memory limit protection, provide effective window lower limit constraints for special scenarios such as ultra-low RTT, and reduce hot path calculation overhead by adopting parameter caching and threshold recalculation strategies.

[0282] TCP congestion control methods can achieve the following steps:

[0283] S1. Parameter acquisition and effective MSS selection, obtain smoothed RTT (priority: smoothed value > SRTT > minimum RTT > default RTT), obtain effective MSS (combining IPv4 / IPv6 lower limit and optional upper limit).

[0284] S2.BDP Calculation and Bandwidth Limit Conversion:

[0285] If the maximum bandwidth max_bandwidth (bps) is configured, convert BDP using the following formula:

[0286] BDP_bits=max_bandwidth×RTT_us / 1000000; BDP_bytes=BDP_bits / 8.

[0287] cwnd_cap=floor(BDP_bytes / MSS)×bw_compensation_factor%.

[0288] If no bandwidth limit is configured, no cwnd limit is set (it is considered unlimited).

[0289] S3. Window upper limit layer constraint:

[0290] Low RTT Special Case: When RTT < 1ms, the cwnd is limited to the range [max(min_effective_cwnd, 1), max_bandwidth / (MSS×8×low_rtt_cap_divisor)].

[0291] Minimum bandwidth limit at runtime (floor) (optional): If enabled and min_bandwidth≤max_bandwidth, ensure that cwnd is not less than the number of packets corresponding to its BDP.

[0292] Fairness cap: cwnd≤(BDP_packets×bdp_cwnd_factor_permil / 1000), and a lower limit is set for the number of packets for very small BDPs.

[0293] Memory protection: cwnd ≤ memory_cwnd_cap.

[0294] S4. Rhythm Sending Upper Limit Write:

[0295] If pacing mode 2 is enabled, sk_max_pacing_rate is set to max_bandwidth / 8 (B / s) according to the threshold strategy. The refresh is only performed when the relative change exceeds the threshold and the interval reaches the minimum update time, so as to reduce jitter and overhead.

[0296] S5. Startup Phase Settings (Optional):

[0297] If ss_bandwidth_factor > 0 and there is a bandwidth limit, the initial congestion window and slow start threshold (ssthresh) are determined by stepping or jumping directly to the bandwidth limit.

[0298] S6. Dynamic up / down adjustment of clamp and its activation:

[0299] Calculate the new snd_cwnd_clamp and compare it with the old value:

[0300] Up-regulation: Suppresses small changes (hysteresis) and limits the maximum percentage of each up-regulation.

[0301] Downward adjustment: When the decrease in the new and old clamps exceeds the threshold, gradually converge snd_cwnd to the new clamp by step size, and reset CUBICepoch to readjust the growth curve.

[0302] S7. Caching and Threshold Recalculation:

[0303] Record the MSS, RTT, bandwidth, and timestamp of the last calculation.

[0304] The recalculation limit is set when any of the following conditions are met: generational parameter change, reaching the minimum recalculation interval, or relative change in bandwidth / RTT / MSS exceeding the threshold.

[0305] S8. Congestion Avoidance and HyStart:

[0306] If you are in the slow start phase, use HyStart (ACK-train and / or delay trigger) to exit slow start early and set ssthresh.

[0307] During the congestion avoidance phase, CUBIC cube growth is used, but window growth is stopped (frozen) when snd_cwnd≥snd_cwnd_clamp.

[0308] This application also provides a TCP congestion control system, including:

[0309] (1) BDP calculation module: converts the bandwidth limit and RTT into the congestion window limit.

[0310] (2) Window constraint module: Implements low RTT special case, minimum bandwidth limit (floor) during runtime, upper limit of fairness and memory protection.

[0311] (3) Rhythm sending module: Threshold update of pacing upper limit.

[0312] (4) Startup phase module: Set the initial cwnd and ssthresh according to the bandwidth factor.

[0313] (5) Upper and lower limit constraint (clamping) adjustment module: realizes the smoothing and forced alignment of snd_cwnd_clamp up / down adjustment.

[0314] (6) Cache recalculation module: Determine whether to recalculate based on time / threshold / generation.

[0315] (7) HyStart module: Hybrid slow start exit determination based on ACK-train and time delay.

[0316] The system also includes: TCP protocol stack, queuing rules (such as fq), network card driver and application. The device is integrated into the TCP congestion control plugin, and manages the socket's snd_cwnd, snd_cwnd_clamp and sk_max_pacing_rate through the kernel interface.

[0317] Valid MSS is preferentially used based on cached values, and the corresponding lower limit is applied according to the IPv4 / IPv6 protocol family. An upper limit can also be configured to avoid abnormally large MSS. BDP calculation uses 64-bit secure operation to prevent overflow. The window upper limit is determined by superimposing the four layers of constraints in order. HyStart supports ACK-training and latency triggering. If the threshold is exceeded, slow start is exited and ssthresh is set to the current cwnd. Pacing refreshes the upper limit only when the relative change exceeds the threshold and meets the minimum update time to reduce jitter. When adjusting the clamping, a small ignore threshold and the maximum single-step increase ratio are set when adjusting upwards. When adjusting downwards, snd_cwnd is decreased by step size to the new upper limit and the epoch is reset. RTT uses weighted smooth update, and the first batch of samples converges faster. The cache records MSS, RTT, bandwidth, timestamp and generation information, and recalculates according to the threshold to avoid performing full calculation for each ACK.

[0318] The device capable of TCP congestion control can be implemented as a kernel module or a congestion control plugin statically compiled into the kernel. It integrates the aforementioned functional modules, configures bandwidth limits, various thresholds and control strategies through the kernel parameter interface, and provides system observability through tracepoints and logs. The system as a whole consists of the application layer, TCP protocol stack, congestion control device, queue rules and network interface card. The congestion control device, as a pluggable TCP algorithm, interacts with other kernel modules through socket fields to complete the coordinated control of window and rate.

[0319] The TCP congestion control system can provide a strongly constrained, configurable bandwidth limit and maintain stability and fairness under the CUBIC curve. Pacing smooths transmission, significantly reducing burst and queuing latency. HyStart improves latency and packet loss during startup. It ensures window effectiveness under ultra-low RTT to avoid efficiency collapse. It reduces hot path computation overhead through caching and threshold recalculation strategies. Fairness and memory limits protect system stability.

[0320] max_bandwidth: is the upper limit of bandwidth, in bits per second (bps). When the value is 0, it means that there is no bandwidth limit. It is the core constraint for window and rate calculation.

[0321] min_bandwidth: This is the minimum bandwidth, measured in bits per second (bps). It is an optional configuration item that can be converted to a window lower limit to ensure the minimum transmission capacity of the connection.

[0322] bw_compensation_factor: This is the bandwidth compensation percentage, with a default value of 100%. It is used to proportionally correct the mapping from BDP to cwnd to compensate for non-ideal characteristics of the link.

[0323] bdp_cwnd_factor_permil: This is the fairness cap factor, expressed in per mille (e.g., 3000 represents 3 × BDP). It is used to limit the window to a multiple of BDP to achieve fair resource allocation in multi-user scenarios.

[0324] memory_cwnd_cap: This is the upper limit of memory protection, measured in packets. It sets an upper limit on the window based on system memory and security requirements to prevent excessive resource consumption and ensure system stability.

[0325] low_rtt_cap_divisor: is the denominator of the low RTT upper bound. It is used to calculate the upper limit of the window when the RTT is extremely small, adapting to the window constraint requirements in low latency scenarios.

[0326] ss_bandwidth_factor and init_ssthresh_factor_permil are startup-related factors. The former is used to guide the initial window with the bandwidth limit, while the latter sets the slow start threshold (ssthresh) according to the initial cwnd, which is used to optimize the window growth strategy during the slow start phase.

[0327] pacing_mode and pacing_update_thresh_permil are pacing refresh strategies. The former is used to set the rhythm sending mode, and the latter is used as the rate update threshold. The pacing rate is only refreshed when the relative change exceeds the threshold to avoid frequent updates.

[0328] cap_recompute_min_interval_ms and rtt_recompute_thresh_permil are parameters related to the recompute strategy. The former limits the minimum time interval for parameter recompute, while the latter triggers recompute when the relative change in RTT exceeds this threshold. This is used to prevent calculations from being too frequent and to ensure that parameters are updated in a timely manner.

[0329] params_generation: is the parameter generation marker, used for cache invalidation broadcasting, low 8 bits aligned, used for cache consistency management of parameter updates.

[0330] snd_cwnd and snd_cwnd_clamp are the congestion window and its clamping limit, respectively. The former is the size of the packet window that the sender can currently fly, and the latter is the global window limit, which is used to prevent excessive window growth and excessive resource consumption.

[0331] TCP congestion control methods can be applied to data center links. In this scenario, the parameters are 10Gbps, RTT=200µs, IPv4MSS=1460, max_bandwidth=10,000,000,000, and bw_compensation_factor=100%.

[0332] Calculation: BDP_bits=10,000,000,000×200×0.000001=2000000bits, BDP_bytes=250000, cwnd≈250000 / 1460≈171.

[0333] Low RTT special case: 200µs<1ms, bw_based_limit≈10000000000 / (1460×8×1000)≈855, floor≥1, 171 is within the interval, no adjustment.

[0334] Fairness and memory limit: 3×BDP≈513, memory limit 65535, final cwnd limit≈171.

[0335] Behavior: CUBIC is frozen after increasing to 171; pacing limit is set to (10000000000 / 8) B / s, and fq is used for smooth packet sending.

[0336] TCP congestion control methods can also be applied to wide area network links. In this scenario, the parameters are 100Mbps, RTT=30ms, MSS=1460, and max_bandwidth=100000000.

[0337] Calculation: BDP_bits = 100000000 × 0.03 = 3000000 bits; BDP_bytes = 375000; cwnd ≈ 375000 / 1460 ≈ 257.

[0338] The fairness cap is approximately 771, the memory cap is not triggered, and the final cwnd is approximately 257.

[0339] If ss_bandwidth_factor=100 (10 steps) is enabled, the initial cwnd transitions between the minimum and the upper limit in stages.

[0340] The pacing limit is approximately 12.5 MB / s.

[0341] TCP congestion control methods can also be applied to ultra-low bandwidth and extremely low RTT, in this scenario: 1Mbps, RTT=100µs, MSS=1460, max_bandwidth=1000000.

[0342] Calculation: BDP_bits = 1000000 × 0.0001 = 100 bits; BDP_bytes = 12.5; cwnd ≈ 0.

[0343] Low RTT special case applies: floor≥1, bw_based_limit≈0.085, cwnd=1 after clamping.

[0344] Effect: Maintains effective transmission even in extreme scenarios, avoiding window collapse.

[0345] The classification and configuration guidelines for adjustable parameters of TCP congestion control methods during the engineering implementation phase are as follows:

[0346] Bandwidth parameters: These are the core constraints (maximum / minimum bandwidth) and bandwidth compensation coefficients used to configure link bandwidth. They are the basic inputs for BDP calculation and setting the upper and lower limits of the window. Among them, max_bandwidth is the upper limit of the link bandwidth (bps, 0 means unlimited), min_bandwidth is the optional minimum guaranteed bandwidth during runtime (bps), and bw_compensation_factor is the bandwidth compensation percentage (default 100%), which is used to correct the mapping ratio from BDP to the congestion window.

[0347] RTT / Recalculation Parameters: Define the triggering conditions and time limits for RTT baseline values ​​and parameter recalculation, used to control the frequency of parameter recalculation and avoid invalid calculations; where default_rtt_us is the default round-trip time (microseconds), cap_recompute_min_interval_ms is the minimum time interval for parameter recalculation (milliseconds), and rtt_recompute_thresh_permil is the threshold (per millisecond) for triggering recalculation based on relative changes in RTT.

[0348] Startup parameters: These cover all configuration items for the slow start phase, used to optimize the window growth strategy during startup and improve startup latency and packet loss. Among them, ss_bandwidth_factor is the startup bandwidth factor (guiding the initial window), init_ssthresh_factor_permil is the initial slow start threshold factor (per mille), hystart is the HyStart function switch, hystart_detect is the ACK flow detection mode, hystart_low_window is the minimum window to trigger HyStart, and hystart_ack_delta_us is the ACK interval threshold (microseconds).

[0349] Window protection parameters: These cover multi-dimensional window constraint configurations to ensure window effectiveness, system stability, and fairness among multiple users. Among them, bdp_cwnd_factor_permil is the fairness cap factor (per mille), fairness_cap_floor_packets is the minimum fairness cap (number of packets), memory_cwnd_cap is the memory protection cap (number of packets), min_effective_cwnd is the minimum effective window, enable_low_rtt_special is the low RTT special case enable switch, low_rtt_cap_divisor is the low RTT window cap divisor, and enable_runtime_min_bw_floor is the minimum bandwidth enable switch.

[0350] The pacing parameters configure the rhythm sending mode and rate update threshold to achieve smooth packet sending and reduce rate update jitter. Among them, pacing_mode is the rhythm sending mode, and pacing_update_thresh_permil is the rate update threshold (per mille). The pacing limit is refreshed only when the relative change exceeds this threshold.

[0351] MSS Limit Parameters: Set the upper and lower limits of the maximum segment size under different protocol families to ensure that the MSS value is reasonably adapted to the network scenario; where mss_upper_bound is the upper limit of MSS, mss_lower_bound_v4 is the lower limit of MSS under the IPv4 protocol, and mss_lower_bound_v6 is the lower limit of MSS under the IPv6 protocol.

[0352] Clamping adjustment parameters: Define the triggering conditions, adjustment step size, and forced switch for adjusting the congestion window up and down to achieve smoothness and forced alignment of the window's upper and lower limits; where enforce_cwnd_downclamp is the forced downclamp switch, cwnd_downclamp_thresh_permil is the window downclamp trigger threshold (per mille), cwnd_downclamp_step_permil is the maximum downclamp ratio in a single step (per mille), cwnd_upclamp_thresh_permil is the window upclamp ignore threshold (per mille), and cwnd_upclamp_step_permil is the maximum upclamp ratio in a single step (per mille).

[0353] Generation control parameters: Cache invalidation broadcasting is implemented through parameter version flags to ensure cache consistency after parameter updates; where params_generation is the parameter generation flag (lower 8 bits aligned) used for cache invalidation broadcasting.

[0354] When the bandwidth cap parameter `max_bandwidth` is set to 0, this application automatically degenerates into a mode without bandwidth cap constraints, maintaining the native behavior of the CUBIC algorithm. Fairness cap or memory protection parameters can be set to zero to disable them, adapting to specific application scenarios that do not require such constraints. Even in non-fq queue rule (qdisc) environments, write operations on the pacing cap can still be constrained by other schedulers. If the memory protection cap parameter `memory_cwnd_cap` is set too low, it can easily lead to underutilization of link resources; a value of no less than 16 is recommended. The default round-trip time parameter `default_rtt_us` should not be set too low, otherwise it will cause the initial bandwidth-delay product (BDP) estimate to be too small, affecting the accuracy of window and rate calculations. This application is suitable for multi-tenant rate capping and fairness control in data centers, fine-grained rate limiting for broadband access or interconnection exits, effective throughput guarantees in ultra-low RTT scenarios, and online services requiring smooth transmission to reduce tail latency.

[0355] Figure 8 is a block diagram of the TCP congestion control system structure provided in the embodiment of this application. As shown in Figure 8, the application sends data through the TCP protocol stack, and the congestion control device manages the window and pacing within the protocol stack. The qdisc is smoothly allocated to the network card according to sk_max_pacing_rate.

[0356] Figure 9 is a flowchart of one of the TCP congestion control methods provided in the embodiments of this application. As shown in Figure 9, firstly, core parameters such as RTT, MSS, and bandwidth configuration are collected; then, the bandwidth-delay product (BDP) is calculated and converted to obtain the upper limit of the congestion window (cwnd) with compensation; subsequently, the window is constrained by four layers of constraints: low RTT special case, minimum bandwidth floor, fairness, and memory; then, the upper limit sk_max_pacing_rate is updated according to the threshold; during the startup phase, cwnd and slow start threshold (ssthresh) are initialized, and the window is adjusted smoothly and with forced alignment; through generational, time, and threshold-triggered caching and recalculation mechanisms, finally, the CUBIC slow start, congestion avoidance, and upper limit freezing logic are executed to complete the congestion control process.

[0357] Figure 10 is a schematic diagram of the TX_START event interaction provided in the embodiment of this application. As shown in Figure 10, after the application calls send() to write data and triggers the CA_EVENT_TX_START event, TCP passes the event to the cubiclimit congestion control module. The module first evaluates whether the generation, time, or threshold conditions are met to trigger parameter recalculation, and then updates snd_cwnd_clamp. If the upper limit is detected to decrease and the corresponding threshold is triggered, snd_cwnd is gradually reduced and the epoch of the CUBIC algorithm is reset. At the same time (optionally), sk_max_pacing_rate is set. Finally, the data is enqueued into Qdisc(fq) according to the pacing rate for allocation. This TX_START timing can effectively de-jitter update the pacing upper limit and realize fast convergence of window clamping and curve readjustment.

[0358] Figure 11 is a flowchart of the clamping up and down adjustment process provided in the embodiment of this application. As shown in Figure 11, the clamping values ​​of the new and old windows are first calculated, and it is determined whether the new value is greater than the old value. If the new value is greater than the old value (up adjustment scenario), it is further determined whether the relative increase is less than the up adjustment threshold. If it is less, the small up adjustment is ignored. If it is greater, the maximum single-step up adjustment is performed. If the new value is not greater than the old value (down adjustment scenario), it is determined whether the difference between the new and old values ​​is greater than the down adjustment threshold. If it is greater, snd_cwnd is gradually reduced to the new value and the CUBIC epoch is reset. If it is less, it is maintained or fine-tuned. By suppressing the up adjustment and gradually reducing the down adjustment, oscillations and sudden changes are avoided, and smoothness and stability are ensured.

[0359] Figure 12 is a low RTT special case diagram provided in the embodiment of this application. As shown in Figure 12, the low RTT special case processing flow first determines whether the current RTT is less than 1ms. If it is less than 1ms, the special case processing logic is entered: first, the lower limit of the window floor=max(min_effective_cwnd,1) is calculated, then the upper limit of the window max(bw / (MSS×8×divisor)) is calculated, and finally the congestion window cwnd is sandwiched between BDP_pkts, floor and the upper limit; if the RTT is not less than 1ms, the normal path is entered, so as to avoid the window deteriorating to an invalid value in the ultra-low RTT scenario, and at the same time make the window constrained by the bandwidth limit.

[0360] Figure 13 is a schematic diagram of caching and recalculation provided in the embodiment of this application. As shown in Figure 13, the caching and recalculation strategy first reads information such as MSS, RTT, max_bw, timestamp, and generation from the cache. Then, it sequentially judges whether the generation has changed, whether the minimum recalculation interval has been reached, and whether the relative change of RTT / BW / MSS is ≥ the threshold. If any condition is met, recalculation is triggered. If none of them are met, the upper limit of the cache is reused. In this way, hot path calculation and lock contention are reduced through caching and thresholded recalculation.

[0361] Figure 14 is a schematic diagram of the deployment and working path of the cubiclimit congestion control plugin provided in the embodiment of this application. As shown in Figure 14, the working path of the kernel congestion control plugin (cubiclimit) is as follows: the application layer initiates data transmission, and transmits the congestion window (snd_cwnd) and window clamp information to the cubiclimit congestion control module via TCP socket; after the module completes the window and rate calculation based on the socket field, it sets the pacing upper limit (sk_max_pacing_rate) and transmits the data to the fair queue scheduler (qdiscfq). Finally, the network interface card (NIC) completes the physical layer data transmission and reception, thereby realizing the constraint and guidance of window and pacing.

[0362] This application presents a comprehensive solution that systematically maps the external bandwidth limit to `snd_cwnd_clamp` and integrates it with mechanisms such as hierarchical constraints, pacing debouncing, clamping smoothing, and cache recalculation. It also details the specific parameterization and interaction logic of each key module. Key points include:

[0363] (1) Dynamic mapping and freezing mechanism from bandwidth limit to unified upper bound of congestion window.

[0364] The external maximum bandwidth `max_bandwidth` is constrained by the data plane using BDP = BW × RTT, and combined with "smooth RTT priority (smooth_rtt > srtt > delay_min > default) + effective MSS selection (IPv4 / IPv6 lower limit and optional upper limit)" to calculate `snd_cwnd_clamp`. CUBIC growth freezes once it reaches this upper limit, forming a single upper limit (ceiling) where "the rate upper limit and the window upper limit are consistent." The window curve is consistent with the rate constraint, avoiding the inconsistency and sudden changes of "limited speed but the window continues to grow"; it maintains consistency under changes in RTT / MSS.

[0365] (2) Layered window constraint stack (low RTT special case + fairness multiple + memory protection + optional minimum bandwidth limit at runtime (floor)).

[0366] Feature: Overlaid on top of cwnd_cap:

[0367] Low RTT Special Case: When RTT < 1ms, the number of BDP packets is clamped by floor = max(min_effective_cwnd, 1) and upper bound = max_bw / (MSS × 8 × low_rtt_cap_divisor).

[0368] The upper limit of the fairness multiplier is: cwnd≤BDP_packets×bdp_cwnd_factor_permil / 1000, and the minimum upper limit of fairness_cap_floor_packets is used when BDP≈0.

[0369] Memory protection limit: cwnd ≤ memory_cwnd_cap.

[0370] Optional minimum bandwidth limit (floor): When enabled and min_bandwidth≤max_bandwidth, use the number of BDP packets as the lower limit of cwnd.

[0371] Technical effect: In scenarios with ultra-low RTT, small BDP, or large windows, it comprehensively balances effectiveness, fairness, and memory safety, avoiding window failure or excessive memory usage.

[0372] (3) Thresholding update mechanism for rhythm transmission upper limit (anti-shake and frequency control).

[0373] Feature: Write sk_max_pacing_rate=max_bandwidth / 8 only if the relative change is greater than or equal to pacing_update_thresh_permil and the minimum update time of cap_recompute_min_interval_ms has elapsed; otherwise, delay the update.

[0374] Technical benefits: Significantly reduces jitter and overhead caused by frequent write speeds, and makes pacing and the upper bound of the window work together without becoming noisy.

[0375] (4) Smooth alignment and epoch re-adjustment of clamping up / down adjustment.

[0376] feature:

[0377] Upgrade: Set a small change suppression threshold cwnd_upclamp_thresh_permil and limit the maximum upgrade ratio in a single step cwnd_upclamp_step_permil;

[0378] Downward adjustment: When the new upper bound is significantly lower than the old value (relative decrease ≥ cwnd_downclamp_thresh_permil), gradually converge snd_cwnd to the new upper bound by cwnd_downclamp_step_permil, and reset CUBICepoch to readjust the growth curve.

[0379] Technical effect: It can quickly align with the upper limit when there are fluctuations, while avoiding violent window oscillations or sudden bursts.

[0380] (5) A caching and threshold recalculation framework for hot paths.

[0381] Features: cap_cached_cwnd is formed based on connection cache {MSS, RTT, max_bw, timestamp, generation}. Recalculation is triggered when the generation change params_generation is met, the minimum recalculation interval is exceeded, or the relative change of BW / RTT / MSS is greater than or equal to the threshold; otherwise, the cache is reused.

[0382] Technical effect: Reduces the computation and write cost of per-ACK while maintaining adaptability, and improves the performance of hotspot paths.

[0383] Figure 15 is a schematic diagram of the TCP congestion control device provided in an embodiment of this application. As shown in Figure 15, the TCP congestion control device includes:

[0384] The first acquisition module 1501 is used to acquire smooth RTT, effective MSS, and bandwidth limit; wherein, smooth RTT is used to represent the transmission delay of the network path, effective MSS is used to represent the maximum number of effective payload bytes carried by a single TCP packet, and bandwidth limit is used to represent the maximum sending bandwidth of the TCP connection.

[0385] The first calculation module 1502 is used to calculate the congestion window limit corresponding to the bandwidth limit based on the smoothed RTT, effective MSS and bandwidth limit; wherein, the congestion window limit corresponding to the bandwidth limit is used to represent the maximum congestion window used by the TCP connection under the bandwidth limit condition.

[0386] The first constraint module 1503 is used to apply hierarchical window constraints to the congestion window upper limit corresponding to the bandwidth upper limit to obtain the final effective congestion window upper limit; wherein, the final effective congestion window upper limit is used to limit the maximum congestion window actually used by the TCP connection.

[0387] The second calculation module 1504 is used to calculate the first rhythm transmission rate and the rate of change between the first rhythm transmission rate and the preset second rhythm transmission rate based on the bandwidth limit; wherein, the first rhythm transmission rate is the rhythm transmission rate calculated based on the bandwidth limit, and the second rhythm transmission rate refers to the rhythm transmission rate applied at the current moment.

[0388] The update module 1505 is used to update the second rhythm transmission rate to the first rhythm transmission rate when the rate of change is greater than a preset rate of change threshold and the first time difference is greater than or equal to the preset minimum update interval, so that the rhythm transmission rate applied at the current moment adapts to the bandwidth limit; wherein, the first time difference refers to the time difference between the current moment and the first moment, and the first moment refers to the rhythm rate update moment that is closest to the current moment before the current moment.

[0389] In one possible design, the first computing module 1502 includes:

[0390] The first calculation unit is used to calculate the bandwidth-delay product based on the smoothed RTT and the bandwidth limit; wherein the bandwidth-delay product is used to represent the maximum amount of data transmitted simultaneously on the network link.

[0391] The second calculation unit is used to calculate the congestion window limit corresponding to the bandwidth limit based on the bandwidth-delay product and the effective MSS.

[0392] In one possible design, the first constraint module 1503 includes:

[0393] The first constraint unit is used to apply an RTT scenario constraint to the upper limit of the congestion window corresponding to the upper limit of the bandwidth limit when the smoothed RTT is less than the preset RTT threshold, so as to obtain the first upper limit; wherein, the RTT scenario constraint refers to adjusting the upper limit of the congestion window corresponding to the upper limit of the bandwidth limit to the preset effective window range.

[0394] The second constraint unit is used to apply a fairness constraint to the first upper limit to obtain a second upper limit; wherein, the fairness constraint refers to adjusting the first upper limit so that the first upper limit does not exceed a preset multiple of BDP.

[0395] The third constraint unit is used to apply memory protection constraints to the second upper limit to obtain the final effective congestion window upper limit; wherein, the memory protection constraint refers to adjusting the second upper limit so that the second upper limit does not exceed the preset system memory safety upper limit value.

[0396] In one possible design, the first constraint module 1503 further includes:

[0397] The first acquisition unit is used to acquire the user priority identifier and real-time network load status corresponding to the TCP connection; wherein, the user priority identifier is used to indicate the resource allocation priority of the user to which the TCP connection belongs, and the real-time network load status is used to indicate the degree of current network link occupancy.

[0398] The adjustment unit is used to adjust a preset initial BDP multiple based on the user priority identifier and real-time network load status to obtain a specific multiple of BDP.

[0399] In one possible design, the TCP congestion control device also includes:

[0400] The second acquisition module is used to acquire the updated rhythm transmission rate; wherein, the updated rhythm transmission rate refers to the rhythm transmission rate applied at the current moment after the second rhythm transmission rate is updated to the first rhythm transmission rate.

[0401] The first determining module is used to determine the final effective congestion window upper limit as the mandatory stopping condition for TCP congestion window growth, and to determine the updated rhythm sending rate as the time interval benchmark for TCP packet sending.

[0402] The second constraint module is used to coordinate the constraint of the actual sending behavior of the preset TCP connection through forced stop conditions and time interval benchmarks, so as to make the actual sending behavior of the TCP connection adapt to the bandwidth limit.

[0403] In one possible design, the TCP congestion control device also includes:

[0404] The third acquisition module is used to obtain the deviation between the actual sending rate of the TCP connection and the updated rhythm sending rate.

[0405] The adjustment module is used to obtain the direction and degree of deviation when the duration of deviation exceeding the preset deviation threshold is greater than the preset time threshold, and adjust the preset constraint parameters in the hierarchical window constraint according to the direction and degree of deviation so that the duration is less than the time threshold.

[0406] In one possible design, the TCP congestion control device also includes:

[0407] The fourth acquisition module is used to acquire the fluctuation frequency and fluctuation amplitude of the bandwidth limit within a preset historical time period.

[0408] The reduction module is used to reduce the rate of change threshold and shorten the minimum update interval when the fluctuation frequency is greater than a preset fluctuation frequency threshold and the fluctuation amplitude is less than a preset fluctuation amplitude threshold.

[0409] The enhancement module is used to increase the rate of change threshold and extend the minimum update interval when the fluctuation frequency is less than the fluctuation frequency threshold and the fluctuation amplitude is greater than the fluctuation amplitude threshold.

[0410] In one possible design, the TCP congestion control device also includes:

[0411] The fifth acquisition module is used to acquire historical smoothed RTT, historical effective MSS, historical bandwidth limit, historical congestion window limit, and historical rhythm transmission rate collected at a preset second time point; wherein, the second time point is earlier than the current time point.

[0412] The sixth acquisition module is used to acquire the current smoothed RTT, the current effective MSS, and the current bandwidth limit at the current moment.

[0413] The second determining module is used to determine the historical congestion window upper limit as the final effective congestion window upper limit and the historical rhythm transmission rate as the rhythm transmission rate applied at the current moment in response to the following: the rate of change between the historical smoothed RTT and the current smoothed RTT is less than a preset first rate of change threshold; the rate of change between the historical effective MSS and the current effective MSS is less than a preset second rate of change threshold; and the rate of change between the historical bandwidth upper limit and the current bandwidth upper limit is less than a preset third rate of change threshold.

[0414] The TCP congestion control device provided in this embodiment can execute the technical solution of a TCP congestion control method embodiment shown in Figures 2 to 7. Its implementation principle and technical effect are similar to those of the TCP congestion control method embodiment shown in Figures 2 to 7, and will not be described in detail here.

[0415] Figure 16 is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. As shown in Figure 16, the electronic device 160 includes at least one processor 1601 and a memory 1602. The electronic device 160 also includes a communication component 1603. The processor 1601, the memory 1602, and the communication component 1603 are connected via a bus 1604.

[0416] In a specific implementation, at least one processor 1601 executes computer execution instructions stored in memory 1602, causing at least one processor 1601 to implement a TCP congestion control method of the above embodiment.

[0417] The specific implementation process of processor 1601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0418] In the above embodiments, it should be understood that the processor 1601 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0419] The memory 1602 may include high-speed RAM memory, and may also include non-volatile memory NVM, such as at least one disk storage.

[0420] Bus 1604 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Bus 1604 can be divided into address bus, data bus, control bus, etc. For ease of illustration, the bus 1604 in the accompanying drawings of this application is not limited to only one bus or one type of bus.

[0421] The above description of the functions implemented by electronic devices and main control devices has introduced the solutions provided by the embodiments of the present invention. It is understood that, in order to implement the above functions, the electronic device or main control device includes hardware structures and / or software modules corresponding to the execution of each function. By combining the units and algorithm steps of the various examples described in the embodiments of the present invention, the embodiments of the present invention can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware 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 the technical solutions of the embodiments of the present invention.

[0422] This application also provides a computer-readable storage medium storing computer-executable instructions. When executed by a processor, these instructions implement a TCP congestion control method as described in the above embodiments. In the specific implementation of the aforementioned TCP congestion control method, each module can be implemented as a processor.

[0423] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0424] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in application-specific integrated circuits (ASICs). Alternatively, the processor and the readable storage medium can exist as discrete components in an electronic device or a host device.

[0425] This application also provides a computer program product, including a computer program, which, when executed by a processor, is used to implement a TCP congestion control method according to the above embodiments.

[0426] The computer program is stored in a readable storage medium, and at least one processor can read the computer program from the readable storage medium and execute the computer program to perform the scheme provided in any of the above embodiments.

[0427] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disk, or optical disk.

[0428] The technical solutions of this application have been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it is readily understood by those skilled in the art that the scope of protection of this application is obviously not limited to these specific embodiments. The above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A TCP congestion control method, characterized in that, include: Obtain the smoothed RTT, effective MSS, and bandwidth limit; wherein the smoothed RTT represents the transmission delay of the network path, the effective MSS represents the maximum number of payload bytes carried by a single TCP packet, and the bandwidth limit represents the maximum sending bandwidth of the TCP connection; calculate the congestion window limit corresponding to the bandwidth limit based on the smoothed RTT, the effective MSS, and the bandwidth limit; wherein the congestion window limit corresponding to the bandwidth limit represents the maximum congestion window used by the TCP connection under the bandwidth limit condition; apply hierarchical window constraints to the congestion window limit corresponding to the bandwidth limit to obtain the final effective congestion window limit; wherein the final effective congestion window limit limits the maximum congestion window actually used by the TCP connection. Based on the bandwidth limit, calculate a first rhythm transmission rate and a rate of change between the first rhythm transmission rate and a preset second rhythm transmission rate; wherein the first rhythm transmission rate is a rhythm transmission rate calculated based on the bandwidth limit, and the second rhythm transmission rate refers to the rhythm transmission rate applied at the current moment; when the rate of change is greater than a preset rate of change threshold and the first time difference is greater than or equal to a preset minimum update interval, update the second rhythm transmission rate to the first rhythm transmission rate so that the rhythm transmission rate applied at the current moment adapts to the bandwidth limit; wherein the first time difference refers to the time difference between the current moment and the first moment, and the first moment refers to the rhythm rate update moment closest to the current moment.

2. The TCP congestion control method according to claim 1, characterized in that, The step of calculating the congestion window upper limit corresponding to the bandwidth upper limit based on the smoothed RTT, the effective MSS, and the bandwidth upper limit includes: calculating the bandwidth-delay product based on the smoothed RTT and the bandwidth upper limit; wherein the bandwidth-delay product is used to represent the maximum amount of data transmitted simultaneously on the network link; and calculating the congestion window upper limit corresponding to the bandwidth upper limit based on the bandwidth-delay product and the effective MSS.

3. The TCP congestion control method according to claim 1, characterized in that, The step of applying a hierarchical window constraint to the congestion window upper limit corresponding to the bandwidth upper limit to obtain the final effective congestion window upper limit includes: when the smoothed RTT is less than a preset RTT threshold, applying an RTT scenario constraint to the congestion window upper limit corresponding to the bandwidth upper limit to obtain a first upper limit; wherein, the RTT scenario constraint refers to adjusting the congestion window upper limit corresponding to the bandwidth upper limit to a preset effective window range; applying a fairness constraint to the first upper limit to obtain a second upper limit; wherein, the fairness constraint refers to adjusting the first upper limit so that the first upper limit does not exceed a specific multiple of a preset BDP; applying a memory protection constraint to the second upper limit to obtain the final effective congestion window upper limit; wherein, the memory protection constraint refers to adjusting the second upper limit so that the second upper limit does not exceed a preset system memory safety upper limit value.

4. The TCP congestion control method according to claim 3, characterized in that, Before applying fairness constraints to the first upper limit to obtain the second upper limit, the method further includes: obtaining the user priority identifier and real-time network load status corresponding to the TCP connection; wherein, the user priority identifier is used to indicate the resource allocation priority of the user to which the TCP connection belongs, and the real-time network load status is used to indicate the degree of current network link occupancy; and adjusting a preset initial BDP specific multiple according to the user priority identifier and the real-time network load status to obtain the specific multiple of the BDP.

5. The TCP congestion control method according to claim 1, characterized in that, After updating the second rhythmic transmission rate to the first rhythmic transmission rate so that the applied rhythmic transmission rate at the current moment adapts to the bandwidth limit, the method further includes: obtaining the updated rhythmic transmission rate; wherein, the updated rhythmic transmission rate refers to the rhythmic transmission rate applied at the current moment after updating the second rhythmic transmission rate to the first rhythmic transmission rate; determining the final effective congestion window limit as the mandatory stop condition for TCP congestion window growth, and determining the updated rhythmic transmission rate as the time interval reference for TCP packet transmission; and using the mandatory stop condition and the time interval reference to collaboratively constrain the actual transmission behavior of the preset TCP connection so that the actual transmission behavior of the TCP connection adapts to the bandwidth limit.

6. The TCP congestion control method according to claim 5, characterized in that, After constraining the actual sending behavior of the TCP connection by the forced stop condition and the time interval reference to adapt the actual sending behavior of the TCP connection to the bandwidth limit, the method further includes: obtaining the deviation between the actual sending rate of the TCP connection and the updated rhythm sending rate; when the duration of the deviation exceeding the preset deviation threshold is greater than the preset time threshold, obtaining the direction and degree of the deviation, and adjusting the preset constraint parameters in the hierarchical window constraint according to the direction and degree of the deviation, so that the duration is less than the time threshold.

7. The TCP congestion control method according to claim 6, characterized in that, After adjusting the preset constraint parameters in the hierarchical window constraint according to the direction and degree of the deviation so that the duration is less than the time threshold, the method further includes: obtaining the fluctuation frequency and fluctuation amplitude of the bandwidth upper limit within a preset historical time period; when the fluctuation frequency is greater than a preset fluctuation frequency threshold and the fluctuation amplitude is less than a preset fluctuation amplitude threshold, reducing the change rate threshold and shortening the minimum update interval; when the fluctuation frequency is less than the fluctuation frequency threshold and the fluctuation amplitude is greater than the fluctuation amplitude threshold, increasing the change rate threshold and extending the minimum update interval.

8. The TCP congestion control method according to claim 1, characterized in that, Before obtaining the smoothed RTT, effective MSS, and bandwidth limit, the method further includes: obtaining historical smoothed RTT, historical effective MSS, historical bandwidth limit, historical congestion window limit, and historical rhythmic transmission rate collected at a preset second time point; wherein, the second time point is earlier than the current time point; obtaining the current smoothed RTT, current effective MSS, and current bandwidth limit at the current time point; in response to the fact that the rate of change between the historical smoothed RTT and the current smoothed RTT is less than a preset first rate of change threshold, and the rate of change between the historical effective MSS and the current effective MSS is less than a preset second rate of change threshold, and the rate of change between the historical bandwidth limit and the current bandwidth limit is less than a preset third rate of change threshold, determining the historical congestion window limit as the finally effective congestion window limit, and determining the historical rhythmic transmission rate as the rhythmic transmission rate applied at the current time point.

9. A TCP congestion control device, characterized in that, include: A first acquisition module is used to acquire smoothed RTT, effective MSS, and bandwidth limit; wherein, smoothed RTT represents the transmission delay of the network path, effective MSS represents the maximum number of payload bytes carried by a single TCP packet, and bandwidth limit represents the maximum sending bandwidth of the TCP connection; a first calculation module is used to calculate the congestion window limit corresponding to the bandwidth limit based on the smoothed RTT, effective MSS, and bandwidth limit; wherein, the congestion window limit corresponding to the bandwidth limit represents the maximum congestion window used by the TCP connection under the bandwidth limit condition; a constraint module is used to apply hierarchical window constraints to the congestion window limit corresponding to the bandwidth limit to obtain the final effective congestion window limit; wherein, the final effective congestion window limit limits the maximum congestion window actually used by the TCP connection. A large congestion window; a second calculation module, used to calculate a first rhythmic transmission rate and a rate of change between the first rhythmic transmission rate and a preset second rhythmic transmission rate based on the bandwidth limit; wherein the first rhythmic transmission rate is a rhythmic transmission rate calculated based on the bandwidth limit, and the second rhythmic transmission rate refers to the rhythmic transmission rate applied at the current moment; an update module, used to update the second rhythmic transmission rate to the first rhythmic transmission rate when the rate of change is greater than a preset rate of change threshold and the first time difference is greater than or equal to a preset minimum update interval, so that the rhythmic transmission rate applied at the current moment adapts to the bandwidth limit; wherein the first time difference refers to the time difference between the current moment and a first moment, and the first moment refers to the rhythmic rate update moment closest to the current moment before the current moment.

10. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; when the processor executes the computer-executable instructions stored in the memory, it is used to implement the TCP congestion control method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the TCP congestion control method as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, is used to implement the TCP congestion control method as described in any one of claims 1 to 8.

Images