TCP BBR：修订间差异
无编辑摘要 |
无编辑摘要 |
||
| （未显示同一用户的2个中间版本） | |||
| 第5行： | 第5行： | ||
而BBR主要是估計寬帶和延遲狀況，則是不斷偵測封包傳輸的錯誤率，根據總傳輸量和錯誤量的比例來決定要以何種頻寬傳輸，降低緩衝區堵塞的狀況，進而提高傳輸速度。Google 率先將 BBR 用在 google.com 及 YouTube 上，大幅提高了頻寬使用效率，全球網路平均傳輸量提升4%，最高更達到14%，雙向傳播時間加快三成，重新緩衝的平均時間也增長11%。 | 而BBR主要是估計寬帶和延遲狀況，則是不斷偵測封包傳輸的錯誤率，根據總傳輸量和錯誤量的比例來決定要以何種頻寬傳輸，降低緩衝區堵塞的狀況，進而提高傳輸速度。Google 率先將 BBR 用在 google.com 及 YouTube 上，大幅提高了頻寬使用效率，全球網路平均傳輸量提升4%，最高更達到14%，雙向傳播時間加快三成，重新緩衝的平均時間也增長11%。 | ||
= BBR原理 = | |||
传统拥塞控制算法并不是一蹴而就的，复杂的网络环境和用户的高要求推动着拥塞控制算法的优化和迭代，我们看下基于丢包策略的传统拥塞控制算法的几个迭代版本，如图所示： | 传统拥塞控制算法并不是一蹴而就的，复杂的网络环境和用户的高要求推动着拥塞控制算法的优化和迭代，我们看下基于丢包策略的传统拥塞控制算法的几个迭代版本，如图所示： | ||
[[Image:congestion control1.png|600px]] | [[Image:congestion control1.png|600px]] | ||
与此同时还有一类算法是基于RTT延时策略来进行控制的，但是这类算法在发包速率上可能不够激进，竞争性能不如其他算法，因此在共享网络带宽时有失公平性，但是算法速率曲线却是很平滑： | 与此同时还有一类算法是基于RTT延时策略来进行控制的，但是这类算法在发包速率上可能不够激进，竞争性能不如其他算法，因此在共享网络带宽时有失公平性，但是算法速率曲线却是很平滑： | ||
[[Image:congestion control2.webp|600px]] | [[Image:congestion control2.webp|600px]] | ||
TCP BBR(Bottleneck Bandwidth and Round-trip propagation time)是由Google设计，并于2016年发布的拥塞算法，以往大部分拥塞算法是基于丢包来作为降低传输速率的信号，而BBR基于模型主动探测。 | |||
该算法使用网络最近出站数据分组当时的最大带宽和往返时间来创建网络的显式模型。数据包传输的每个累积或选择性确认用于生成记录在数据包传输过程和确认返回期间的时间内所传送数据量的采样率。 | |||
该算法认为随着网络接口控制器逐渐进入千兆速度时，分组丢失不应该被认为是识别拥塞的主要决定因素，所以基于模型的拥塞控制算法能有更高的吞吐量和更低的延迟，可以用BBR来替代其他流行的拥塞算法例如CUBIC。Google在YouTube上应用该算法，将全球平均的YouTube网络吞吐量提高了4%，在一些国家超过了14%。BBR之后移植入Linux内核4.9版本，并且对于QUIC可用。 | |||
* Ref：https://zhuanlan.zhihu.com/p/469291099 | * Ref：https://zhuanlan.zhihu.com/p/469291099 | ||
= 开启BBR= | |||
<syntaxhighlight lang="bash"> | |||
sysctl net.ipv4.tcp_available_congestion_control | |||
vi /etc/sysctl.conf | |||
net.core.default_qdisc=fq | |||
net.ipv4.tcp_congestion_control=bbr | |||
</syntaxhighlight> | |||
[[Category:Network]] | [[Category:Network]] | ||
[[Category:TCP/IP]] | [[Category:TCP/IP]] | ||
2024年1月17日 (三) 11:21的最新版本
BBR（Bottleneck Bandwidth and Round-trip propagation time）是Google的一種壅塞控制演算法，在網路連結的電腦或行動裝置中運行，可決定數據發送的速度，旨在解決網路壅塞問題。在啟用BBR前，自1980年代起，TCP/IP ( TCP/IP Protocol Suite ) 的演算法大多都是先觀測傳輸時封包是否有丟失狀況，如果有丟失則認識此為網路壅塞，而處理方式是全面降速，直到丟失的封包成功傳出，此舉會導致緩衝區不斷擴大，在傳輸大量資料時速度越來越慢、最後卡死。[1]
而BBR主要是估計寬帶和延遲狀況，則是不斷偵測封包傳輸的錯誤率，根據總傳輸量和錯誤量的比例來決定要以何種頻寬傳輸，降低緩衝區堵塞的狀況，進而提高傳輸速度。Google 率先將 BBR 用在 google.com 及 YouTube 上，大幅提高了頻寬使用效率，全球網路平均傳輸量提升4%，最高更達到14%，雙向傳播時間加快三成，重新緩衝的平均時間也增長11%。
BBR原理
传统拥塞控制算法并不是一蹴而就的，复杂的网络环境和用户的高要求推动着拥塞控制算法的优化和迭代，我们看下基于丢包策略的传统拥塞控制算法的几个迭代版本，如图所示：
与此同时还有一类算法是基于RTT延时策略来进行控制的，但是这类算法在发包速率上可能不够激进，竞争性能不如其他算法，因此在共享网络带宽时有失公平性，但是算法速率曲线却是很平滑：
TCP BBR(Bottleneck Bandwidth and Round-trip propagation time)是由Google设计，并于2016年发布的拥塞算法，以往大部分拥塞算法是基于丢包来作为降低传输速率的信号，而BBR基于模型主动探测。 该算法使用网络最近出站数据分组当时的最大带宽和往返时间来创建网络的显式模型。数据包传输的每个累积或选择性确认用于生成记录在数据包传输过程和确认返回期间的时间内所传送数据量的采样率。 该算法认为随着网络接口控制器逐渐进入千兆速度时，分组丢失不应该被认为是识别拥塞的主要决定因素，所以基于模型的拥塞控制算法能有更高的吞吐量和更低的延迟，可以用BBR来替代其他流行的拥塞算法例如CUBIC。Google在YouTube上应用该算法，将全球平均的YouTube网络吞吐量提高了4%，在一些国家超过了14%。BBR之后移植入Linux内核4.9版本，并且对于QUIC可用。
开启BBR
sysctl net.ipv4.tcp_available_congestion_control
vi /etc/sysctl.conf
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr