拥塞控制

我偶尔会从开发者和网络人员那里听到关于 TCP 拥塞窗口大小的讨论。我听到关于滑动窗口算法和基于 ACK 的窗口增长（慢启动）的闲聊，以及高 RTT 总是意味着批量下载慢。当然，你总是希望快速下载，但是却遇到了蜗牛般的下载速度，你感觉你的 TCP 参数出了问题，是时候打开 TCP 并对其进行调整了。但这种诱惑是错误的，我可能还会对普通工程师所做的调整感到恐惧。

实际上我发现大多数工程师对 TCP 的实际原理知之甚少。大多数工程师对滑动窗口和 ack-pacing 有所了解，其余的都是误解和混淆。所以，我希望能够减少这种混淆，并讨论真正影响你批量 TCP 下载速率的因素，即 CUBIC。我还会谈到 BBR：一个基于延迟的拥塞检测的 CUBIC 替代方案，以及 QUIC：一种新的网络传输协议。

首先，关于调整的问题，你很可能不需要调整你系统的 TCP 参数。我能想到的只有两种可能需要调整的场景：

除了这两种情况，你应该相信你系统自带的调整是可靠的。这是因为工程师在整个 ARPA/互联网的历史中一直在调整 TCP，而且每个人都认为 TCP 的行为正确性十分重要。

1989 年，当互联网任由政府运行且 TCP 还很年轻时，工程师们正在学习关于不良 TCP 行为和网络的知识。TCP 当时没有拥塞控制，偶尔会导致整个互联网的崩溃。客户端被编码为尊重连接另一端的机器的容量，而不是网络的容量。就像一只对裁判愤怒的篮球队，即使只有一小部分数据包能够通过，客户端也会反复向本地过载的路由器重传。1989 年，在一次特别严重的事故中，NSFNET 的骨干链路在难以置信的拥塞情况下，只有 40bps 的带宽（这是 32kbps 容量的 1/1000）。互联网正在遭受拥塞崩溃！解决拥塞崩溃的方法是将拥塞控制和 Jacobson 和 Karel 的慢启动算法注入到 TCP 中。

之前 TCP 只有一个“发送窗口”，每个客户端会跟踪对端准备从线路上读取的字节数。如果客户端没有准备接收数据，发送方就不会发送。正如 1986 年的崩溃所证明的那样，只有接收窗口是不够的。就像今天一样，TCP 连接不是完全由系统的内存或者处理能力限制的。瓶颈是网络容量。接收窗口处于完全开放状态，但是网络却陷入了崩溃。Jacobson 和他们的朋友引入了拥塞窗口，这规定了现在可以传输多少字节而不会有拥塞的风险。发送状态机会查看接收窗口和拥塞窗口，并只发送两者较小的一个的那么多数据包。

当一个 TCP 创建后，它并不知道它连接的链路有多达，它的吞吐量可能是 1kbps，也可能使 10Gbps。拥塞控制找到链路的容量以避免链路崩溃，并且需要快速找到这个容量（你不会想把所有时间都花费在加速上）。Jacobson 和他的朋友们选择了一个指数增长的系统，每收到一个 ACK 就会触发两个额外的数据包，为了让大家困惑，Jacobson 把这个指数增长称之为慢启动。感谢 Jacobson。

这里为 tweakers 辩护。确实存在这样的情况：调整 initial_cwnd 会影响慢启动达到速度的快慢。在 \(2^{4+n}\) 而不是 \(2^{1+n}\) 启动可以更快地达到更大的 cwnd。然而这并不需要调整。是的，慢启动是基于 RTT 速度的，这会影响高 RTT 的用户。然而，在当前（Linux）默认的 initial_cwnd 为 10 个数据包的情况下，TCP 可以在 14 个周期中增长到 122Mbps 的流量，对于 100ms 的链路这是 1.4s，在大量下载的背景下并不长（至于像 10 GigE 这样的高容量链路，大多数操作系统会自动调整 TCP 参数）。

一个相关的误解是我听到的（这促使了对 initial_cwnd 的调整），即慢启动及其由 ACK 触发的 2^x 增长是 TCP 传输速率的主要驱动因素。完全不是，慢启动只是开场戏，甚至更少。绝大多数时间 TCP 处于拥塞避免状态，由像 CUBIC 这样的算法驾驭。如果你想责备和预期不符的大流量下载，不要诅咒慢启动或者 ACK-pacing，埋怨 CUBIC 吧。（当然也要赞美它，它真的很酷！）。

如上图所示，我们的 TCP 流从 ACK 驱动的指数增长开始，知道它压倒链路并导致丢包（图中的第一个峰值）。然后拥塞控制开始接管流（连接的剩余部分）。拥塞控制指令：在链路容量附近操作流，防止崩溃，并与其它流友好相处。

1988 年，我们拥塞控制的核心是 Jacobson 的新算法：Tahoe，Tahoe 是一个真正的进步，然而我会描述 CUBIC 而不是 Tahoe。CUBIC 是一个现代的、由 Linux 内核默认使用的拥塞控制算法。

当 CUBIC 接管 TCP 流时，它知道 W_max：当 TCP 使链路过载时 cwnd 的值。CUBIC 假设这是链路容量在 W_max 附近。从更大的角度来看，CUBIC 希望利用已知的链路容量，然后偶尔超过这个安全的吞吐量以防止链路容量增加。下面的公式是显示的 cubic 函数。CUBIC 在丢包时回退到 0.8\*W-max，然后在 W_max 出绘制这个立方函数，其拐点（平坦部分），从上图可以看出，前三个峰值是接近拐点中断的 cubic 函数，看起来像鲨鱼鳍。最后，你可以在第四个周期看到容量增加。流通过拐点（W_max）进入 cubic 函数的“最大探测”区域。出现了一个清晰的立方形式。经过几个鲨鱼鳍周期后，这种增长再次重复。

立方体形状是一种优化：在最大吞吐量（大约为 W_max）一下的时间为浪费。CUBIC 迅速增长以达到 W_max。随着它接近，增长逐渐减弱。相比之下，早期的拥塞控制算法 Reno 具有锯齿波动，并且不像 CUBIC 那样迅速达到最大吞吐量。

现在，在上述 cwnd 图的右侧发生了一些奇怪的事情。我在 CUBIC 放置的拐点（三次函数的平坦部分）下方 W_max 处画了一条红色虚线。CUBIC 的实际内容比 Ha 等人的原始论文中提到的更多。为了解决收敛问题（多个流达到网络资源公平分配的时间）。当看起来吞吐量下降时（W_max_prev > W_max），Linux 将拐点放置在 0.9*W_max。在稳态下，这给 Linux CUBIC 带来了一个周期（在 W_max 和 0.9*W_Max 交替）。

下面可以看到 Linux CUBIC 与 Ha 的原始 CUBIC。Ha 的波形是纯粹的鲨鱼鳍。我们预料到这一点；链路容量只会下降，因此 CUBIC 函数从未有机会通过拐点进入探测阶段。Linux CUBIC’s 的修改将拐点每两个周期放置在 0.9*W_max ，因此即使链路容量没有增加，也会出现 CUBIC 形式。你可以想象这会导致大流量在短时间内人为地处于较低水平，从而允许较小的流获取带宽。你还可以看到在 0.9*W_max 个周期中，流从最大探测区域接近 W_max ，因此可能比如果它是通过 CUBIC 函数的线性中心区域增长时更积极地获取可用带宽。

TCP CUBIC 包含了 2008 年原始 CUBIC 论文的另一个改进。现在 TCP 通常使用 HyStart（Hybird Slow Start）。慢启动往往会严重超过链路容量，造成不必要的拥塞。HyStart 跟踪数据包的时间，寻找拥塞的第一丝迹象，并设置一个水平 sshthresh。此时慢启动有可能严重压垮链路，当超过 sshthresh 时，流切换到拥塞控制（对我们来讲就是 CUBIC）。

关于 RTT 的重要说明：CUBIC 的流量控制独立于 RTT。我听到工程师抱怨 TCP 传输的 RTT 问题，但实际上 CUBIC 是由时间而不是 ACK/RTT 来调节的。仅根据时间调整 cwnd 可以在各种 RTT 下提供更好的性能。