首先要意识到的是 TCP 窗口大小和往返时间 (RTT) 限制了吞吐量：每个 RTT 不能传输超过一个窗口大小。

本质上，对于较大的 RTT（延迟），与较小的 RTT 相比，对于相同的吞吐量，您需要更大的窗口。如果不能增加窗口，就不能利用全部带宽。这就是为什么带宽延迟乘积对于网络规划中的吞吐量场景建模很重要。

因此，拥塞控制以另一种方式工作：在缓慢启动时，窗口以中等大小开始，并且 - 假设有足够的带宽 - 会逐渐增加。

在某个时间，在途中的某个地方，达到了端口的容量并且无法立即转发数据包。他们需要排队。他们在途中花费了更多时间，因此 ACK 开始迟到。发送方测量的 RTT 上升。

响应填充缓冲区 -> 增加 RTT，窗口再次减小。发送速度变慢，队列为空，RTT 再次下降。作为回应，允许窗口增长，重新开始循环。

理论上，这听起来（相当）简单。在实践中，您必须微调精确的响应机制。请记住，TCP 过去只能在只有几个 1000 位/秒的慢速串行调制解调器上工作，而今天也可以在数千兆位/秒/秒的线路上运行（几乎）——这很容易达到七个甚至八个数量级！

这就是 BIC 和 CUBIC 发挥作用的地方：传统的拥塞控制，即使是窗口缩放，也有其局限性。基本上，它在一侧的拥塞和另一侧的吞吐量低于潜在带宽之间摆动。

BIC 和 CUBIC 尝试使用二次或三次函数对通道的确切拥塞行为进行建模，而不是在拥塞之前加速，然后减少，以便您可以在拥塞开始之前以最大吞吐量在“最佳位置”运行通道. 模型参数不断调整为反馈参数，使模型随通道变化而变化。