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

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

X=R×2p/3+123p/8×p×(1+32p2)s

其中:

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

MIN(CongestionWindowTotalα×BytesAcked×MSSi,CongestionWindowiBytesAcked×MSSi)

CongestionWindowTotal 是所有子流拥塞窗口的总和，CongestionWindowi是子流 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。

基础

队列分析

• 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. ance 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 多项美国专利。