1. 前言
前段时间调试网络相关的功能时发现,在一定的丢包率情况下,使用tcp bbr算法比cubic算法有更好的网络传输表现(拉流更顺畅)。
本文仅仅记录一次网络调试经验以及网上查找的一些结论性的内容。对于两种tcp拥塞控制算法的具体实现不做深究,更多的是了解两种算法的表现情况及使用场景。
2. cubic和bbr算法对比
查询相关资料,两种tcp拥塞算法的表现情况如下:
Reno/CUBIC:
它们是事件驱动的!无论是丢包,还是RTT增加,都被视为一种严重的事件,这些严重的事件导致TCP拥塞控制系统在”To find current bandwidth“,”To avoid congestion“以及
”To probe more bandwidth“之间切换,最终落实下来的就是促使拥塞算法(无论Reno,Vegas还是CUBIC)调整窗口的大小。
那么谁来发现这些事件是否发生呢?答案是TCP拥塞控制状态机。拥塞控制状态机直接主导这些状态的切换,只要它发现丢包,不管是不是真的,都会拉低窗口值。
所以说,Reno/CUBIC的窗口调整是被动的。
BBR:
bbr是反馈驱动的!bbr内置了自主的调速机制,不受TCP拥塞控制状态机的控制,bbr算法是自闭的,它可以自己完成VJ的所有状态探测以及切换,无需外界干涉,且对外界的干涉视而不见。
bbr周期性的试图探测是否有更多的带宽,如果有,那么就利用它,如果没有,就退回到之前的状态。
所以说,bbr的窗口调整是主动的。
3. cubic和bbr使用场景
网络在没有丢包的情况下,cubic和BBR对于这些较长时延的链路都有很好的表现。而在中度丢包的情况下,BBR的表现就非常突出了。
- 若仅仅在内网使用,内网环境带宽高,时延低,低丢包率的情况下,建议继续使用 cubic;
- 若对外提供服务,建议使用 BBR,并使相应的网卡使用 tc-fq 调度,否则可能占用额外的 CPU 资源,影响性能;
- BBR的公平性存在问题,它会抢占Cubic算法的带宽(取决于瓶颈缓冲区的大小)
- BBR的机制会导致高重传率
BBR和Cubic两者擅长处理的网络环境并不相同。不过它不采用丢包作为拥塞信号,而是通过自己评估,也许会在其他的环境下取得更好的成绩,比如说和强化学习相结合。