TCP congestion control slow start optimization method based on bandwidth detection
Through the TCP congestion control method based on bandwidth detection, the bottleneck link bandwidth is quickly estimated and the congestion window update is optimized, which solves the problem of low bandwidth utilization in the slow startup stage of TCP, and achieves efficient data transmission and user experience improvement.
Patent Information
- Application Number
- CN202510782011.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-12
- Publication Date
- 2025-08-22
AI Technical Summary
The existing TCP congestion control algorithms cannot adapt quickly in a slow startup phase in high-bandwidth networks, resulting in low bandwidth utilization, especially short-stream transmission efficiency, and existing optimization solutions require additional router support or are expensive.
By collecting data packet information, the bandwidth estimate of ACK interval compensation is calculated using data sending timestamps, ACK reception timestamps and minimum RTTs, the update strategy of the congestion window is optimized, the bottleneck link bandwidth is quickly estimated and the sending window is adjusted, and the slow start exit conditions are optimized to avoid additional detection messages and router changes.
It significantly improves the performance of TCP congestion control algorithm in high-bandwidth networks, shortens short stream transmission time, reduces long-stream packet loss and stream completion time, and improves bandwidth utilization and user experience.
Smart Images

Figure CN120528867A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of computer networks, and in particular to a TCP congestion control slow start optimization method based on bandwidth detection. Background Art
[0002] With the rapid development of the internet, bandwidth-intensive services such as high-definition video streaming, virtual reality, cloud computing, and the Internet of Things are becoming increasingly popular, leading to exponential growth in network traffic. The emergence of 5G has boosted theoretical network speeds from 4G's 1Gbps to 20Gbps. Achieving high-speed, reliable data transmission has become a key research topic.
[0003] The Transmission Control Protocol (TCP) is a fundamental protocol in computer networks, ensuring reliable data transmission across the internet. The TCP congestion control algorithm plays a crucial role in managing network traffic and preventing congestion collapse. However, even with significant increases in physical layer data speeds, the user-perceived rate increase may be subtle due to the congestion control algorithm's exponentially increasing slow-start mechanism. This is because when a new connection is established, the sender has little information about path characteristics and available bandwidth. Therefore, the sender must gradually increase the congestion window (CWND) from a small initial value. However, this approach has significant drawbacks in high-bandwidth networks, as it takes a long time for the sender to reach the bottleneck bandwidth, thus failing to fully utilize the existing high-bandwidth link. This is particularly true for short streams such as web pages, app downloads, and short videos. These streams often complete transmission before reaching link capacity, but have not yet exited the slow-start phase, resulting in wasted available bandwidth.
[0004] In recent years, Google's BBR (Bottleneck Bandwidth and Round-trip propagation time) algorithm, which measures bottleneck bandwidth and round-trip propagation time to control congestion, is more adaptable to various network environments. With Google's deployment of BBR in real-world scenarios (such as YouTube), approximately 40% of internet traffic has become BBR flows, and its excellent performance has attracted increasing research attention. However, BBR's slow start phase still uses an exponential growth method, which cannot quickly adapt to high-bandwidth networks. Furthermore, BBR's bandwidth estimation during the slow start phase is susceptible to send window exhaustion and its own pacing mechanism, resulting in bandwidth underestimation. Therefore, optimizing BBR's slow start can further improve its performance and enable its application in a wider range of scenarios.
[0005] To address the slow start issue, researchers have proposed various optimization schemes. For example, the Quick-Start mechanism allows the sender to cooperate with the router to request a higher transmission rate, but this requires additional request packets and router support. The Jump-Start mechanism directly starts transmission at an arbitrary rate. While this optimizes the transmission of short flows, it has a negative impact on long flows and network congestion. Furthermore, machine learning-based methods such as TCPWISE and TCP-RL optimize performance by dynamically adjusting the initial congestion window, but this typically requires additional overhead.
[0006] In terms of BBR optimization, although BBRv2 and BBRv3 have improved friendliness and fairness, optimization of the slow start phase is still imperfect. Therefore, optimization of the BBR slow start phase remains an important research direction. Summary of the Invention
[0007] In order to solve the above problems, the present invention proposes a TCP congestion control slow start optimization method based on bandwidth detection, which specifically includes:
[0008] Step S1: Collect data packet information from the sender to the receiver, and use the data sending timestamp, ACK receiving timestamp, confirmed data size, and minimum RTT in the data packet to calculate the bandwidth estimation of ACK interval compensation and the bandwidth estimation of BBR;
[0009] Step S2: Calculate the congestion window fast_CWND based on the bandwidth estimation of the ACK interval compensation, calculate the congestion window bbr_CWND based on the bandwidth estimation of the BBR, and update the congestion window based on the sending bandwidth and the ratio of fast_CWND to bbr_CWND;
[0010] Step S3: Determine whether the bandwidth limit has been reached based on the updated congestion window value. If so, exit the slow start process directly. If not, proceed to step S4.
[0011] Step S4: Based on the TCP protocol, a final sending window is selected from the updated congestion window and receiving window to complete the TCP congestion control slow start optimization based on bandwidth detection.
[0012] Optionally, in step S1, obtaining bandwidth estimation for ACK interval compensation specifically includes:
[0013] Calculate the ACK interval caused by sending window exhaustion based on the data sending timestamp, ACK receiving timestamp, confirmed data size and minimum RTT;
[0014] The ACK interval caused by pacing is calculated based on the data sending timestamp, ACK receiving timestamp, confirmed data size, and minimum RTT.
[0015] Optionally, the ACK interval caused by sending window exhaustion is calculated based on the data sending timestamp, ACK receiving timestamp, confirmed data size, and minimum RTT, specifically:
[0016] The waiting time T between the first round of data sending and the second round of data sending w_11 Denoted as:
[0017] T w_11 =T ack_1 -T send_10
[0018] =RTT1-(T send_10 -T send_1 )
[0019] Among them, T ack_1 The first ACK reception timestamp, T send_1 Send timestamp for the first data packet, T send_10 The timestamp for sending the tenth data packet is RTT1, which is the shortest time required for the data packet to travel from the sender to the receiver and back to the sender in the first round.
[0020] Based on the number of link data packets, the shortest time minRTT required for the data packet to travel from the sender to the receiver and back to the sender is used to approximate RTT1. w_11 Simplified to:
[0021] T w_11 =minRTT-(T send_10 -T send_1 ).
[0022] Optionally, calculate the ACK interval T caused by pacing based on the data sending timestamp, ACK receiving timestamp, confirmed data size and minimum RTT i The content specifically includes:
[0023]
[0024] Among them, T ack_n+1 The n+1th ACK reception timestamp, T e_n+1 T is the additional waiting time before sending the n+1th data packet. w_n+1 is the waiting time caused by exhaustion of the sending window, T i_n The interval between the nth ACK and the (n+1)th ACK.
[0025] Optional, get T w_n+1 The parameters are as follows:
[0026]
[0027] Among them, T send_n Send timestamp for nth packet, The sending timestamp of the first data packet in this round.
[0028] Optionally, in step S2, the content of calculating the congestion window fast_CWND based on the bandwidth estimation of the ACK interval compensation is specifically:
[0029] fast_CWND=(throughput n ×minRTT) / MSS
[0030] Among them, throughput n is the throughput, MSS is the maximum segment size, and minRTT is the shortest time required for a data packet to travel from the sender to the receiver and back to the sender.
[0031] Optionally, the throughput information includes:
[0032]
[0033] Among them, n represents the nth ACK received, Acked_bytes i To confirm the data size, T i_i The return time interval between adjacent ACKs.
[0034] Optionally, the content of the updated congestion window is specifically:
[0035] At the initial stage of transmission, the sizes of the congestion window bbr_CWND and the congestion window fast_CWND are compared, and the larger value between the two is selected to update the congestion window CWND;
[0036] Starting from the fourth round, the congestion window bbr_CWND is ignored, and the value of the congestion window fast_CWND is used to update the congestion window CWND.
[0037] Compared with the prior art, the present invention has the following beneficial effects:
[0038] This paper proposes BBR-QS, which quickly estimates the available bandwidth of the bottleneck link at the beginning of slow start without padding the bottleneck link or sending additional probe messages. BBR-QS is implemented on the sender side, requiring no changes to the receiver or routers, making it easy to deploy in real-world scenarios. This paper also proposes a compensation mechanism for the ACK return rate, which addresses the impact of send window exhaustion and BBR's pacing mechanism on the ACK return rate, ensuring that the ACK return rate accurately reflects the bottleneck link bandwidth. Based on the new bandwidth estimate, this paper modifies the BBR slow start exit criteria to reduce packet loss during slow start exit. Furthermore, it addresses the send rate limitation imposed by the receive window during the slow start phase. This paper implements BBR-QS in the Linux kernel and tests it in various network environments. Experimental results show that compared to the most commonly used congestion control algorithms, CUBIC and BBR, BBR-QS can reduce the time to reach the bottleneck link bandwidth by over 50%. For short flows (e.g., 2MB), BBR-QS can reduce flow completion time by over 50%. For long flows (e.g., 32MB), BBR-QS can reduce packet loss by over 20% and reduce flow completion time by 8.5%. By optimizing bandwidth estimation and slow start exit conditions, this method accelerates the transmission of short flows and speeds up slow start convergence, significantly improving the performance of the TCP congestion control algorithm, BBR, in high-bandwidth networks. This method can be widely applied in various network environments, significantly improving the user experience.
[0039] The present invention can quickly estimate the available link bandwidth and use it to determine the initial sending window, significantly improving the slow start convergence speed in different network environments, increasing the bandwidth utilization in the slow start phase, and shortening the transmission time of small files such as pictures, words, and PDFs, which are mostly between hundreds of KB and several MB in size. This is of great significance for meeting users' daily sharing, storage, collaboration and other needs and improving user experience. BRIEF DESCRIPTION OF THE DRAWINGS
[0040] In order to more clearly illustrate the technical solution of the present invention, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.
[0041] Figure 1 A flowchart of a method for optimizing TCP congestion control slow start based on bandwidth detection according to an embodiment of the present invention;
[0042] Figure 2 This is a schematic diagram of an additional sending interval caused by exhaustion of the sending window according to an embodiment of the present invention;
[0043] Figure 3 This is a schematic diagram of the additional sending interval caused by the pacing mechanism in an embodiment of the present invention. DETAILED DESCRIPTION
[0044] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the present invention is further described in detail below with reference to the accompanying drawings and specific embodiments.
[0045] Example 1
[0046] A TCP congestion control slow start optimization method based on bandwidth detection, such as Figure 1 As shown, the method includes:
[0047] Step S1: Collect data packet information from the sender to the receiver, and calculate the bandwidth estimation of ACK interval compensation and BBR based on the data sending timestamp, ACK receiving timestamp, confirmed data size and minimum RTT. Figure 2 As shown in , after the sender sends the 10th data packet, it needs to wait for the ACK of the 1st data packet to return before it can continue to slide the send window to send the 11th data packet. This means that when the send window is exhausted, data packets cannot be sent for a period of time and the sender is in an idle state. In addition, as Figure 3 As shown in Figure 2, BBR's pacing mechanism determines the packet transmission rate. It evenly distributes packets at a specific rate, increasing the interval between packet transmissions and, consequently, the interval between ACKs. These factors contribute to bandwidth underestimation.
[0048] Therefore, the ACK interval compensation algorithm is used to compensate for the waiting time caused by the exhaustion of the sender window and the additional sending interval caused by BBR pacing, making the bandwidth estimation more accurate.
[0049] like Figure 2 As shown in Figure 2, the kernel does not pace the data packets in the first RTT, so the 10 data packets sent in the first round of RTT are sent all at once as quickly as possible. w_11 The reason is that the sending window is exhausted, but the link is not fully used at this time. The second round RTT is T w_31 The same is true for the time period. Therefore, only the ACK return rate per RTT (such as Figure 2 The 1st to 10th ACKs in the dotted box can reflect the actual link capacity.
[0050] The bandwidth estimation for obtaining ACK interval compensation specifically includes:
[0051] The ACK interval caused by the exhaustion of the sending window is calculated based on the data sending timestamp, ACK receiving timestamp, confirmed data size, and minimum RTT. The specific content is:
[0052] The waiting time T between the first round of data sending and the second round of data sending w_11 Denoted as:
[0053] T w_11 =T ack_1 -T send_10
[0054] =RTT1-(T send_10 -T send_1 )
[0055] Among them, T ack_1 The first ACK reception timestamp, T send_1 Send timestamp for the first data packet, T send_10 is the timestamp for sending the tenth data packet, and RTT1 is the shortest time required for the data packet to travel from the sender to the receiver and then back to the sender in the first round; in this embodiment, Figure 2 As shown, taking the waiting time between the first round of data transmission and the second round of data transmission as an example, the waiting time between the sending of the 10th data packet and the sending of the 11th data packet is calculated.
[0056] In the first and second rounds of RTT, since the connection has just been established and the number of data packets in the link is small, for RTT1 and RTT2, the shortest time minRTT required for the data packet to travel from the sender to the receiver and back to the sender is used to approximate RTT1, and T w_11 Simplified to:
[0057] T w_11 =minRTT-(T send_10 -T send_1 ).
[0058] Therefore, for ACKs that do not belong to the same round of RTT (e.g. Figure 2 The 10th ACK and the 11th ACK in the transmission window need to be exhausted to wait for the time T w_n+1 Subtract this from the total time it takes for the ACK to come back.
[0059] The ACK interval caused by pacing is calculated based on the data sending timestamp, ACK receiving timestamp, confirmed data size, and minimum RTT.
[0060] BBR uses the pacing mechanism to add additional sending intervals between data packets to avoid buffer expansion and other problems that may be caused by the sender sending data packets at once according to the CWND size. The Linux kernel calculates the next sending time T based on the ratio of the packet length and the pacing_rate in BBR. next_send The last sending time T last_send The interval T len , so the next sending time can be calculated as:
[0061] T next_send =T last_send +T len
[0062] The kernel function tcp_pacing_check() will check whether the data packet can be sent. If the current time does not exceed the next sending time T next_send , the data packet will continue to wait for sending.
[0063] like Figure 3 As shown, the kernel does not pace the packets in the first round of RTT. Figure 3 As shown in the dashed box, after the first RTT, the number of packets is still small and the pacing_rate is low, resulting in a longer sending interval. Accordingly, the ACK return interval in the same RTT round increases, affecting the bandwidth estimation based on the ACK rate.
[0064] In order to retain the advantages of the pacing mechanism to the greatest extent possible while eliminating its impact on bandwidth estimation during slow start, BBR-QS uses an interval compensation algorithm to compensate for the extra ACK return interval generated by pacing. Figure 3 As shown in Figure 2, when pacing is actually enabled in the second RTT round, the sending interval T between the 11th and 12th packets is len_11 It consists of two parts: the time required to send the data packet itself (T trans _ 11 ) and the additional waiting time caused by pacing (T e_11 ). For T len_13 The same is true for other intervals. Since the kernel uses the tcp_pacing_check() function to determine whether a packet can be sent, T e_n It can be calculated as the difference between the time when the data packet is first checked and the time when the data packet is actually sent. Therefore, for the ACK in the same round RTT, the additional waiting time T caused by the pacing mechanism needs to be included. e_n Subtract from the total time taken for the ACK to return. In addition, for the ACK interval between adjacent RTTs, in addition to the need to compensate for the waiting time T caused by the exhaustion of the sending windoww_n In addition, the corresponding additional waiting time T needs to be compensated e_n The delay caused.
[0065] Finally, the compensated ACK interval T i Specifically include:
[0066]
[0067] Among them, T ack_n+1 The n+1th ACK reception timestamp, T e_n+1 T is the additional waiting time before sending the n+1th data packet. w_n+1 is the waiting time caused by exhaustion of the sending window, T i_n is the interval between the nth ACK and the (n+1th) ACK. The numbers in parentheses indicate trigger conditions. The first row indicates the ACK interval within the first RTT round, simply subtracting the timestamps of adjacent ACK returns. The second row represents ACKs within the second and subsequent RTT rounds, subtracting the additional waiting time from the first case. The third row indicates ACKs between adjacent RTT rounds, subtracting the waiting time due to window exhaustion from the second row.
[0068] Get T w_n+1 The parameters are as follows:
[0069]
[0070] Among them, T send_n Send timestamp for nth packet, The sending timestamp of the first data packet in this round of RTT.
[0071] Step S2: Calculate the congestion window fast_cwnd based on the bandwidth estimation of the ACK interval compensation, calculate the congestion window bbr_cwnd based on the bandwidth estimation of the BBR, and update the congestion window based on the sending bandwidth and the ratio of fast_cwnd to bbr_cwnd.
[0072] The content of the congestion window fast_cwnd calculated based on the bandwidth estimation of ACK interval compensation is as follows:
[0073] fast_CWND=(throughput n ×minRTT) / MSS
[0074] Among them, throughput n is the throughput, MSS is the maximum segment size, and minRTT is the shortest time required for a data packet to travel from the sender to the receiver and back to the sender.
[0075] The sender can confirm the number of bytes Acked_bytes through ACK i The accumulated value is taken as the total amount of data sent, and according to T i_i The sum of the elapsed time is obtained, and the throughput is obtained by:
[0076]
[0077] Among them, n is the nth ACK received, Acked_bytes i To confirm the data size, T i_i It is the return time interval between adjacent ACKs.
[0078] The content of updating the congestion window is as follows:
[0079] At the initial stage of transmission, the sizes of the congestion window bbr_CWND and the congestion window fast_CWND are compared, and the larger value between the two is selected to update the congestion window CWND;
[0080] Starting from the fourth round, the congestion window bbr_CWND is ignored, and the value of the congestion window fast_CWND is used to update the congestion window CWND.
[0081] Step S3: Determine whether the bandwidth upper limit has been reached based on the updated congestion window value. If so, exit the slow start directly. If not, execute step S4.
[0082] In addition to the bandwidth estimation described above, BBR's own bandwidth estimation can still be performed normally, and bbr_CWND can be obtained based on BBR's own estimated bandwidth (BtlBW). In the initial stage of transmission, to minimize the impact of possible bandwidth estimation jitter on CWND growth, the larger value of bbr_CWND and fast_CWND can be used to obtain CWND.
[0083] After the third bandwidth estimate (i.e., at the end of the fourth RTT), the algorithm will ignore bbr_CWND and only use the value of fast_CWND. This is to avoid BBR's exponential growth injecting too many packets into the link when the estimated bandwidth approaches the bottleneck bandwidth. Therefore, the algorithm sets CWND as follows:
[0084]
[0085] The first bandwidth estimate uses data from the first two RTT rounds. Based on this estimated bandwidth, fast_CWND can be calculated at the beginning of the third RTT round. This ensures that sufficient data is available without making the first bandwidth estimate take too long.
[0086] After that, BBR-QS will accumulate data from all previous RTT rounds to estimate the bandwidth until the slow start exit condition is triggered. As the stream is transmitted, BBR-QS obtains more and more sampling points, is less affected by link fluctuations, and the estimated bandwidth will be more stable and accurate. For the third and subsequent RTTs, since CWND has increased from the initial 10MSS to at least 20MSS, 40MSS or even more, the waiting time between adjacent RTTs caused by the exhaustion of the sending window is negligible. Therefore, the algorithm will no longer compensate for the waiting time T w_n .
[0087] Before the first update of fast_CWND based on the bandwidth estimate based on ACK interval compensation (i.e., before the start of the third RTT round), pacing_rate is still calculated based on BBR's original estimated bandwidth. This results in CWND being increased to match the bottleneck link bandwidth in the third RTT round, but the sending rate pacing_rate remains low. This severely limits BBR-QS's ability to increase the sending rate and accelerate bandwidth convergence.
[0088] Therefore, before the third round of RTT begins, the corresponding pacing_rate3 needs to be updated:
[0089] pacing_rate3=throughput3 / minRTT
[0090] Here, throughput3 is the throughput value after the first BBR-QS estimation. After that, pacing_rate will still be updated according to the original BBR algorithm.
[0091] Through the above steps, bandwidth estimation based on ACK interval compensation is implemented, making bandwidth estimation more accurate and optimizing CWND selection and pacing_rate update strategies. This helps improve BBR-QS performance in network transmission, avoids unreasonable sending rates caused by inaccurate bandwidth estimation, reduces network congestion, and improves data transmission efficiency and stability.
[0092] The conditions for optimizing slow start exit are:
[0093] BBR's original slow start exit condition required that the estimated bandwidth (BtlBW) for three consecutive RTT rounds not increase by more than 25%. However, when the sending rate reaches the bottleneck bandwidth, the exponential growth of BBR's CWND and pacing_rate may cause the sender to inject too many packets into the link, resulting in excessive packet loss. On the other hand, bandwidth estimation based on ACK interval compensation approaches the bottleneck link bandwidth based on the actual estimated bandwidth. We believe that if the estimated bandwidth after ACK interval compensation does not increase significantly within a certain period of time, it indicates that BBR-QS has reached near the bottleneck link bandwidth. In addition, when the packet loss rate is too high, it also indicates that slow start should be exited.
[0094] Therefore, the algorithm changes the exit condition to: in k consecutive RTT rounds, the estimated bandwidth after ACK interval compensation does not increase by more than the threshold c , or the packet loss rate of an RTT exceeds the threshold loss .
[0095] Step S4: Based on the TCP protocol, a final sending window is selected from the updated congestion window and receiving window to complete the TCP congestion control slow start optimization based on bandwidth detection.
[0096] In the TCP protocol, the sender's final send window (snd_wnd) is determined by the smaller value of the congestion window (CWND) and the receive window (RWND). This is to prevent the sending rate from exceeding the receiver's receiving capacity. In this case, due to the limitation of RWND, the CWND updated by the bandwidth estimation based on ACK interval compensation may not increase the sender's send window (snd_wnd).
[0097] The value of RWND reflects the different conditions of the receiving end's buffer. Typically, the receiver increases RWND at a fixed step size for each data packet received. However, when RWND exceeds a threshold reflecting the buffer size, the receiver sends this threshold back to the sender as the RWND value in the ACK. In fact, if CWND is based on the ACK return rate, then a linear increase in RWND indicates that the receiver can at least process data packets at the current rate. On the other hand, if RWND reflects the upper limit of the buffer, it means that the remaining space in the buffer is limited, and the sender needs to control the send window (snd_wnd) based on the size of RWND.
[0098] Therefore, the algorithm observes the current RWND n Is it the same as the previous RWND n-1The same growth step size is used to determine whether to ignore RWND. It should be noted that RWND is scaled by the window scaling factor before being encapsulated into ACK. If the result is not an integer, the kernel will remove the decimal part and add 1 to the integer part.
[0099] Therefore, when comparing the RWND growth step, it is necessary to add 1 as redundancy. The RWND selection algorithm can be expressed as:
[0100] Δ n =RWND n -RWND n-1 (n>1)
[0101]
[0102] Through the above steps, the RWND selection algorithm designed based on the RWND characteristics is implemented, aiming to more accurately control the sender's sending window, so that it can fully utilize the receiver's receiving capacity while avoiding data loss or network congestion due to a full receiving buffer, thereby improving the stability and efficiency of BBR-QS during data transmission.
[0103] The embodiments described above are merely descriptions of preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Without departing from the spirit of the present invention, various modifications and improvements made to the technical solutions of the present invention by persons skilled in the art should fall within the scope of protection defined by the claims of the present invention.
Claims
1. A TCP congestion control slow start optimization method based on bandwidth detection, characterized in that: The method comprises: Step S1: Collect data packet information from the sender to the receiver, and use the data sending timestamp, ACK receiving timestamp, confirmed data size, and minimum RTT in the data packet to calculate the bandwidth estimation of ACK interval compensation and the bandwidth estimation of BBR; Step S2: Calculate the congestion window fast_CWND based on the bandwidth estimation of the ACK interval compensation, calculate the congestion window bbr_CWND based on the bandwidth estimation of the BBR, and update the congestion window based on the sending bandwidth and the ratio of fast_CWND to bbr_CWND; Step S3: Determine whether the bandwidth limit has been reached based on the updated congestion window value. If so, exit the slow start process directly. If not, proceed to step S4. Step S4: Based on the TCP protocol, a final sending window is selected from the updated congestion window and receiving window to complete the TCP congestion control slow start optimization based on bandwidth detection.
2. The TCP congestion control slow start optimization method based on bandwidth detection according to claim 1, characterized in that: In step S1, obtaining the bandwidth estimation for ACK interval compensation specifically includes: Calculate the ACK interval caused by sending window exhaustion based on the data sending timestamp, ACK receiving timestamp, confirmed data size and minimum RTT; The ACK interval caused by pacing is calculated based on the data sending timestamp, ACK receiving timestamp, confirmed data size, and minimum RTT.
3. The TCP congestion control slow start optimization method based on bandwidth detection according to claim 2 is characterized in that: The ACK interval caused by the exhaustion of the sending window is calculated based on the data sending timestamp, ACK receiving timestamp, confirmed data size, and minimum RTT. The specific content is: The waiting time T between the first round of data sending and the second round of data sending w_11 Denoted as: T w_11 =T ack_1 -T send_10 =RTT1-(T send_10 -T send_1 ) Among them, T ack_1 The first ACK reception timestamp, T send_1 Send timestamp for the first data packet, T send_10 The timestamp for sending the tenth data packet is RTT1, which is the shortest time required for the data packet to travel from the sender to the receiver and back to the sender in the first round. Based on the number of link data packets, the shortest time minRTT required for the data packet to travel from the sender to the receiver and back to the sender is used to approximate RTT1. w_11 Simplified to: T w_11 =minRTT-(T send_10 -T send_1 )。 4. The TCP congestion control slow start optimization method based on bandwidth detection according to claim 3 is characterized in that: Calculate the ACK interval T caused by pacing based on the data sending timestamp, ACK receiving timestamp, confirmed data size and minimum RTT i The content specifically includes: Among them, T ack_n+1 The n+1th ACK reception timestamp, T e_n+1 T is the additional waiting time before sending the n+1th data packet. w_n+1 is the waiting time caused by exhaustion of the sending window, T i_n The interval between the nth ACK and the (n+1)th ACK.
5. The TCP congestion control slow start optimization method based on bandwidth detection according to claim 4 is characterized in that: Get T w_n+1 The parameters are as follows: Among them, T send_n Send timestamp for nth packet, The sending timestamp of the first data packet in this round.
6. The TCP congestion control slow start optimization method based on bandwidth detection according to claim 1, characterized in that: In step S2, the content of calculating the congestion window fast_CWND based on the bandwidth estimation of the ACK interval compensation is specifically: fast_CWND=(throughput n ×minRTT) / MSS Among them, throughput n is the throughput, MSS is the maximum segment size, and minRTT is the shortest time required for a data packet to travel from the sender to the receiver and back to the sender.
7. The TCP congestion control slow start optimization method based on bandwidth detection according to claim 6, characterized in that: The throughput includes: Among them, n represents the nth ACK received, Acked_bytes i To confirm the data size, T i_i The return time interval between adjacent ACKs.
8. The TCP congestion control slow start optimization method based on bandwidth detection according to claim 6, characterized in that: The content of the updated congestion window is specifically: At the initial stage of transmission, the sizes of the congestion window bbr_CWND and the congestion window fast_CWND are compared, and the larger value between the two is selected to update the congestion window CWND; Starting from the fourth round, the congestion window bbr_CWND is ignored, and the value of the congestion window fast_CWND is used to update the congestion window CWND.