主机推广
TCP 拥塞控制算法
传统 TCP 拥塞控制算法，基于丢包反馈的协议。
基于「丢包反馈」的协议是一种 被动式 的拥塞控制机制，其依据网络中的丢包事件来做网络拥塞判断。即便网络中的负载很高时，只要没有产生拥塞丢包，协议就不会主动降低自己的发送速度。
这种协议可以最大程度的利用网络剩余带宽，提高吞吐量。然而，由于基于丢包反馈协议在网络近饱和状态下所表现出来的侵略性，一方面大大提高了网络的带宽利用率；但另一方面，对于基于丢包反馈的拥塞控制协议来说，大大提高网络利用率同时意味着下一次拥塞丢包事件为期不远了，所以这些协议在提高网络带宽利用率的同时也间接加大了网络的丢包率，造成整个网络的抖动性加剧。
还有谁导致了丢包？
丢包并不总是拥塞导致，丢包可能原因是多方面，比如：
- 全球最牛的防火墙 GWF 的随机丢包策略
- 网路中由于多路径衰落（multi-path fading）所造成的信号衰减（signal degradation）
- 通道阻塞造成的丢包（packet drop），再者损坏的封包（corrupted packets）被拒绝通过
- 有缺陷的网路硬件、网路驱动软件发生故障
- 信号的信噪比（SNR）的影响
Google BBR 的出现
我们自然不喜欢 GWF 这种人为的随机丢包策略，当路过 GWF 时，数据被丢包，我们在此时应该立刻重新发包，增大发送的频率，而不希望降低速度，也就是不希望传统的 TCP 拥塞算法去控制。
由此，就出现了基于不丢包的拥塞控制算法 CDG， 以 延迟 作为判断依据，延迟增大说明拥塞, 数据开始在路由器的缓冲中积累. 降低发送 窗口。然而 CDG 算法与基于丢包的算法不兼容, 只有全球的设备都换上 CDG，但这是不可能的，目前市面上的设备不可能一下子都切换到 CDG，因此 Google 就不开心了，Google 的科学家们开发了一种过渡算法来解决这个问题，这个算法的名字就是 BBR（Bottleneck Bandwidth and RTT），它是一种全新的 拥塞控制算法，BBR 同 CDG 一致的思想是不以丢包作为拥塞控制信号，但是和 CDG 不同的是，BBR 能和 cubic 和 reno 共存。
? 使用BBR前后网络吞吐量对比图 / By Google
BBR 由 Google 开发，供 Linux 内核的 TCP 协议栈使用，有了 BBR 算法，Linux 服务器可以显著提高吞吐量并减少连接延迟，简单来说 BBR 能加速网络传输速度。此外，部署 BBR 也很容易，因为该算法只需要发送方，而不需要网络或接收方的支持。
CentOS 7 服务器实例上部署 BBR
下面我将向您分享我如何在 CentOS 7 KVM 服务器实例上部署 BBR。
步骤〇： 前置条件
- CentOS 7 x64 服务器实例。
- 一个 sudo 用户
步骤 ① ：使用 ELRepo RPM 仓库升级内核
要使用BBR，您需要将CentOS 7机器的内核升级到4.9.0。您可以使用ELRepo RPM第三方仓库轻松完成该操作。
在升级之前，您可以查看当前内核：
uname -r
|
此命令应可能输出类似于以下字符串：
3.10.0-514.2.2.el7.x86_64
|
如您所见，当前内核为3.10.0，因此我们需要更新内核。
更新内核之前，先安装 ELRepo 仓库：
sudo rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org sudo rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm |
使用ELRepo repo安装4.9.0内核：
sudo yum --enablerepo=elrepo-kernel install kernel-ml -y
|
确认结果：
rpm -qa | grep kernel
|
如果安装成功，您应该看到类似于一下列，且kernel-ml-4.18.5-1.el7.elrepo.x86_64在输出列表中看到：
kernel-ml-4.18.5-1.el7.elrepo.x86_64 kernel-3.10.0-514.el7.x86_64 kernel-tools-libs-3.10.0-514.2.2.el7.x86_64 kernel-tools-3.10.0-514.2.2.el7.x86_64 kernel-3.10.0-514.2.2.el7.x86_64 |
现在，您需要通过设置默认引导为 grub2 ，来启用4.18.5内核。
显示 grub2 菜单中的所有条目：
sudo egrep ^menuentry /etc/grub2.cfg | cut -f 2 -d \'
|
结果应该类似于：
CentOS Linux 7 Rescue a0cbf86a6ef1416a8812657bb4f2b860 (4.18.5-1.el7.elrepo.x86_64) CentOS Linux (4.18.5-1.el7.elrepo.x86_64) 7 (Core) CentOS Linux (3.10.0-514.2.2.el7.x86_64) 7 (Core) CentOS Linux (3.10.0-514.el7.x86_64) 7 (Core) CentOS Linux (0-rescue-bf94f46c6bd04792a6a42c91bae645f7) 7 (Core) |
由于行计数开始于0，且4.18.5内核条目位于第一行，因此将默认引导条目应设置为0：
sudo grub2-set-default 0
|
重启系统：
sudo shutdown -r now // 或 reboot |
当服务器重新联机时，请重新登录并重新运行uname命令以确认您使用的是正确的内核：
uname -r
|
您应该看到如下结果：
4.18.5-1.el7.elrepo.x86_64
|
步骤 ②：启用BBR
要启用 BBR 算法，您需要修改sysctl配置，如下所示：
echo 'net.core.default_qdisc=fq' | sudo tee -a /etc/sysctl.conf echo 'net.ipv4.tcp_congestion_control=bbr' | sudo tee -a /etc/sysctl.conf sudo sysctl -p |
现在，您可以使用以下命令，确认是否已经启用了BBR：
sudo sysctl net.ipv4.tcp_available_congestion_control
|
正常情况下应输出类似以下的字符串：
net.ipv4.tcp_available_congestion_control = bbr cubic reno
|
接下来，继续验证：
sudo sysctl -n net.ipv4.tcp_congestion_control
|
应该输出类似以下字符串：
bbr
|
最后，检查内核模块是否已加载：
lsmod | grep bbr
|
应该输出类似于：
tcp_bbr 20841 0
|
步骤 ③（可选）：测试网络性能是否增强
为了测试BBR的网络性能是否增强，您可以在Web服务器目录中创建一个文件以供下载，然后从台式机上的Web浏览器测试下载速度。
sudo yum install httpd -y sudo systemctl start httpd.service sudo firewall-cmd --zone=public --permanent --add-service=http sudo firewall-cmd --reload cd /var/www/html sudo dd if=/dev/zero of=500mb.zip bs=1024k count=500 |
最后，http://[your-server-IP]/500mb.zip从桌面计算机上的 Web 浏览器访问 URL ，然后评估下载速度。
当然服务器在国外的话，也可以在 YouTube 上直接打开一个 4K 画质视频，进行感官速度测试，如下图：
? 使用BBR后的YouTube速度 © JANDOU
就这样，尽情享受高速网络带来的新体验。
步骤 ④ （可选）：删除无用的旧内核
升级内核之后，往往老旧的内核也保留下来了，执行以下命令，将自动筛选并删除当前无用的系统内核版本。
yum remove $(rpm -qa | grep kernel | grep -v $(uname -r))
|
详情请参考文章：CentOS 7 删除无用的旧内核
非专业技术人员福利
如果您不是专业技术人员，可以采取一键安装脚本进行安装，执行以下命令：
wget --no-check-certificate https://github.com/teddysun/across/raw/master/bbr.sh && chmod +x bbr.sh && ./bbr.sh
|
详情请参考文章： 一键安装最新内核并开启 BBR 脚本
参考链接：
TCP BBR congestion control comes to GCP – your Internet just got faster
TCP拥塞控制算法 优缺点 适用环境 性能分析
How to Deploy Google BBR on CentOS 7 By Vultr
TCP流量控制和拥塞控制机制
对 Google TCP BBR 的浅薄认识
技术致谢
Neal Cardwell，高级软件工程师；
Yuchung Cheng，高级软件工程师；
C. Stephen Gunn，高级职员可靠性工程师；
Soheil Hassas Yeganeh，高级软件工程师；
Van Jacobson, 研究科学家；
Amin Vahdat, 谷歌研究员。
