TCP 拥塞控制详解 | 7. 超越 TCP（上）-阿里云开发者社区

第 7 章超越 TCP

随着对拥塞控制的探索不断深入，出现了许多新的算法和协议，与我们前几章中所介绍方法的主要不同之处在于，它们大多数都针对特定用例优化，而不是 TCP 所支持的任意复杂度的异构网络环境。QUIC 可能是个例外，其最初目标是提升 HTTP 的性能，但现在已经发展成为一种通用的 TCP 替代方案。

本章将介绍其中某些具体用例，但并没有详尽包含所有可能选项。这些用例包括数据中心 TCP 性能调优；在较长时间段内仅用剩余容量传输背景流量；非 TCP 兼容的基于 HTTP 的 web 流量优化；以 TCP 友好的方式支持实时流；支持多路径传输协议；以及具有独特无线电诱导行为的移动蜂窝网络。

7.1 数据中心(DCTCP, On-Ramp)

有一些针对云数据中心的 TCP 优化工作，其中之一是数据中心 TCP(Data Center TCP) ，数据中心环境的几个特点使我们可以采用不同于传统 TCP 的方法，这些特点包括:

数据中心内流量的往返时间较小；
数据中心交换机中的缓冲区通常也很小；
所有的交换机都在统一的管理控制之下，因此可以要求满足一定的标准；
大量流量具有较低的时延要求；
这些流量与高带宽流竞争；

应该注意的是，DCTCP 不仅仅是 TCP 的一个版本，而是一种改变交换机行为和终端主机对从交换机接收到的拥塞信息的响应的系统设计。

DCTCP 的核心观点是，在数据中心环境中使用丢包作为拥塞的主要信号是不够的。当队列已经积累到足以溢出时，低延迟流量已经无法满足其最低需求，因此会对性能产生负面影响。DCTCP 使用 ECN 的一个版本来提供拥塞的早期信号。但是，ECN 的原始设计将 ECN 标记处理得很像一个丢包，并将拥塞窗口缩短一半，而 DCTCP 采用了一种更精细的方法。DCTCP 试图估算遇到拥塞的字节比例，而不是简单判断拥塞是否发生。然后，根据这个估算缩放拥塞窗口。同时标准 TCP 算法仍然在数据包实际丢失的情况下发挥作用。该方法的设计目的是通过提前对拥塞做出反应来保持队列较短，同时不对空队列做出过度反应，避免牺牲吞吐量。

该方法的关键挑战是估算遇到拥塞的字节比例。对于每个交换机来说计算都很简单，如果一个包到达，并且交换机看到队列长度(K)超过某个阈值，例如,

K>(RTT×C)/7

其中 C 是每秒数据包的链路速率，然后交换机设置 IP 报头中的 CE 位。该算法避免了 RED 的复杂性。

然后，接收器为每个流维护一个布尔变量，我们将其表示为DCTCP.CE，并将其初始值设置为 false。当发送 ACK 报文时，如果DCTCP.CE为 true，接收端会在 TCP 报头中设置 ECE (Echo Congestion Experienced)标志，并且实现了以下状态机来响应每一个收到的数据包:

如果设置了 CE 位，并且DCTCP.CE=False, 设置DCTCP.CE为 True，并立即发送 ACK。
如果没有设置 CE 位，并且DCTCP.CE=True, 设置DCTCP.CE为 False，并立即发送 ACK。
其他清空清空忽略 CE 位。

"其他"情况的非明显后果是，只要收到 CE 值固定的数据包流，接收端就会每 n 个数据包发送一次延迟 ACK，延迟 ACK 已被证明对保持高性能非常重要。

在每个观察窗口(通常选择近似于 RTT 的周期)结束时，发送端计算在该窗口期间遇到拥塞的字节的比例，即标记为 CE 的字节与总传输字节的比率。DCTCP 以与标准算法完全相同的方式增加拥塞窗口，但减小窗口的方式与上次观察窗口期间遇到拥塞的字节数成正比。

具体来说，引入一个名为DCTCP.Alpha的新变量并初始化为 1，在观察窗口的最后更新如下:

$DCTCP.Alpha=DCTCP.Alpha×(1−g)+g×M$M是标记的字节组，g是估算增益，为常数(由实现设置)，决定了DCTCP.Alpha随数据包的标记而变化的速度。当出现持续拥塞时，DCTCP.Alpha接近 1，如果持续通畅(没有阻塞)，DCTCP.Alpha衰减到 0。这样对新拥堵反应较小，对持续拥堵反应较大，拥堵窗口的计算如下:

CongestionWindow=CongestionWindow×(1−DCTCP.Alpha/2)

综上所述，CE 标记表明早期且频繁发生的拥塞，但对这种标记的反应比标准 TCP 更慎重，以避免过度反应导致队列空。

阐述了 DCTCP 的论文，包括推动其设计的数据中心流量特性的研究，获得了 SIGCOMM 的"test of time"奖。

延伸阅读:

M. Alizadeh, et al. Data Center TCP (DCTCP). ACM SIGCOMM, August 2010.

自 DCTCP 以来，已经有相当多关于数据中心 TCP 优化的研究，一般方法是从网络中引入更复杂的信号，发送方可以使用这些信号来管理拥塞。我们通过详细介绍最近的一项成果 On-Ramp 来结束对这一用例的讨论，它侧重于所有拥塞控制算法面临的根本问题: 平衡长期流量与瞬态突发流量。On-Ramp 采用模块化设计，直接解决了这一冲突，而且不需要依赖来自网络的额外反馈。

其主要的观点是，当处于平衡状态的拥塞控制算法遇到严重拥塞并大幅减少窗口(或速率)时，必须决定是否记住之前的均衡状态。这是一个困难的选择，因为这取决于拥堵的持续时间，而拥堵的持续时间很难预测。如果拥塞是暂时的，算法应该记住之前的状态，这样一旦突发流量结束，就可以迅速恢复到原来的均衡状态，避免浪费网络资源。如果由于一个或多个新流的到来造成了持续的拥塞，算法应该忽略之前的状态，以便迅速找到新的均衡。

图 41. On-Ramp 对数据包传输进行配速，以避免由于突发流量导致的网络排队，补充了传统拥塞控制算法保持长期稳定性和公平性的努力。

其思想是将拥塞控制机制分成两部分，每一部分只关注长期/瞬时流量平衡的一个方面。具体来说，On-Ramp 被实现为位于传统 TCP 拥塞控制算法之下的"垫片(shim)"，如图 41 所示。On-Ramp 处理突发流量(临时填充网络队列)，当测量到单向延迟(OWD, One-Way Delay) 增长过大(在 OWD 大于某个阈值)时在发送端临时缓存数据包(而不是占用网络内缓冲区)来试图快速减少排队时延。然后 On-Ramp 与现有拥塞控制算法合作，努力达成长期流量的平衡。On-Ramp 已经被证明可以与包括 DCTCP 在内的几种拥塞控制算法一起工作。

On-Ramp 的关键设计是使两个控制决策在各自的时间尺度上独立运行。但为了正常工作，On-Ramp 需要精确测量 OWD，而 OWD 又依赖发送方和接收方之间的同步时钟。由于数据中心延迟可以小于几十微秒，发送方和接收方的时钟必须同步到几微秒内。这种高精度的时钟同步传统上需要硬件密集型协议，但 On-Ramp 利用了一种新的方法，利用协作节点网格中的网络效应来实现纳秒级的时钟同步，而不需要特殊硬件，这使得 On-Ramp 很容易部署。

延伸阅读:

S. Liu, et al. Breaking the Transience-Equilibrium Nexus: A New Approach to Datacenter Packet Transport. Usenix NSDI ‘21. April 2021.

Y. Geng, et al. Exploiting a Natural Network Effect for Scalable, Fine-grained Clock Synchronization. Usenix NSDI ‘18, April 2018.

7.2 背景传输(LEDBAT)

与低延迟数据中心环境形成鲜明对比的是，许多应用程序需要在很长一段时间内传输大量数据，BitTorrent 和软件更新等文件共享协议就是类似例子。LEDBAT(Low Extra Delay Background Transport)就是为了解决这一用例的问题的。

改进 TCP 拥塞控制算法的各种努力的共同主题之一是与标准 TCP 共存。众所周知，算法可以通过更积极的响应拥塞而"超越"TCP。因此，隐含的假设是新的拥塞控制算法应该与标准 TCP 一起评估，以确保不只是从不那么激进的 TCP 实现中窃取带宽。

LEDBAT 采用了相反的思路，它创建了一个故意不像 TCP 那么咄咄逼人的拥塞控制协议。其思想是利用链路不拥塞时可用的带宽，但在其他标准流到达时，迅速收回流量并将带宽留给其他流。此外，顾名思义，与 TCP 填充瓶颈链路时的典型行为不同，LEDBAT 尽量不触发明显的排队延迟。

与 TCP Vegas 一样，LEDBAT 的目标是在拥塞严重到足以造成丢包之前检测到它的发生。然而，LEDBAT 采用了一种不同的方法来进行，即通过单向延迟测量作为主要输入参数。这是一个相对新颖的方法，在一个具有合理精度但不完全同步的时钟被认为是常态的时代是有意义的。

为了计算单向延迟，发送方在每个传输包中放入时间戳，接收方将其与本地系统时间进行比较，以测量包所经历的延迟，然后将这个计算值发送回发送方。即使时钟不是精确同步的，这种延迟的变化也可以用来推断队列的堆积。假设时钟没有较大的相对"偏差"，即它们的相对偏移量不会变化太快，这在实践中是一个合理的假设。

发送端监测测量到的延迟，并估算固定组件(可能是由于光速和其他固定延迟)是在某一(可配置的)时间间隔内看到的最低值。排除时间最久的估算，从而允许改变路由路径并改变固定延迟。任何超过这个最小值的延迟都被认为是由于排队引起的延迟。

建立"基础"延迟后，发送方从测量延迟中减去该延迟以获得排队延迟，并可以选择性的使用滤波算法来减少估算中的短期噪声。然后将这个估计的排队延迟与目标延迟进行比较，当延迟低于目标时，允许增大拥塞窗口，当延迟高于目标时，减小拥塞窗口，其增大和减小的速度与距离目标的距离成正比，增大速度被限制为不超过标准 TCP 窗口在增长阶段的增长速度。

LEDBAT 在收到 ACK 时设置CongestionWindow的算法总结如下:

CongestionWindow=CongestionWindow+(GAIN×offtarget×bytesnewlyacked×MSS/CongestionWindow)

其中，GAIN取值为 0 到 1 的配置参数，off_target是测量的排队延迟和目标之间的差距，表示为目标的一个分数，bytes_newly_acked是当前 ACK 中确认的数据包字节数。因此，测量延迟相对目标越低，拥塞窗口增长越快，但绝不会超过每个 RTT 一个MSS。减小速度与队列长度超过目标的距离成正比。CongestionWindow在响应丢包、超时和长空闲期时也会有所减少，这与 TCP 非常相似。

因此，LEDBAT 可以很好的利用空闲的可用带宽，同时避免创建长队列，其目标是将时延保持在目标附近(这是一个可配置的数字，建议在 100 毫秒量级)。如果其他流量开始与 LEDBAT 流竞争，LEDBAT 将会后退，从而防止队列变长。

LEDBAT 被 IETF 定义为实验协议，允许相当大程度的实现灵活性，例如根据延迟估算和一系列配置参数，可以在 RFC 中找到更多细节。

延伸阅读:

S. Shalunov, et al. Low Extra Delay Background Transport (LEDBAT). RFC 6817, December 2012.

7.3 HTTP 性能(QUIC)

HTTP 自 20 世纪 90 年代万维网发明以来就一直存在，一开始就运行在 TCP 上。最初版本 HTTP/1.0 由于使用 TCP 的方式存在大量性能问题，例如，每个对象的请求都需要建立新的 TCP 连接，然后在返回应答后关闭。早期提出的 HTTP/1.1 的目的是更好的利用 TCP。TCP 继续被 HTTP 使用了 20 多年。

事实上，TCP 作为一种支持 Web 的协议仍然存在问题，特别是因为可靠、有序的字节流并不完全是 Web 流量的正确模型。特别是，由于大多数网页包含许多对象，因此能够并行请求许多对象是有意义的，但 TCP 只提供单一字节流。如果一个包丢失，TCP 会等待重传这个数据包，然后再继续，然而 HTTP 可以很高兴的接收其他不受单个丢包影响的对象。多 TCP 连接似乎是一个解决方案，但也有其自身缺陷，包括缺乏连接之间拥塞的共享信息。

高延迟无线网络的兴起等其他因素使得单一设备有可能使用多个网络(例如，Wi-Fi 和蜂窝网络)。同时，加密、身份验证等越来越多被使用，也促使人们认识到 HTTP 的传输层将从新方法中受益。为满足这一需求而出现的协议是 QUIC。

QUIC 由谷歌在 2012 年提出，随后被提议为 IETF 标准。它已经得到了大量的部署，出现在大多数 Web 浏览器和流行网站中，甚至开始用于非 HTTP 应用程序。可部署性是协议设计者考虑的关键因素。在 QUIC 中有很多可选部分，其规范跨越了三个 RFC，长达几百页，但在这里主要关注其拥塞控制方法，其中包含了我们在本书中看到的许多观点。

和 TCP 一样，QUIC 在传输中建立拥塞控制，但它认识到没有完美的拥塞控制算法。相反，它假设不同的发送者可能使用不同的算法。QUIC 规范中的基准算法类似于 TCP NewReno，但发送方可以单方面选择不同的算法，如 CUBIC。QUIC 提供了所有的机制来检测丢包，以支持各种拥塞控制算法。

与 TCP 相比，QUIC 的许多设计特性使丢包和拥塞检测更加健壮。例如，无论是第一次发送还是重传，TCP 对一个数据包使用相同的序列号，而 QUIC 序列号(称为包号)是严格递增的。序列号越大表示报文发送的时间越晚，越低表示报文发送的时间越早，这意味着始终有可能区分第一次传输的数据包和由于丢包或超时重传的数据包。

还要注意，TCP 序列号指的是传输字节流中的字节，而 QUIC 序列号指的是整个包。由于 QUIC 序列号空间足够大(高达 2^62 - 1)，可以避免循环问题。

QUIC 协议支持选择性确认，在 TCP SACK 选项中可以支持确认三个以上数据包范围，从而提高了高丢包环境性能，只要成功接收了部分包，就可以向前推进。

与 TCP 快速恢复所依赖的重复 ACK 相比，QUIC 采用了一种更可靠的方法来判断丢包。该方法是独立于 QUIC 开发的，名为 RACK-TLP: 最近确认和尾丢包探针(Recent Acknowledgments and Tail Loss Probes)。其关键观点为，当发送方在丢包之后没有发送足够的数据来触发重复 ACK 时，或者当重传的数据包本身丢失时，重复 ACK 无法触发丢包恢复。相反，如果实际上没有丢包，包的重排序也可能触发快速恢复。QUIC 采用了 RACK-TLP 的思想，通过两个机制来解决这个问题:

收到包的时候，如果一个序列号更高的包已经被确认，并且这个包在"过去足够长的时间"被发送，或者在确认包之前有 K 个包(K 是一个参数)，那么这个包被认为是丢失的。
在等待 ACK 到达的"探测超时时间间隔"之后发送探测包，以触发 ACK，从而提供关于丢失包的信息。

第一个机制是确保少量包被重新排序不会被解释为丢包事件。K 建议初始设置为 3，但如果有更严重的无序情况，可以更新 K。"过去足够长的时间"的定义比测量的 RTT 稍微长一点。

第二个机制是确保即使数据包没有生成重复 ACK，也会发送探测数据包来引出进一步的 ACK，从而暴露接收到的数据包流中的缺口。通过使用估算 RTT 及其方差，将"探测超时间隔"计算为足以解释 ACK 可能遇到的所有延迟。

QUIC 是传输协议领域最有趣的发展。TCP 的许多限制几十年来一直为人所知，但 QUIC 代表了迄今为止最成功的努力之一，它在设计空间中指明了一个不同的点，基于几十年来的宝贵经验，将 TCP 拥塞控制提炼为基准规范。因为 QUIC 的灵感来自于 HTTP 和 Web 的经验(在 TCP 出现很久之后才出现)，提供了关于分层设计和互联网演变中不可预见后果的有趣案例研究。还有更多内容可以介绍，关于 QUIC 的权威参考是 RFC 9000，但是拥塞控制在单独的 RFC 9002 中涉及。