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前后收集吞吐量对比图：
BBR 由 Google 斥地，供 Linux 内核的 TCP 和谈栈使用，有了 BBR 算法，Linux 办事器能够显著提高吞吐量并削减保持延迟，简洁来说 BBR 能加快收集传输速度。此外，布置 BBR 也很轻易，因为该算法只需要发送方，而不需要收集或领受方的支撑。
CentOS 7 办事器实例上布置 BBR
1、首先，升级办事器内核版本到4.9以上，不在累述
2、启用BBR
需要点窜sysctl设置，以启用BBR算法
首先运行lsmod |grep bbr 查察是没有BBR的# modprobe tcp_bbr
# echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
# echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
# sysctl -p
若是内核不支撑运行modprobe号令时会失足：modprobe: FATAL: Module tcp_bbr not found.
查察下是否启用了BBR# sysctl net.ipv4.tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = reno cubic bbr hybla
# sysctl -n net.ipv4.tcp_congestion_control
bbr
# lsmod |grep bbr
tcp_bbr 20480 6
参考：https://github.com/google/bbr
