关于程序员:TCP拥塞控制详解-7-超越TCP

网络传输问题实质上是对网络资源的共享和复用问题，因而拥塞管制是网络工程畛域的外围问题之一，并且随着互联网和数据中心流量的爆炸式增长，相干算法和机制呈现了很多翻新，本系列是收费电子书《TCP Congestion Control: A Systems Approach》的中文版，残缺介绍了拥塞管制的概念、原理、算法和实现形式。原文: TCP Congestion Control: A Systems Approach

第 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) 超过某个阈值，例如,

$$\mathsf{K} > \mathsf{(RTT} \times \mathsf{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，在察看窗口的最初更新如下:

$$\mathsf{DCTCP.Alpha} = \mathsf{DCTCP.Alpha} \times
\mathsf{(1 – g) + g} \times \mathsf{M}$$

M是标记的字节组，g是估算增益，为常数 (由实现设置)，决定了DCTCP.Alpha 随数据包的标记而变动的速度。当呈现继续拥塞时，DCTCP.Alpha靠近 1，如果继续通顺 (没有阻塞)，DCTCP.Alpha 衰减到 0。这样对新拥挤反馈较小，对继续拥挤反馈较大，拥挤窗口的计算如下:

$$\mathsf{CongestionWindow} = \mathsf{CongestionWindow} \times \mathsf{(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 采纳模块化设计，间接解决了这一抵触，而且不须要依赖来自网络的额定反馈。

其次要的观点是，当处于均衡状态的拥塞控制算法遇到重大拥塞并大幅缩小窗口 (或速率) 时，必须决定是否记住之前的平衡状态。这是一个艰难的抉择，因为这取决于拥挤的持续时间，而拥挤的持续时间很难预测。如果拥塞是临时的，算法应该记住之前的状态，这样一旦突发流量完结，就能够迅速复原到原来的平衡状态，避免浪费网络资源。如果因为一个或多个新流的到来造成了继续的拥塞，算法应该疏忽之前的状态，以便迅速找到新的平衡。

其思维是将拥塞管制机制分成两局部，每一部分只关注长期 / 刹时流量均衡的一个方面。具体来说，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 的算法总结如下:

$$\mathsf{CongestionWindow}\ = \mathsf{CongestionWindow + (GAIN \times off\_target \times bytes\_newly\_acked \times 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 中波及。

延长浏览:\
J. Iyengar and I. Swett, Eds. QUIC Loss Detection and Congestion Control. RFC 9002, May 2021.

7.4 TCP 敌对协定(TCP-Friendly Protocols, TFRC)

正如本书提到的，因为 TCP 在检测到拥塞时以各种模式退出，因而很容易构建出性能优于 TCP 的传输协定。任何不通过升高发送速率来响应拥塞的协定，最终都会比它竞争的任何 TCP 或 TCP 类流量取得更大的瓶颈链路份额。在无限资源下，这可能会导致拥塞解体，而在 TCP 拥塞管制刚被开发进去时，拥塞解体开始变得很广泛。因而，业界有强烈的趣味确保互联网上的绝大多数流量在某种意义上是 ”TCP 敌对的 ”。

当咱们应用 ”TCP 敌对 ” 这个术语时，是在说咱们冀望失去与 TCP 相似的拥塞响应。LEDBAT 能够被认为 ” 比 TCP 敌对 ”，因为在第一个提早提醒时就缩小窗口大小，它比 TCP 更踊跃的在拥塞时退后。然而有一类利用对于 TCP 敌对须要更多的思考，因为它们不应用基于窗口的拥塞计划，这就是包含流媒体在内的典型 ” 实时 ” 利用。

如视频流和电话等多媒体利用能够通过扭转编码参数来调整发送速率，在带宽和品质之间进行衡量。然而，不可能忽然大幅升高发送速率而不影响品质，而且它们通常须要在无限的品质级别中进行抉择。如 3.1 节所探讨的，这些思考导致其采纳基于速率的办法，而不是基于窗口的办法。

对于这些利用来说，TCP 敌对的办法是尝试抉择一个与 TCP 在相似条件下实现的发送速率类似的发送速率，但要以一种避免速率稳定太大的形式进行。反对这一想法的是多年来对 TCP 吞吐量建模的钻研。在定义 TFRC 规范的 RFC 5348 中给出了 TCP 吞吐量方程的简化版本，其中一些变量设置为推荐值，指标传输速率 X(比特 / 秒)的方程为:

$$\mathsf{X} = \frac{s}{R\times\sqrt{2p/3} + 12\sqrt{3p/8}\times p
\times (1 + 32 p^2)}$$

其中:

• s是分片大小(不包含 IP 和传输层头域)；
• R为 RTT，单位为秒；
• P是 ” 丢包事件 ” 的数量，体现为占传输数据包的比例。

尽管这个公式的推导自身就很乏味(参见上面的第二个参考)，但这里的要害思维是，如果咱们晓得 RTT 和门路的丢包率，就能很好的晓得 TCP 连贯可能提供多少带宽。因而，TFRC 试图疏导无奈实现基于窗口的拥塞控制算法的应用程序在雷同的条件下达到与 TCP 雷同的吞吐量。

惟一须要解决的问题是 p 和R的度量，而后决定应用程序应该如何响应 X 的变动。与其余协定一样，TFRC 应用工夫戳来比 TCP 最后更精确的度量 RTT。包序列号用于确定接收端丢包，间断丢包被分组为单个丢包事件。从这些信息中能够计算出损包事件概率p，而后由接收端反馈给发送端。

对速率变动的确切响应形式当然取决于应用程序自身，其根本思维是，应用程序能够在一组编码速率中抉择可能适应 TFRC 规定的速率的最高品质。

尽管 TFRC 的概念牢靠，但因为若干起因，其部署很无限。一个起因是以DASH(Dynamic Adaptive Streaming over HTTP) 呈现了针对某些类型的流通信的更简略的解决方案。DASH 只实用于非实时媒体(例如看电影)，但事实证明，这在整个互联网上的媒体流量中占很大比例，事实上在所有互联网流量中占比也很大。

DASH 让 TCP(或者 QUIC)负责拥塞管制，应用程序测量 TCP 正在交付的吞吐量，而后相应调整视频流的品质，以防止接收端饥饿。这种办法曾经被证实适宜于视频娱乐，然而因为依赖于接收端有适度的大量缓冲来平滑 TCP 吞吐量的稳定，并不真正适宜于交互式音视频畛域。DASH 的要害实现之一是能够对不同带宽要求的视频进行多品质级编码，并提前存储在流媒体服务器上。而后，一旦察看到的网络吞吐量降落，服务器就会降落到较低质量的流，而后在条件容许的状况下再回升到较高质量的流。客户端能够向服务器发送信息，比方它还有多少缓冲视频期待播放，以帮忙服务器抉择适合的品质和带宽流。这种办法的老本是服务器上额定的媒体存储，但在古代流媒体视频时代，这种老本曾经变得相当便宜。请留神，这里的 ” 服务器 ” 可能是 CDN(内容散发网络)中的一个节点。因而，视频流能够利用客户端和服务它的 CDN 节点之间可用带宽的任何改良，从而传输更高质量级别的媒体。

TFRC 的另一个限度是，它应用丢包作为次要拥塞信号，但不响应丢包之前的提早。尽管在 TFRC 的钻研中这是最先进的技术，但 TCP 拥塞管制畛域当初曾经把提早思考在内了，比方 TCP Vegas 和 BBR(参见第 5 章)。当咱们思考到真正须要一些别的反对 (不是 DASH) 的多媒体应用程序正是那些对提早敏感的应用程序时，这就特地有问题了。因为这个起因，在撰写本文时，仍在持续为实时流量定义 TCP 敌对的拥塞管制规范。IETF RMCAT (RTP Media Congestion Avoidance Techniques)工作组是这项工作的核心。因而，上面的 TFRC 标准并不是最初的工作，但为如何实现 TCP 敌对协定提供了有用的参考。

延长浏览:\
S. Floyd, M. Handley, J. Padhye, and J. Widmer. TCP Friendly Rate Control (TFRC): Protocol Specification. RFC 5348, September 2008.\
J. Padhye, V. Firoiu, D. Towsley, and J. Kurose. Modeling TCP Throughput: A Simple Model and its Empirical Validation. ACM SIGCOMM, September 1998

7.5 多路径传输

尽管连贯到互联网的晚期主机只有一个网络接口，但当初在一个设施上有至多两个不同网络的接口很常见，最常见的例子是具备蜂窝和 WiFi 接口的移动电话。另一个例子是数据中心，服务器常常会调配多个网络接口，以进步容错能力。许多应用程序一次只应用一个可用的网络，但同时应用多个接口能够进步性能。这种多路径通信的思维曾经存在了几十年，并导致了 IETF 对 TCP 扩大的标准化，以反对利用成对主机之间的多路径的端到端连贯，这被称为MPTCP(Multipath TCP)。

一对主机同时通过两条或多条门路发送流量对拥塞管制来说有重要意义。例如，如果两条门路共享一个瓶颈链接，那么每个门路一个 TCP 连贯的简略实现将取得两倍于规范 TCP 连贯的瓶颈带宽份额，MPTCP 的设计者在放弃多路径益处的同时正着手解决这种潜在的不偏心。MPTCP 提出的拥塞管制办法同样实用于其余传输协定，如 QUIC。多路径传输拥塞管制的高级指标是:

1. 在最佳可用门路上执行成果至多与繁多路径流一样好。
2. 不要从任何门路中获取比繁多路径流更多的资源。
3. 从最拥挤的门路上移除更多流量，与前两个指标统一。

值得注意的是，对其余 TCP 流偏心的想法有一些奥妙之处，咱们在第 3.2 节中探讨过。

尽管多路径算法的细节波及到简单的计算，但所采取的总体办法比较简单。拥塞控制算法在每个子流的根底上大抵模仿 TCP，同时试图确保上述三个指标都失去满足。该算法的外围是应用以下公式在子流上接管到 ACK 时减少每个子流的拥塞窗口大小。

$$\mathsf{MIN} (\frac{\alpha \times \mathsf{BytesAcked} \times \mathsf{MSS_{i}}}{\mathsf{CongestionWindowTotal}}, \frac{\mathsf{BytesAcked} \times \mathsf{MSS_{i}}}{\mathsf{CongestionWindow_{i}}} )$$

CongestionWindowTotal是所有子流拥塞窗口的总和，$\mathsf{CongestionWindow_{i}}$ 是子流 i 的拥塞窗口。MIN 的第二个参数模仿了规范 TCP 将取得的增量，从而确保子流不会比 TCP 更激进 (指标 2)。第一个参数应用变量 α 来确保总体上多路径流取得与应用其最佳可用门路(指标 1) 雷同的吞吐量。RFC 6356 介绍了计算 α 的细节。须要留神的是，因为没有丢包，因而非拥塞门路可能比拥塞门路减少更多的拥塞窗口，随着工夫的推移，更多流量会挪动到非拥塞门路上(指标 3)。

尽管回头看这很简略，但正如 Wischik 和他的共事在 NSDI 的一篇论文中介绍的那样，正是基于许多乏味的剖析才帮忙他们找到了正确的办法。

延长浏览:\
D. Wischik, C. Raiciu, A. Greenhalgh and M. Handley. Design, Implementation and Evaluation of Congestion Control for Multipath TCP. NSDI, April 2011.\
C. Raiciu, M. Handley and D. Wischik. Coupled Congestion Control for Multipath Transport Protocols. RFC 6356, October 2011.

7.6 挪动蜂窝网络

咱们以一个始终受到钻研个人关注的用例作为总结: 拥塞管制和挪动蜂窝网络之间的相互作用。从历史上看，TCP/IP 互联网和挪动蜂窝网络是独立倒退的，自 3G 宽带服务引入以来，后者充当了端到端 TCP 连贯的 ” 最初一英里 ”。随着 5G 的推出，咱们能够预期挪动网络将在提供互联网连贯方面施展越来越重要的作用，其如何影响拥塞管制将会受到越来越多的关注。

尽管挪动无线连接能够被视为与通过互联网的端到端门路上的任何其余跳没有什么不同，但因为历史起因，它被视为一种非凡状况，端到端门路在逻辑上被划分为图 42 所示的两个段: 通过互联网的有线段和通过无线接入网 (RAN) 的无线最初一跳。这种 ” 非凡状况 ” 的观点是有理由的，因为 (1) 因为无线电频谱的稀缺，无线链路通常是瓶颈；(2)因为设施移动性和无线电烦扰的综合成果，RAN 中可用带宽可能是高度可变的；并且 (3) 当设施从一个蜂窝挪动到另一个蜂窝时，由给定基站提供服务的设施数量会稳定。

尽管 RAN 外部很大水平上是关闭和专有的，但钻研人员通过试验察看到，在边缘有显著的缓冲，这可能是为了排汇预期的无线电链路争用，同时在容量关上时保持足够的工作负载。正如 Haiqing Jiang 和他的共事在 2012 年 CellNet 研讨会论文中指出的那样，这种大缓冲区对于 TCP 拥塞管制是有问题的，会导致发送端超出无线电链路上的理论可用带宽，并且在这个过程中，会引入显著的提早和抖动。这是第 6.3 节中确定的缓冲收缩问题的另一个示例。

延长浏览:\
H. Jiang, Z. Liu, Y. Wang, K. Lee and I. Rhee. Understanding Bufferbloat in Cellular Networks ACM SIGCOMM Workshop on Cellular Networks, August 2012.

Jiang 的论文提出了可能的解决方案，并广泛察看到，像 Vegas 这样基于提早的办法比 Reno 或 CUBIC 这样基于丢包的办法体现更好，但近十年来，这个问题在很大水平上始终没有失去解决。随着基于开源软件的 RAN 实现的承诺正在逐渐衰亡，可能很快就能够采取跨层办法，由 RAN 提供接口，使基站外部产生的事件对更高层次的协定栈 (例如，在第 6 章中形容的 AQM 机制) 可见。Xie Yi 和 Jamieson 最近的钻研表明，这种办法可能是无效的，只管他们的实现应用终端设备反馈，而不是让 RAN 直接参与。无论如何实现，其想法是让接管方明确通知发送方在最初一跳上有多少带宽可用，而后发送方必须判断理论瓶颈是在最初一跳还是互联网门路上的其余点上。

延长浏览:\
Y. Xie, F. Yi, and K. Jamieson. PBE-CC: Congestion Control via Endpoint-Centric, Physical-Layer Bandwidth Measurements. SIGCOMM 2020.\
L. Peterson and O. Sunay. 5G Mobile Networks: A Systems Approach. January 2020.\
L. Peterson, C. Cascone, B. O’Connor, T. Vachuska, and B. Davie. Software-Defined Networks: A Systems Approach. November 2021.

蜂窝网络成为 TCP 拥塞管制新挑战的另一个方面是，链路带宽不是恒定的，而是随每个接收端所经验的信噪比的函数而变动。正如 BBR 作者所指出的，这个无线链路的调度器 (目前是不通明的) 能够应用给定客户端的队列数据包数量作为其调度算法的输出，因而构建队列的 ” 益处 ” 能够减少调度器提供的带宽。BBR 试图在其设计中解决这一问题，确保具备足够的侵略性，至多在无线链路缓冲区中缓存一些包。

撇开过来的钻研不谈，一个很乏味的问题是，无线连接将来是否仍将放弃其独特性。如果从挪动网络运营商的角度看，那么指标始终是在大范畴变动的条件下最大限度利用稀缺的无线电频谱，应用深度队列将工作负载放弃在尽可能高的程度是一种通过验证的办法。当宽带连贯是新的服务，语音和文本是次要用例时，这当然是有意义的，但明天的 5G 须要提供良好的 TCP 性能，重点应该放在端到端 goodput 和最大化吞吐量 / 提早比(即在第 3.2 节探讨的功率曲线)。然而有改良的机会吗？

咱们置信这个问题的答案是必定的。除了提供对后面提到的 RAN 调度器和队列的更多可见性之外，还有三个其余因素可能会扭转这个畛域。首先，5G 部署可能会反对网络切片，这是一种隔离不同类别流量的机制，意味着每个切片都有本人的队列，能够依照特定于流量的形式进行调整和调度。其次，小型基站的遍及可能会缩小在给定基站上抢夺带宽的流量数量，这将如何影响调度器最大化频谱利用率还有待察看。第三，通过左近的边缘云而不是互联网为 5G 连贯设施提供服务将变得越来越广泛，这意味着端到端 TCP 连贯将有更短的往返工夫，将使拥塞控制算法对 RAN 中可用容量的变动更敏感。当然，没人能保障将来如何倒退，但所有这些因素都应该为将来调整拥塞控制算法提供短缺的机会。

附录

对于拥塞管制的钻研论文十分宽泛，本书只援用了一小部分。这里收集了更全面的参考书目，(目前)依据书中波及的次要主题组织。

咱们邀请社区帮忙放弃书目标残缺和更新。如果提供额定的援用或修复谬误，请提交 Pull Request 到 GitHub。如果对如何改良书目标组织形式提出倡议，请向 GitHub 公布 Issue。

根底

队列剖析

• L. Kleinrock. Queueing Systems, Volume 2. Wiley & Sons, May 1976.
• V. Paxson and S. Floyd. Wide-Area Traffic: The Failure of Poisson Modeling. IEEE/ACM Transactions on Networking, June 1995.
• W. Leland et al, On the self-similar nature of Ethernet traffic. ACM SIGCOMM‘93 Symposium, August 1993.
• J. Gettys. Bufferbloat: Dark Buffers in the Internet. IEEE Internet Computing, April 2011.

实践根底

• M. Mathis, J. Semke, J. Mahdavi, and T. Ott. The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm. SIGCOMM CCR, 27(3), July 1997.
• F. Kelly. Charging and Rate Control for Elastic Traffic. European Transactions on Telecommunications, 8:33–37, 1997.
• S. Athuraliya and S. Low. An Empirical Validation of a Duality Model of TCP and Active Queue Management Algorithms. Proceedings of the Winter Simulation Conference, 2001.
• R. Jain and K. K. Ramakrishnan. Congestion Avoidance in Computer Networks with a Connectionless Network Layer: Concepts, Goals and Methodology. Computer Networking Symposium, April 1988.

评估规范

• R. Jain, D. Chiu, and W. Hawe. A Quantitative Measure of Fairness and Discrimination for Resource Allocation in Shared Computer Systems. DEC Research Report TR-301, 1984.
• Bob Briscoe. Flow Rate Fairness: Dismantling a Religion. ACM SIGCOMM CCR, April 2007.
• R. Ware, et al. Beyond Jain’s Fairness Index: Setting the Bar for the Deployment of Congestion Control Algorithms. ACM SIGCOMM HotNets. November 2019.

架构

• J. Saltzer, D. Reed, and D. Clark. End-to-End Arguments in System Design. ACM Transactions on Computer Systems, Nov. 1984.
• D. Clark, The Design Philosophy of the DARPA Internet Protocols. ACM SIGCOMM, 1988.
• S. Jain, et al. B4: Experience with a Globally-Deployed Software Defined WAN. ACM SIGCOMM, August 2013.
• J. Perry, et al. Fastpass: A Centralized“Zero-Queue”Datacenter Network. ACM SIGCOMM, August 2014.

通用算法

• V. Jacobson. Congestion Avoidance and Control. ACM SIGCOMM‘88 Symposium, August 1988.
• J. Hoe. Improving the start-up behavior of a congestion control scheme for TCP. ACM SIGCOMM‘96 Symposium. August 1996.
• L. Brakmo, S. O’Malley, and L. Peterson TCP Vegas: New Technique for Congestion Detection and Avoidance. ACM SIGCOMM‘94 Symposium. August 1994. (Reprinted in IEEE/ACM Transactions on Networking, October 1995).
• S. Low, L. Peterson, and L. Wang. Understanding TCP Vegas: A Duality Model. Journal of the ACM, Volume 49, Issue 2, March 2002.
• S. Ha, I. Rhee, and L. Xu. CUBIC: a new TCP-friendly high-speed TCP variant. ACM SIGOPS Operating Systems Review, Volume 42, Issue 5, July 2008.
• N. Cardwell, Y. Cheng, C. S. Gunn, S. Yeganeh, V. Jacobson. BBR: Congestion-based Congestion Control. Communications of the ACM, Volume 60, Issue 2, February 2017.
• B. Briscoe, et al. Implementing the“Prague Requirements”for Low Latency Low Loss Scalable Throughput (L4S). Linux NetDev 0x13 Conference, March 2019.

被动队列治理

• K.K. Ramakrishnan and R. Jain. A Binary Feedback Scheme for Congestion Avoidance in Computer Networks with a Connectionless Network Layer. ACM SIGCOMM, August 1988.
• S. Floyd and V. Jacobson Random Early Detection (RED) Gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking. August 1993.
• R. Braden, et al. Recommendations on Queue Management and Congestion Avoidance in the Internet. RFC 2309, April 1998.
• K. Ramakrishnan, S. Floyd, and D. Black. The Addition of Explicit Congestion Notification (ECN) to IP. RFC 3168, September 2001.
• K. Nichols and V. Jacobson. Controlling Queue Delay. ACM Queue, 10(5), May 2012.

特定畛域算法

数据中心

• M. Alizadeh, et al. Data Center TCP (DCTCP). ACM SIGCOMM, August 2010.
• R. Mittal, et al. TIMELY: RTT-based Congestion Control for the Datacenter. ACM SIGCOMM 2015.
• S. Liu, et al. Breaking the Transience-Equilibrium Nexus: A New Approach to Datacenter Packet Transport. Usenix NSDI‘21. April 2021.

背景传输

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

HTTP

• J. Iyengar and I. Swett, Eds. QUIC Loss Detection and Congestion Control. RFC 9002, May 2021.

无线

• H. Jiang, Z. Liu, Y. Wang, K. Lee and I. Rhee. Understanding Bufferbloat in Cellular Networks. ACM SIGCOMM Workshop on Cellular Networks, August 2012.
• K. Liu and J. Y. B. Lee, On Improving TCP Performance over Mobile Data Networks. IEEE Transactions on Mobile Computing, 2016.
• Y. Xie, F. Yi, and K. Jamieson. PBE-CC: Congestion Control via Endpoint-Centric, Physical-Layer Bandwidth Measurements. SIGCOMM 2020.
• Y. Gao, et al. Understanding On-device Bufferbloat For Cellular Upload. ACM Internet Measurement Conference (IMC), November 2016.

实时

• S. Floyd, M. Handley, J. Padhye, and J. Widmer. TCP Friendly Rate Control (TFRC): Protocol Specification. RFC 5348, September 2008.
• J. Padhye, V. Firoiu, D. Towsley, and J. Kurose. Modeling TCP Throughput: A Simple Model and its Empirical Validation. ACM SIGCOMM, September 1998.

多路径

• D. Wischik, C. Raiciu, A. Greenhalgh and M. Handley. Design, Implementation and Evaluation of Congestion Control for Multipath TCP. NSDI, April 2011.
• C. Raiciu, M. Handley, and D. Wischik. Coupled Congestion Control for Multipath Transport Protocols. RFC 6356, October 2011.

实现与工具

• S.J. Leffler, M.K. McKusick, M.J. Karels, and J.S Quarterman. The Design and Implementation of the 4.3 BSD Unix Operating System. Addison-Wesley. January 1989.
• Netesto.
• NS-3 Network Simulator.
• RFC 6298: Computing TCP’s Retransmission Timer. June 2011.
• The Linux Kernel. BPF Documentation.

对于本书

TCP Congestion Control: A Systems Approach在 GitHub 上依据创作共用协定 (CC BY-NC-ND 4.0) 许可条款提供。邀请社区在雷同的条件下提供更正、改良、更新和新资料。尽管本受权并不主动授予制作衍生作品的权力，但咱们十分心愿与感兴趣的各方探讨衍生作品(如翻译)。请分割 discuss@systemsapproach.org。

如果应用该作品，其包含以下版权信息:

Title: TCP Congestion Control: A Systems Approach\
Authors: Larry Peterson, Lawrence Brakmo, and Bruce Davie\
Source: https://github.com/SystemsApproach/tcpcc\
License: CC BY-NC-ND 4.0

浏览本书

本书是零碎办法系列的一部分，其在线版本公布在 https://tcpcc.systemsapproach.org。

要跟踪进度并接管新版本告诉，能够在 Facebook 和 Twitter 上关注本我的项目。要浏览对于互联网倒退的实时评论，请订阅 Systems Approach Newsletter。

编译本书

要建设可供网页浏览的版本，首先须要下载源码:

$ mkdir ~/systemsapproach
$ cd ~/systemsapproach
$ git clone https://github.com/SystemsApproach/tcpcc.git
$ cd tcpcc

构建过程实现在 Makefile 中，并且须要装置 Python。Makefile 将创立一个虚拟环境(venv-docs)，用于装置文档生成工具集，可能还须要应用零碎的包管理器装置enchant C 库，以便拼写查看器失常工作。

请运行 make html，在_build/html 中生成 HTML。

请运行 make lint 查看格局。

执行 make spelling 查看拼写。如果有拼写正确但字典中没有的单词、名称或首字母缩写词，请增加到 dict.txt 文件中。

请运行 make 查看其余可用的输入格局。

向本书投稿

如果你应用这些资料，心愿也违心给出回馈。如果你是开放源码的老手，能够查看 How to Contribute to Open Source 指南，你将学到如何公布 Issue，如何收回 Pull Request 合并改良，以及其余一些主题。

如果你想投稿，并且正在寻找一些须要关注的内容，请查看 wiki 上的以后待办事项列表。

对于作者

Larry Peterson是普林斯顿大学计算机科学系 Robert E. Kahn 名誉教授，并从 2003 年到 2009 年负责主席。Peterson 传授的钻研次要集中在互联网大规模分布式系统的设计、实现和操作，包含宽泛应用的 PlanetLab 和 MeasurementLab 平台。他目前正在为凋谢网络基金会 (ONF) 的 Aether 接入边缘云我的项目做出奉献，并负责首席科学家。Peterson 是美国国家工程院院士，ACM 和 IEEE 院士，2010 年 IEEE Kobayashi 计算机与通信奖得主，2013 年 ACM SIGCOMM 奖得主。Peterson 领有普渡大学博士学位。

Lawrence Brakmo目前在 Facebook 的 Kernel 小组工作。在退出 Facebook 之前，他是谷歌主机网络组的成员，在此之前，是 DoCoMo 美国实验室操作系统组的研究员和项目经理。Brakmo 致力于 TCP 加强以进步网络性能，包含 TCP Vegas 和 TCP-NV 拥塞控制算法的设计。他还开发了操作系统技术，以进步零碎的可靠性、性能和能耗。Brakmo 在亚利桑那大学取得计算机科学博士学位。

Bruce Davie是计算机科学家，因其在网络畛域的奉献而闻名。他是 VMware 亚太区的前副总裁兼首席技术官，在 VMware 收买 SDN 初创公司 Nicira 期间退出 VMware。在此之前，他是 Cisco Systems 研究员，领导一个架构师团队，负责多协定标签替换(MPLS)。Davie 领有超过 30 年的网络行业教训，并合著了 17 个 RFC。他于 2009 年成为 ACM 研究员，并于 2009 年至 2013 年负责 ACM SIGCOMM 主席。他还在麻省理工学院做了五年的拜访讲师。Davie 是多本书的作者，领有 40 多项美国专利。

你好，我是俞凡，在 Motorola 做过研发，当初在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓重的趣味，平时喜爱浏览、思考，置信继续学习、一生成长，欢送一起交流学习。\
微信公众号：DeepNoMind

本文由 mdnice 多平台公布