当前位置：首页 > TCP/IP > 正文

TCP拥塞控制之TCP CUBIC

TCP/IP
2022-11-26
2627
更新：2022-11-26 14:20:41

TCP的拥塞控制算法已经演变了很多了，在linux内核2.6.8中，就默认采用BIC拥塞控制算法了，在2.6.18中，默认的拥塞控制算法采用了CUBIC。这是因为在BIC-TCP提出后不久，North Carolina State University的研究人员在根据BI-TCP的一些缺点后，再次提出了CUBIC的算法，CUBIC不仅仅是简单的对BIC-TCP存在问题的一些修正，它的整个算法都已经做了较大的调整。

##### BIC存在的问题

从[TCP BIP](https://ngdcn.com/post/199.html)的原理来看，BIC在long fast的网络场景下表现的已经很好了，BIC针对具有高延迟的高速网络进行了优化：所谓的“长胖网络”，**为什么又产生了CUBIC呢**？

首先，**BIC能不能用到RTT较小，丢包较高的环境中呢**？从原理上来分析，BIC在离Wmax较远时，窗口增速很快，如果将BIC广泛应用到RTT较小，丢包较高的网络中去，BIC的增窗策略太激进了，大量的抢占了资源，公平性实在是难以保证。

同时，BIC的二分搜索增窗，Max Probing的指数增窗，Smax及Smin的限定，**实现相对复杂**，同时也很难以对性能进行分析，于是，诞生了的CUBIC。CUBIC的名字很有意思，cubic本来就是立方的意思，而又可以理解成cu-bic，也就是cubic-BIC的样式，感觉上就有点GNU取名的味道。从名字上我们知道CUBIC是跟立方有关的，下面我们来详细介绍CUBIC的整体流程。

##### CUBIC

知道了BIC的存在的问题，也就知道了CUBIC的核心思想，CUBIC解决问题的思路很巧妙，既要BIC的高效，又要公平性，要实现BIC的高效只需要窗口调整过程的图像类似BIC即可，任意一个奇数阶的多项式图像均可以拟合BIC的图像，对于公平性而言，**既然reno和BIC都以RTT为单位争抢资源，那么为什么不能把窗口的调整过程从以RTT为单位的思路独立出来呢**？这样就可以通过调整时间的步长来维持公平性。

> CUBIC中最关键的点在于它的窗口增长函数仅仅取决于连续的两次拥塞事件的时间间隔值，从而窗口增长完全独立于网络的时延RTT。之前讲述过小RTT带来的不公平性，而CUBIC的RTT无关的性质使得CUBIC能够在多条共享瓶颈链路的TCP连接之间保持良好的RRT公平性。

CUBIC通过这个公式给出了解决方案：

t为当前时间距上一次窗口减小的时间差，而K就代表该函数从W增长到Wmax的时间周期。其中K的计算公式为：

> t=0时刻，窗口是我们的Wmin，也就是*Wmax，把t=0，W(0)=*Wmax带入，可推导出上述K的计算公式。

该函数的的样式和BIC很像：

当收到ACK后，CUBIC计算利用该算法计算下一个RTT内的窗口增长速度，即计算W(t+RTT)，该值将作为cwnd的目标值，根据cwnd的大小，CUBIC将进入三种不同模式，如果cwnd会小于在标准TCP下经过上次拥塞之后的时刻t窗口将会达到的值(该值是通过标准TCP的窗口增长函数计算出来的)，那么CUBIC就处于标准TCP模式，如果小于Wmax，那么位于凹阶段的，如果大于Wmax，那么处于凸阶段。

鉴于CUBIC比BIC-TCP更出色的表现，在Linux2.6.18版本后，CUBIC取代了BIC-TCP，成为缺省的TCP算法。

当然，CUBIC也有其缺点，比如在凸增长阶段的快速增长可能导致网络流量的突发性，从而造成一定的丢包。

内核代码请参考/net/ipv4/tcp_Cubic.c，详细理论证明和伪代码实现请参考论文[1]。

**参考资料：**
1、CUBIC: A New TCP Friendly HighSpeed TCP Variant

2、https://www.cnblogs.com/fll/archive/2009/11/29/1613201.html

3、https://zhuanlan.zhihu.com/p/366392032

> <span style="font-style: italic;">声明：本文素材来源于网络，仅供学习使用，如有侵权请联系网站删除(ngdcn_admin@163.com)。</span>