Linux 4.9 BBR
传统 TCP 拥塞控制算法, 基于 “丢包” 进行
但丢包作为拥塞信号的问题是，丢包并不总是拥塞导致，如 GFW 随机丢包策略、链路传输错。这时候发生丢包, 恰恰要做的是立刻重发, 增大发送频率, 而不是降低发送速度
基于不要丢包拥塞控制算法, CDG 以延迟作为判断依据，延迟增大说明拥塞, 数据开始在路由器的缓冲中积累. 降低发送窗口
CDG 算法的问题是, 和基于丢包的算法不兼容, 只有大家全用 CDG, 才是最佳的, 只要有人不用 CDG 而是基于丢包… 那丢包的人就能竞争走所有的带宽. 因为 CDG 是不丢包的
世界不可能一下子就切换所有的设备，也仅仅只能在全部机器都你一家控制的数据中心有点用途了
CDG 进一步改良，Google 开发 BBR 算法, 同 CDG 一样, BBR 算法不以丢包作为拥塞控制信号, 但是和 CDG 算法不同的是, BBR 能和 cubic 和 reno 共存
BBR 能做到这点, 算法却意外的简单
通信领域一个久经考验的公式:
|
|
反过来,
|
|
只要知道了带宽和延迟, 那窗口该多大不就是显而易见了吗?
根本就不用去 “猜” 窗口大小. 而是直接算出来
所有其他的拥塞控制算法, 都是在 “猜” 窗口大小. 拥塞了就缩一下, 没拥塞了就涨.
BBR 算法反其道而行, 不去猜窗口大小, 而是直接算. 延迟是可以测量的, 带宽是可以测量的, 把2个测量值相乘, 就是最佳窗口大小
困难在于, 延迟和带宽属于不相容可观察量, 符合量子力学的测不准原理, 是无法同时测量的
BBR 的做法是, 分开测量
TCP拥塞控制算法 优缺点 适用环境 性能分析