何时使用和不使用BBR

原文链接：https://blog.apnic.net/2020/01/10/when-to-use-and-not-use-bbr/

TCP BBR(Bottleneck Bandwidth and Round-trip propagation time)是由Google设计，并于2016年发布的拥塞算法，以往大部分拥塞算法是基于丢包来作为降低传输速率的信号，而BBR基于模型主动探测。

不过，在具体谈论应该BBR合适的应用场景之前，有必要先回顾一下传统拥塞控制算法的弊端所在。

1.传统拥塞控制算法的弊端（即BBR试图解决的问题）

TCP拥塞控制算法已经持续发展了30多年，主流的拥塞控制算法是基于丢包的，即它们将数据包丢失作为拥塞信号。例如，Linux的默认TCP算法Cubic在遇到数据包丢失时将其拥塞窗口降低了30％。

但是，在某些情况下，基于丢包的TCP算法效果不佳。例如，在浅缓冲区中，数据包丢失可能被误解为网络拥塞，从而导致吞吐量降低和网络利用率降低。另一方面，在较深的缓冲区中，数据包通常要花很长时间才能填满缓冲区。这将导致较高的网络延迟，这称为缓冲膨胀问题。

为了解决此类问题，Google在2016年提出了BBR。BBR不会使用数据包丢失作为拥塞信号，而是根据观察到的带宽和延迟值来调节其流量。具体来说，BBR将其传输中的数据包数量限制为时延带宽积（BDP）的倍数。此外，BBR还使用 pacing来控制数据包之间的间隔。

重点：

• 瓶颈缓冲区大小和时延带宽积（BDP）之间的差异通常指示BBR何时运行良好。在较大的BDP和较浅的缓冲区大小下，BBR可获得更高的吞吐量。

• 与Cubic相比，BBR可能导致100倍的数据包重传。

• BBR和Cubic之间的不公平性取决于瓶颈缓冲区的大小—如果缓冲区大小较小（10KB），则BBR可以获取总带宽的90％以上；具有较大的缓冲区大小（10MB），Cubic可获得大约80％的总带宽。

2.BBR的优势和劣势

虽然BBR是为了解决基于丢包的拥塞控制算法的某些问题而提出的，但是这并不意味着在所有的情况下，BBR都比基于丢包的拥塞控制算法有更好的性能。

为了探究BBR在何种情况下相比较基于丢包的拥塞控制算法有更好的性能，原作者进行了几个相关的实验，旨在探究：

• BBR什么时候更有用（与基于丢包的算法（例如Cubic）相比）

• BBR忽略数据包丢失的缺点是什么？

• BBR是否对基于丢包的算法不公平？（答案是yes）

原作者和其在石溪大学的同事们在不同的网络条件下，跨不同的网络测试平台（LAN，WAN，Mininet）进行了广泛的测量研究，从而做到了这一点。他们在路由器上部署了流量控制器，以进行细粒度的网络参数控制，并使用带有NetEm的Linux流量控制（TC）来设置网络延迟，并使用令牌桶过滤器（TBF）来设置网络带宽和缓冲区大小。

2.1BBR在何时更有效？

为了研究BBR或Cubic在不同情况下能否获得更高的吞吐量，他们在局域网中进行了640个iperf3实验。在这些实验中，收集了BBR和Cubic的有效值，并通过决策树（使用Python3中的DecisionTreeClassifier包）将这些值进行了概括。

在决策树中，橙色节点表示BBR获得更高吞吐量的实例，而蓝色节点代表Cubic获得更高吞吐量的实例。图中可以观察到，瓶颈缓冲区大小和BDP之间的相对差异通常决定了BBR何时运行良好-在较小的BDP和较深的缓冲区大小下，Cubic可获得较高的吞吐量，而在较大的BDP和较浅的缓冲区大小下，BBR可获得较高的吞吐量。更高的产量。

也就是BBR与CDP呈现正相关，与缓冲区大小呈现负相关，而Cubic恰恰相反。

 为了分析和量化BBR与浅缓冲区中的Cubic相比，吞吐量的提高，定义一个以下指标：

GpGain = (goodput|BBR – goodput|Cubic) / goodput|Cubic x 100（显然，当BBR更有效时，GpGain为正数）

 对于较浅的缓冲区大小（100KB）的情况下，在图2中展示了在不同的RTT和带宽值下GpGain指标的热图。我们观察到BBR与Cubic相比有显着改善。例如，在200ms的RTT和500Mbps的带宽下，与Cubic相比，BBR的吞吐量提高了115％。这是因为BBR使用带宽和延迟估计作为拥塞信号而不是数据包丢失。

 2.2忽略丢包的缺点

BBR需要将2BDP数据保留在网络中（额外的BDP数据用于处理延迟/聚合的ACK），在浅缓冲区中，这些额外的数据BDP将导致巨大的数据包重传。

更糟糕的是，BBR不会将丢包视为拥塞信号，这会导致高重传率的保持。下面的热图（图3）显示了在不同的RTT和带宽值下BBR和Cubic的数据包重传次数。

图3中可以观察到，BBR导致的数据包重传比Cubic的重传100倍。这表明BBR是以浅缓冲区中的高数据包重传为代价提高吞吐量。因此，如果传递的内容对丢包敏感，那么BBR可能不是一个好选择。在这种情况下，内容提供商需要仔细检查吞吐量和体验质量之间的权衡。

 3.BBR的cliff point

在这些实验中可以发现有一个“cliff point”-即损失百分比，超出此百分比，BBR的实际吞吐量会大大下降。如图5（左）所示，BBR的吞吐量保持几乎满负荷，直到损失百分比达到20％。

 经分析，cliff point与BBR的最大pacing_gain参数密切相关，该参数决定了其探测能力。如果丢包概率为p，则在带宽探测期间，BBR的速度为pacing_gain×带宽（BW）。但是，由于损耗，其有效pacing为pacing_gain×BW×（1- p）。因此，如果此值小于带宽，则BBR将不会探测额外的容量，并且会因丢包而推断出较低的容量。

4.总结

总的来说，BBR作为在Cubic之后提出的拥塞控制算法，它的有很多优点，并且解决了Cubic算法存在的一些问题，但是因为它并非是采用丢包作为拥塞信号，也带来了一些新的问题。

• BBR的公平性存在问题，它会抢占Cubic算法的带宽（取决于瓶颈缓冲区的大小）

• BBR的机制会导致高重传率

 BBR目前来看，只能说和Cubic更有优劣，两者擅长处理的网络环境并不相同。不过它不采用丢包作为拥塞信号，而是通过自己评估，也许会在其他的环境下取得更好的成绩，比如说和强化学习相结合。

==================

来源  https://pylist.com/topic/186.html#:~:text=BBR%20%E6%98%AF%E4%B8%80%E7%A7%8D%E5%8D%8F%E8%AE%AE%E7%AE%97%E6%B3%95%EF%BC%8C%E5%9C%A8%20Openwrt%20%E8%B7%AF%E7%94%B1%E4%B8%8A%E5%90%AF%E7%94%A8,BBR%20%E8%BF%98%E6%98%AF%E6%9C%89%E4%B8%80%E5%AE%9A%E4%BD%9C%E7%94%A8%E7%9A%84%E3%80%82%20Openwrt%2018.%2A

BBR 是一种协议算法，在 Openwrt 路由上启用 BBR 还是有一定作用的。 Openwrt 18.* 后都自带模块 kmod-tcp-bbr 安装就可以。

看内核版本

12

root@OpenWrt:~# uname -r4.9.184root@OpenWrt:~# uname -r4.9.184

安装 kmod-tcp-bbr

12

opkg update
opkg install kmod-tcp-bbropkg update
opkg install kmod-tcp-bbr

会安装相关的 ipk

123

Configuring kmod-sched-core.Configuring kmod-sched.Configuring kmod-tcp-bbr.Configuring kmod-sched-core.Configuring kmod-sched.Configuring kmod-tcp-bbr.

查看相关情况

1234567891011121314151617181920212223

root@OpenWrt:~# sysctl net.ipv4.tcp_congestion_controlnet.ipv4.tcp_congestion_control = cubic
root@OpenWrt:~# sysctl net.ipv4.tcp_available_congestion_controlnet.ipv4.tcp_available_congestion_control = cubic reno bbr
root@OpenWrt:~# sysctl net.core.default_qdiscnet.core.default_qdisc = fq_codel
root@OpenWrt:~# lsmod | grep bbrtcp_bbr                 4832  0 root@OpenWrt:~# cat /etc/sysctl.conf# Defaults are configured in /etc/sysctl.d/* and can be customized in this fileroot@OpenWrt:~# ls -l /etc/sysctl.d/-rw-r--r--    1 root     root           675 Jun 27 12:18 10-default.conf
-rw-r--r--    1 root     root           379 Jun 27 12:18 11-nf-conntrack.conf
-rw-r--r--    1 root     root           184 Jun 27 12:18 12-tcp-bbr.conf
root@OpenWrt:~# cat /etc/sysctl.d/12-tcp-bbr.conf # Do not edit, changes to this file will be lost on upgrades# /etc/sysctl.conf can be used to customize sysctl settingsnet.ipv4.tcp_congestion_control=bbr
net.core.default_qdisc=fq
root@OpenWrt:~# sysctl -proot@OpenWrt:~# lsmod | grep bbrtcp_bbr                 4832  0 root@OpenWrt:~# sysctl net.ipv4.tcp_congestion_controlnet.ipv4.tcp_congestion_control = cubic
root@OpenWrt:~# sysctl net.ipv4.tcp_available_congestion_controlnet.ipv4.tcp_available_congestion_control = cubic reno bbr
root@OpenWrt:~# sysctl net.core.default_qdiscnet.core.default_qdisc = fq_codel
root@OpenWrt:~# lsmod | grep bbrtcp_bbr                 4832  0 root@OpenWrt:~# cat /etc/sysctl.conf# Defaults are configured in /etc/sysctl.d/* and can be customized in this fileroot@OpenWrt:~# ls -l /etc/sysctl.d/-rw-r--r--    1 root     root           675 Jun 27 12:18 10-default.conf
-rw-r--r--    1 root     root           379 Jun 27 12:18 11-nf-conntrack.conf
-rw-r--r--    1 root     root           184 Jun 27 12:18 12-tcp-bbr.conf
root@OpenWrt:~# cat /etc/sysctl.d/12-tcp-bbr.conf # Do not edit, changes to this file will be lost on upgrades# /etc/sysctl.conf can be used to customize sysctl settingsnet.ipv4.tcp_congestion_control=bbr
net.core.default_qdisc=fq
root@OpenWrt:~# sysctl -proot@OpenWrt:~# lsmod | grep bbrtcp_bbr                 4832  0

还没生效，重启路由后再看看

1234

root@OpenWrt:~# lsmod | grep bbrtcp_bbr                 4832 21 root@OpenWrt:~# sysctl net.ipv4.tcp_congestion_controlnet.ipv4.tcp_congestion_control = bbr
root@OpenWrt:~# lsmod | grep bbrtcp_bbr                 4832 21 root@OpenWrt:~# sysctl net.ipv4.tcp_congestion_controlnet.ipv4.tcp_congestion_control = bbr

BBR 加速生效了！

推荐本站淘宝优惠价购买喜欢的宝贝:

本文链接：https://hqyman.cn/post/6857.html 非本站原创文章欢迎转载，原创文章需保留本站地址！

打赏

微信支付宝扫一扫，打赏作者吧～

休息一下~~