全部标签
写点什么
MySQLOpenHarmony云计算程序员行业资讯算法Python人工智能区块链Linux前端个人成长面试架构师编程企业动态新基建敏捷安全读书笔记高效工作团队管理创业生涯规划知识管理运维产品经理 查看更多

TCP 拥塞控制详解 | 7. 超越 TCP

作者：俞凡
  • 2022 年 7 月 17 日

  • 本文字数：15111 字

    阅读完需：约 50 分钟

网络传输问题本质上是对网络资源的共享和复用问题，因此拥塞控制是网络工程领域的核心问题之一，并且随着互联网和数据中心流量的爆炸式增长，相关算法和机制出现了很多创新，本系列是免费电子书《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)超过某个阈值，例如,



其中 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，在观察窗口的最后更新如下:


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



综上所述，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的算法总结如下:



其中，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(比特/秒)的方程为:



其中:


  • 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 时增加每个子流的拥塞窗口大小。



CongestionWindowTotal 是所有子流拥塞窗口的总和，是子流 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)当设备从一个蜂窝移动到另一个蜂窝时，由给定基站提供服务的设备数量会波动。


图 42. 包括最后一跳无线链路的端到端路径，其中基站缓冲数据包等待通过无线接入网(RAN)传输。


虽然 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。

基础

队列分析
理论基础
评估标准
架构

通用算法

主动队列管理

特定领域算法

数据中心
背景传输
HTTP
无线
实时
多路径

实现与工具

关于本书

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

划线
评论
复制
发布于: 刚刚阅读数: 3

版权声明: 本文为 InfoQ 作者【俞凡】的原创文章。

原文链接:【http://xie.infoq.cn/article/8a253682167064906b7727f82】。

本文遵守【CC-BY 4.0】协议，转载请保留原文出处及本版权声明。

算法网络TCP拥塞控制
用户头像

俞凡

关注

公众号：DeepNoMind 2017.10.18 加入

俞凡，Mavenir Systems研发总监，关注高可用架构、高性能服务、5G、人工智能、区块链、DevOps、Agile等。公众号：DeepNoMind

评论

发布
暂无评论
Copyright © 2022, Geekbang Technology Ltd. All rights reserved. 极客邦控股（北京）有限公司 | 京 ICP 备 16027448 号 - 5京公网安备京公网安备 11010502039052号
TCP拥塞控制详解 | 7. 超越TCP_算法_俞凡_InfoQ写作社区