Support > About independent server > In high-latency scenarios, is the BBR algorithm suitable for all servers?
In high-latency scenarios, is the BBR algorithm suitable for all servers?
Time : 2025-10-15 14:55:59
Edit : Jtti

  Transoceanic communications inevitably introduce high latency, a particularly sensitive issue for real-time-critical services like online gaming, financial transactions, and e-commerce platforms. To improve network transmission efficiency, the BBR algorithm emerged. As a modern TCP congestion control algorithm, it optimizes data transmission performance in high-latency and high-bandwidth environments. However, many webmasters and operations personnel question whether the BBR algorithm is suitable for all servers in high-latency scenarios.

  BBR Algorithm Overview and Working Principle:

  BBR is a TCP congestion control algorithm proposed by Google in 2016. Unlike traditional algorithms such as CUBIC and Reno, BBR does not rely on packet loss to determine network congestion. Instead, it dynamically adjusts the sending rate by estimating bottleneck bandwidth and round-trip latency in real time. The core concepts of BBR can be summarized as bandwidth estimation, RTT monitoring, and adaptive rate. The traditional CUBIC algorithm is prone to underutilization of bandwidth or frequent packet loss in high-latency, high-bandwidth networks because it relies on packet loss signals to control the sending rate. BBR, on the other hand, achieves a balance between low latency and high throughput by predicting network capacity, offering significant advantages in transoceanic, high-latency scenarios.

  High-latency network characteristics:

  Under these conditions, traditional algorithms often fail to balance throughput and latency. BBR's dynamic bandwidth and RTT-based control makes it theoretically more suitable for high-latency scenarios.

  Advantages of the BBR algorithm for high-latency servers:

  1. Reduced queuing delay. Traditional congestion control continuously increases the sending window, leading to queue backlogs on routers or switches and resulting in high latency. BBR estimates link capacity to control the rate, reducing queue lengths and effectively reducing latency.

  2. Improved link utilization. In transoceanic, high-latency networks, where link capacity is high but RTT is long, algorithms like CUBIC often have idle bandwidth while waiting for ACKs. BBR continuously estimates bandwidth, keeping the sending rate close to the link limit and fully utilizing available bandwidth.

  3. Reduced sensitivity to packet loss. BBR does not rely on packet loss to determine network status, making it more stable on links with low packet loss but high latency, and avoids significant reductions in sending rates due to occasional packet loss.

  4. Adaptive to diverse network conditions. BBR can adapt to both long and short latency environments, as well as environments with varying bandwidth. This makes it particularly suitable for scenarios such as cross-border business, cloud servers, optimization.

  Limitations and Applicability of the BBR Algorithm:

  Although BBR offers significant advantages in high-latency scenarios, it's not suitable for all servers or network environments. The following points should be noted:

  1. Low-latency LAN environments. In LAN environments with very low latency (e.g., 1-5ms), BBR may not be faster than CUBIC, and in some cases may even be slightly slower, because CUBIC already fully utilizes the bandwidth.

  2. High-loss networks. Although BBR performs well on networks with low packet loss rates, when the packet loss rate exceeds 1%-2%, BBR's estimation mechanism may produce errors, leading to fluctuations in the sending rate. In such cases, traditional loss-driven algorithms may be more stable.

  3. Server CPU and kernel support. BBR requires Linux kernel 4.9 or higher. If the server kernel version is too low or CPU resources are limited, enabling BBR may result in performance degradation or instability.

  4. Application type restrictions. BBR primarily optimizes TCP transmission rates. For UDP traffic or real-time voice/video applications, it needs to be optimized in conjunction with protocols such as QUIC and RTP.

  5. Conflicts with QoS policies. In enterprise networks, if QoS or traffic rate limiting policies are in place, BBR's adaptive sending rate may conflict with these policies, resulting in reduced throughput.

  Therefore, BBR is suitable for high-latency environments, but its use still needs to be evaluated based on network conditions, server configuration, and service type.

  Practical Methods for Enabling BBR in High-Latency Scenarios

  1. Upgrading the Linux kernel: The BBR algorithm supports Linux kernels 4.9 and above. We recommend using the latest stable kernel version and ensuring that the TCP module supports BBR.

  2. Enabling BBR and Setting the Default Queue

modprobe tcp_bbr
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p

  Use sysctl net.ipv4.tcp_congestion_control to check if this is effective.

  3. Adjust the TCP buffer

echo "net.core.rmem_max=67108864" >> /etc/sysctl.conf
echo "net.core.wmem_max=67108864" >> /etc/sysctl.conf
echo "net.ipv4.tcp_rmem=4096 87380 67108864" >> /etc/sysctl.conf
echo "net.ipv4.tcp_wmem=4096 65536 67108864" >> /etc/sysctl.conf
sysctl -p

  Increasing the window size and buffer size allows BBR to fully utilize the bandwidth of long, high-latency paths.

  4. Monitor network performance: Use iperf3, ping, and mtr to test bandwidth, latency, and packet loss to evaluate BBR optimization results.

  5. Integrate with CDN and intelligent routing: BBR optimizes TCP transmission, but cross-border access is still affected by network connectivity. Combining it with a CDN or multi-line BGP server can further reduce latency.

  Summary: The BBR algorithm is a revolutionary TCP congestion control scheme, particularly suitable for high-latency, high-bandwidth, and low-packet-loss cross-border server environments. It achieves a balance between low latency and high throughput through real-time bandwidth and RTT estimation, addressing the inefficiencies of traditional algorithms over long-distance transmission. However, BBR is not a panacea. It has limited optimization effects on low-latency LANs, high-packet-loss networks, or UDP applications, and requires a modern Linux kernel and appropriate system configuration. In practice, high-latency server optimization should be combined with measures such as the BBR algorithm, TCP buffer and window adjustment, MTU and queue strategy optimization, cross-border line optimization (BGP, CN2, etc.), CDN and multi-point load balancing. Only by combining system parameter optimization with network architecture optimization can we truly improve the cross-border access experience, reduce latency fluctuations, and improve business stability.

Relevant contents

Construction of Hong Kong VPS cache penetration protection system 2025 Cross-border E-commerce Server Configuration and Discount Guide Can Japanese servers prevent DDoS attacks? Defense measures and principle analysis What is a Riser card in the Japanese server? What are its specific functions? How to deal with the shortage of server space in the United States How to improve SEO effects by optimizing Hong Kong server configuration Is the CN2 line of the rational discussion server really much faster than the ordinary line? How to optimize the access speed of Hong Kong servers to make mainland access smoother My Hong Kong server frequently disconnects at night but is very stable during the day? What are the advantages of choosing a Hong Kong node for game accelerators?
Go back

24/7/365 support.We work when you work

Support