tcp pacing && bbr

最新推荐文章于 2024-04-17 18:51:55 发布

linuxheik

最新推荐文章于 2024-04-17 18:51:55 发布

阅读量1.1k

点赞数

分类专栏： bbr

本文链接：https://blog.csdn.net/linuxheik/article/details/79724061

版权

bbr 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

作者：tsetao
链接：https://www.zhihu.com/question/53559433/answer/136002384
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

在探讨这个问题之前，关于网络中的Bufferbloat问题需要了解，详细信息在这里（https://www.bufferbloat.net/projects/bloat/wiki/Introduction/），

的回答也说得比较清楚了。

在这里做一些补充吧。
流量控制分为两部分：
* 接收方的流量控制（即滑动窗口）-- 由接收方告知，只关注自身缓存情况，不关注网络，这里不讨论。
* 发送方的流量控制（即拥塞控制）
现在广泛使用的CUBIC/(new)Reno都是基于丢包的，在算法上重点输出拥塞窗口（cwnd）；
而BBR输出cwnd和pacing_rate，且pacing_rate为主，cwnd为辅，参考(https://groups.google.com/d/msg/bbr-dev/bIIdBU4feD8/sfmbh4W_DgAJ)

什么是pacing？看下图：

&amp;lt;img src="https://pic3.zhimg.com/50/v2-033f904724e92977e6f6e13942e3981f_hd.jpg" data-rawwidth="981" data-rawheight="573" class="origin_image zh-lightbox-thumb" width="981" data-original="https://pic3.zhimg.com/v2-033f904724e92977e6f6e13942e3981f_r.jpg"&amp;gt; 图片引用来自 QUIC @ Google Developers Live, February 2014
也就是说早期的拥塞控制输出cwnd只是告诉tcp可以发多少数据，而没有说怎么发，恰好， BBR输出的pacing_rate就是告诉TCP怎么发。

BBR对TCP的大胆改动：

&amp;lt;img src="https://pic2.zhimg.com/50/v2-b742e172ed1ae802bab8e0903f47f98c_hd.jpg" data-rawwidth="563" data-rawheight="328" class="origin_image zh-lightbox-thumb" width="563" data-original="https://pic2.zhimg.com/v2-b742e172ed1ae802bab8e0903f47f98c_r.jpg"&amp;gt; 红框中是BBR加入时添加的，这里很明显，BBR从TCP接管了充分的控制权。
之前的拥塞控制并不总是能起作用，换句话说就是会被夺权。TCP走进PRR算法（ 参考论文：Proportional Rate Reduction for TCP）后，拥塞控制无能为力。
从工程实现的角度来看，BBR这个小小的修改把TCP的 可靠传输 / 拥塞控制 解耦了 —— TCP你专注于自己的可靠性（当然还有很多其它细节），我BBR总是会负责任地告诉你（TCP）现在可以发多少数据，以什么速度发出这些数据。

丢包对BBR有什么影响？
&amp;lt;img src="https://pic4.zhimg.com/50/v2-2fe40d036eae2f25045242ce9e6f8f86_hd.jpg" data-rawwidth="928" data-rawheight="481" class="origin_image zh-lightbox-thumb" width="928" data-original="https://pic4.zhimg.com/v2-2fe40d036eae2f25045242ce9e6f8f86_r.jpg"&amp;gt;
图片来自 BBR-TCP-Opportunities
从算法上来讲，丢包对BBR的影响微乎其微。BBR只管告诉TCP cwnd/pacing_rate， 不管需要发送的包是重传的还是正常发送的。看上图，丢包率在20%的时候BBR的输出骤降，导致这个现象其实是从实现层面考虑设置的一个阈值。

/* If lost/delivered ratio > 20%, interval is "lossy" and we may be policed: */
static const u32 bbr_lt_loss_thresh = 50;

这里还考虑了被限速的场景，不展开。

友好性测试
提到的友好性问题，google groups里有测试数据
https://groups.google.com/d/msg/bbr-dev/zyvKgjjOYr8/pN20-CmVBQAJ
----------------
10 Mbps link with 40ms RTT
带宽，RTT固定的情况下，测试不同Buffer大小的情况：

buf以n倍BDP表示，CUBIC/Vegas/BBR输出单位Mbps
(1) 1 CUBIC flow vs. 1 Vegas flow:
buf  CUBIC  Vegas
---- -----  -----
0.5   6.81   2.73
1     8.49   1.06
2     9.12   0.43
4     9.15   0.4

(2) 1 CUBIC flow vs. 1 BBR flow:
buf  CUBIC  BBR
---- -----  -----
0.5   1.74   7.67
1     1.71   7.7
2     4.79   4.72
4     6.12   3.43

说明：
Vegas是基于延迟的拥塞控制，现在几乎不用了，因为它们跟基于丢包的拥塞控制发生竞争时会处于几乎饿死的状态。
另外，关于Ledbat（基于延迟的）用于BT，是理所应当的（挂BT下载的急迫性一般是低于常规网络流量的，当有常规流量介入时，主动退避是符合常理的）。

v------------2016.12.20更新--------------v
bbr-dev邮件组中一组测试数据（

的回答中也提供了）引起了大家的关注。
最开始，Leo Zhang的回答所提到的测试报告我并未详细阅读。今天抽时间详细看了一下，感到意外。
比如出现BBR饿死CUBIC，BBR饿死同类。这和其它测试数据出入很大。

我第一反应就是环境不对，BBR挑环境。然而这方面却没找到说明，BBR相关的文档都没有提到专用场景。

接着，

抛出了另一个问题（如何评价文章《令人躁动一时且令人不安的TCP BBR算法》？）。看过文章（该作者之前的文章也看了），写了简答，才发现自己似乎错过了什么，同时自己其实也对20%的丢包率阈值设置有疑问，偷懒的理解就是大量测试统计的结果吧。

这些天bbr-dev中关于BBR Report（ https://groups.google.com/forum/#!topic/bbr-dev/Ps4zyM5AD9g）这份精彩的邮件列表我错过了，赶紧补一下！
Neal Cardwell 说到：

We are actively working on reducing the buffer pressure exerted by BBR, which should help in the sorts of CUBIC vs BBR scenarios you describe (as well as BBR vs BBR scenarios).

这份刚刚诞生的拥塞控制的确还是存在不少缺陷，不过依然在持续改进中，期待美好的事情总会发生吧！
^-------------2016.12.20更新-------------^

根据

的回答中已经提到的实测延迟改善数据，我们可以看到目前互联网整体上Bufferbloat问题是比较严重的，即我们的网络请求延迟总体被拉高很多。
为了降低延迟，如果：
1、我们改用基于延迟的拥塞控制，因为不可能一时间全部更新，先替换的那部分网络体验会很糟糕；
2、逐步改用BBR这类拥塞控制，我们的网络高延迟问题将会逐渐得到改善。

以上并非说一定是BBR，但是BBR在拥塞控制上开辟了一条新的路（也许早就有人做过类似的尝试，但是因为工程实现，或者测试环境受限不能得到广泛验证，石沉大海），相信以后关于拥塞控制的研究改进更多会基于这条路去走。

最后，BBR是基于什么的拥塞控制？
根据论文，是基于拥塞的拥塞控制（Congestion-based Congestion Control），但是看起来感觉不好理解。
根据我的理解，我更倾向于称它为基于带宽延迟的拥塞控制（BDP-based Congestion Control）。
因为，BBR总是在测量最小RTT（10s内），最大Bandwidth（10 Round Trips），并且尽量控制输出到网络的数据包（in-flight）靠近 BDP（without buffer），这样既能保证带宽利用率，又能避免Bufferbloat问题。

PS. BBR也已经被实现在QUIC协议中，参考（https://cs.chromium.org/chromium/src/net/quic/core/congestion_control/bbr_sender.h）。

我也并非完全理解了BBR的实现细节，并且其中还牵扯到TCP的实现，也不熟悉。
如果以上理解有错，或者不到位，欢迎指正。

完。

---
XTao