从流量控制算法谈网络优化 – 从 CUBIC 到 BBRv2 算法

义达
660 阅读8分钟

从流量控制算法谈网络优化 – 从 CUBIC 到 BBRv2 算法

转自：aws.amazon.com/cn/blogs/ch…

TCP与UDP

UDP概括起来是一个“发送后不管”的协议。它是无状态的，没有拥塞控制或可靠的传输支持，这也导致了网络运营商会针对UDP协议的限流。我们经常看到UDP被用于DNS（域名系统）和NTP（网络时间协议）等。与之相对，TCP则像是UDP互补的孪生兄弟，提供了可靠的传输和流量控制，因此TCP协议也变得相当复杂。

人们通常认为TCP和UDP的主要区别就是TCP给我们提供了可靠的数据包传输。当然这是TCP最重要的功能之一，但TCP协议还为我们提供了流量控制。流量控制关乎网络使用的公平性，这对互联网的有效运行是至关重要的。TCP使用多种拥塞控制策略来避免拥塞。具体来讲，TCP会为每条连接维护一个“拥塞窗口”来限制可能在端对端间传输的未确认分组的总数量。并且，TCP在一个连接初始化或超时后使用一种“慢启动”机制来增加拥塞窗口的大小。所谓的“慢启动”，指的是初始值虽然比较低，但其增长极快：当每个分段得到确认时，拥塞窗口会增加一个MSS（Maximum segment size），使得在每次往返时间（Round-trip time，RTT）内拥塞窗口能高效地双倍增长。设想一下，如果没有这种形式的流量控制，互联网注定会在海量的数据传输之下不堪使用。

TCP拥塞算法

许多年来，不同的流量控制算法已经在各种TCP堆栈中实现和使用。例如Cubic、Tahoe、Vegas、Reno、Westwood，以及最近流行的BBR等。这些都是TCP中使用的不同拥塞控制算法。这些算法的作用是决定发送方应该以多快的速度发送数据，并同时适应网络的变化。

查看拥塞算法

Cubic 是一种较为温和的拥塞算法，它使用三次函数作为其拥塞窗口的算法，并且使用函数拐点作为拥塞窗口的设置值。Linux内核在2.6.19后使用该算法作为默认TCP拥塞算法。

# 检查当前可用的拥塞算法
$ sudo sysctl net.ipv4.tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = cubic reno
# 查看当前使用的拥塞算法
$ sudo sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = cubic

BBR 算法

TCP的BBR（Bottleneck Bandwidth and Round-trip propagation time，BBR）是谷歌在2016年开发的一种新型的TCP 拥塞控制算法。在此以前，互联网主要使用基于丢包的拥塞控制策略，只依靠丢失数据包的迹象作为减缓发送速率的信号。如今我们拥有了越来越大的带宽，而现在的互联网质量也越来越好。于是我们观察到了一些新的问题，比如影响延迟的缓冲区膨胀的问题。BBR尝试通过使用全新的拥塞控制来解决这个问题，它使用基于延迟而不是丢包作为决定发送速率的主要因素。

BBR算法的优势

吞吐量的改善在远距离路径上尤为明显，比如跨太平洋的文件或者大数据的传输，尤其是在有轻微丢包的网络条件下。延迟的改善主要体现在最后一公里的路径上，而这一路径经常受到缓冲膨胀（Bufferbloat）的影响。所谓“缓冲膨胀”指的网络设备或者系统不必要地设计了过大的缓冲区。当网络链路拥塞时，就会发生缓冲膨胀，从而导致数据包在这些超大缓冲区中长时间排队。在先进先出队列系统中，过大的缓冲区会导致更长的队列和更高的延迟，并且不会提高网络吞吐量。由于BBR并不会试图填满缓冲区，所以在避免缓冲区膨胀方面往往会有更好的表现。

BBR的缺点

首先，因为它倾向于抢占Cubic算法的带宽，在网络公平性上明显存在不足；其次BBR的机制会导致高重传率；第三点是在Wi-Fi环境下用户的网速明显变慢。

BBR算法测试

默认没有延迟的情况：4.98Gbits/秒

延迟对TCP吞吐量的影响sudo tc qdisc replace dev eth0 root netem latency 50ms

取消延迟：sudo tc qdisc del dev eth0 root

增加100ms延迟下cubic：611 Mbits/秒

增加100ms延迟下bbr：609 Mbits/秒

丢包对吞吐量的影响sudo tc qdisc replace dev eth0 root netem loss 1.5% latency 50ms

增加丢包cubic：10.5 Mbs/秒

增加丢包bbr：333Mbits/秒

总结

上面的测试显示了丢包和延迟对TCP吞吐量的巨大影响。在一个高延迟的路径上，仅仅是少量的数据包丢失（1.5%）就会产生了巨大的影响。在这些较长的路径上使用除BBR以外的任何其他技术，当出现哪怕是少量的丢包时，都会造成很大的问题。也只有BBR在任何超过1.5%的丢包损失时都能保持一个不错的吞吐量数字。

# 查看TCP性能
$ ss -tni
State                   Recv-Q                Send-Q                               Local Address:Port                                    Peer Address:Port                 Process
ESTAB                   0                     0                                       10.46.0.14:42008                                     10.46.0.30:4332
	 cubic wscale:7,7 rto:201 rtt:0.478/0.358 ato:57 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:20 ssthresh:20 bytes_sent:368934938 bytes_acked:368934939 bytes_received:4096303512 segs_out:726680 segs_in:3024953 data_segs_out:427782 data_segs_in:2990834 send 484686192bps lastsnd:20 lastrcv:20 lastack:20 pacing_rate 581471368bps delivery_rate 32357536bps delivered:427783 app_limited busy:96662ms rcv_rtt:1.051 rcv_space:1232188 rcv_ssthresh:3145728 minrtt:0.045
ESTAB                   0                     0                                       10.46.0.14:41990                                     10.46.0.30:4332
	 cubic wscale:7,7 rto:201 rtt:0.34/0.157 ato:62 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:10 ssthresh:20 bytes_sent:369829144 bytes_acked:369829145 bytes_received:4129949751 segs_out:727366 segs_in:3048214 data_segs_out:428324 data_segs_in:3013969 send 340705882bps lastsnd:8 lastrcv:8 lastack:8 pacing_rate 408847056bps delivery_rate 1261623760bps delivered:428325 app_limited busy:96739ms rcv_rtt:1 rcv_space:1279525 rcv_ssthresh:3145728 minrtt:0.074
ESTAB                   0                     0                                       10.46.0.14:42010                                     10.46.0.30:4332
	 cubic wscale:7,7 rto:201 rtt:0.444/0.201 ato:60 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:10 ssthresh:20 bytes_sent:367074640 bytes_retrans:4344 bytes_acked:367070297 bytes_received:4006695991 segs_out:722454 segs_in:2962046 data_segs_out:426494 data_segs_in:2928130 send 260900901bps lastsnd:16 lastrcv:16 lastack:16 pacing_rate 312816872bps delivery_rate 1829052624bps delivered:426495 app_limited busy:97147ms retrans:0/3 dsack_dups:3 reordering:4 reord_seen:1 rcv_rtt:1 rcv_space:1236126 rcv_ssthresh:3145728 minrtt:0.076

何时使用BBR

网络在没有丢包的情况下，Cubic和BBR对于这些较长时延的链路都有很好的表现。而在中度丢包的情况下，BBR的表现就非常突出了。当我们在不同的地方放置有服务器，需要在系统或者服务器之间有源源不断的数据传输。例如日志文件、数据库同步、业务数据的异地备份等等。而在复杂的网络环境下，会因为各种原因而出现丢包的情况。在这种场景下，BBR将会大放异彩，帮助您维护更好的网络数据传输。

BBRv2

在我们的测试中，BBRv2显示了以下特性:

  1. 对于网速较低的用户来说，带宽可以与CUBIC媲美。
  2. 对于网速较高的用户来说，带宽可以与BBRv1媲美。
  3. 丢包率比BBRv1低4倍；但仍然比CUBIC高2倍。
  4. 传输中的数据比BBRv1低3倍；但略低于CUBIC。
  5. RTTs较BBRv1低；但仍然比CUBIC高。
  6. 与BBRv1相比，RTT具有更高的公平性。

总的来说，BBRv2在BBRv1基础上有了很大的改进，而且在需要更高带宽的情况下，它更接近于成为Reno/CUBIC的完全替代品。

avatar
文章
阅读
粉丝