TCP 拥塞控制详解 | 1. 概述

网络传输问题本质上是对网络资源的共享和复用问题，因此拥塞控制是网络工程领域的核心问题之一，并且随着互联网和数据中心流量的爆炸式增长，相关算法和机制出现了很多创新，本系列是免费电子书《TCP Congestion Control: A Systems Approach》的中文版，完整介绍了拥塞控制的概念、原理、算法和实现方式。原文: TCP Congestion Control: A Systems Approach

序

拥塞控制无疑是计算机网络中最重要、最基础的课题之一，也是最具挑战性的问题之一。计算机网络需要控制可能分布在全球不同组织中的端点，并支持不同的应用程序，因此网络层在支持传输层拥塞控制方面的作用也具有多方面、微妙的挑战。几乎每一个所想到的互联网场景都需要拥塞控制，从跨越全球、承载所有类型流量的公共互联网，到承载大量文件传输数据的长"胖"管道，到专门的数据中心网络，到私人商业骨干网，再到移动和无线网络。

当我们面对所有这些挑战时，如何理解已经开发出来的众多(真的很多!)拥塞控制方法？这些方法解决的根本挑战是什么？网络层的作用是什么？更广泛的说，拥塞控制协议的设计空间是什么？对于拥塞控制，是否存在可识别的通用类别或方法？在实践中采用了哪些方法，为什么？在你可能听说过的 TCP 的许多选项/变体中，各有什么不同，适合什么场景，为什么？这么多问题！

要弄清楚这一点并回答所有这些问题(或更多问题)，不仅需要一本书，而且需要一本伟大的书！幸运的是，现在就有这样一本书，就是本书！《TCP 拥塞控制详解》(TCP Congestion Control: A Systems Approach) 的三位作者是世界上最博学的拥塞控制研究者之一，Brakmo 和 Peterson 的 TCP Vegas 协议(可以在 5.1 节了解更多)首创了端点可以预测以及避免拥塞的概念，而不只是对观察到的拥塞做出反应。TCP Vegas 已经成为新设计的拥塞避免协议(如谷歌支持的 BBR 协议，见 5.3 节)的基础。本书作者都是非常出色的作家(我自己也是教科书作者)，文字清晰、简洁、引人入胜，能够组织和交流复杂的想法，并有适量的细节和实践讨论。Larry Peterson 和 Bruce Davie 所倡导的"系统方法(systems approach)"也正是真正理解拥塞控制这一网络架构中的深层次、系统级问题(例如，网络和传输层功能的分离和交互，在应用层或网络中实现网络服务的问题，例如拥塞控制)所需要的。

这本书是 Larry、Bruce 以及其他人正在开发的一套非常棒的开源"系统方法"书籍的必要和最受欢迎的补充。希望你能从头到尾读一遍，以后有需要的时候再来查阅，并像我一样喜欢它。

Jim Kurose

Amherst, Massachusetts

前言

从早期分组交换开始，拥塞控制就一直是计算机网络中最活跃的研究领域之一。20 世纪 80 年代，Jacobson 和 Karels 通过在 TCP 中引入拥塞控制机制，为随后几十年的工作奠定了基础，这一工作始于互联网显示出拥堵崩溃迹象的危机时刻。以太网发明人 Bob Metcalf 曾预言互联网将在 20 世纪 90 年代崩溃，幸运的是他说错了。但很明显，虽然自那以后互联网平稳运行所依赖的算法得到了成倍改进，但即使到现在，拥塞控制问题还没有完全解决。

本书是我们在过去 30 年里参与开发拥塞控制算法的结果。在过去一段时间里，拥塞控制方面有了如此多的发展，几乎不可能把它们完全囊括进来。我们在本书中试图提供一个框架将拥塞控制作为一个系统问题来理解，并通过几个主题来解释多种方法。例如，我们在 TCP Vegas 上的工作开辟了一条一直持续到今天的研究路线，其目的是避免严重拥塞，而不是在拥塞发生后做出反应，因此我们认为基于回避的方法是拥塞控制的主要类别之一。

我们希望本书可以不断更新。还有很多拥塞控制方面的工作目前还没有定论，涉及到的算法还在继续改进，可能会出现新的方法来解决新的用例。我们将根据需要更新本书，以反映该领域的状态，欢迎提交意见和反馈。

最后，我们要感谢那些为改进本开源书做出贡献的人们，包括:

• Bill Fisher

• Giulio Micheloni

• J van Bemmel

• Omer Shapira

• Nico Vibert

• Vik Vanderlinden

请使用问题链接向我们发送意见和反馈，查看Wiki获取最新待办事项列表。

Larry Peterson, Lawrence Brakmo, Bruce Davie

2022 年 5 月

第 1 章 概述

互联网被认为是工程领域无与伦比的成功，这理所当然，网络连接了数十亿设备，支持了每一个想象中的通信应用，并适应从每天几十位到每秒数百千兆的传输速率。但其核心仍然存在棘手的技术挑战，在过去 30 多年里引起了(无论是试图让互联网表现得更好的从业者，还是想了解其数学基础的理论家)广泛的关注: 如何最好的将网络资源分配给试图使用它的所有竞争者。

在任何计算机系统中，资源分配都是一个难题，对于像互联网这样复杂系统来说更是如此。当 20 世纪 80 年代初首次在互联网部署 TCP/IP 协议栈时，这个问题并不是人们最关心的问题。然而十年之后，随着互联网在大学里的广泛使用(比万维网的发明早了几年)，网络开始经历一种被称为"拥塞崩溃(congestion collapse)"的现象。20 世纪 80 年代末，拥塞控制作为解决方案被开发和部署，解决了眼前的危机。从那时起，互联网社区一直在研究和改进拥塞控制方法，本书将引导你浏览这段旅程。

早期最著名的拥塞管理工作是由两位研究人员 Van Jacobson 和 Mike Karels 进行的，他们发表于 1988 年的论文 Congestion Avoidance and Control 一直以来都是是网络领域被引用最多的论文之一。这有充分的理由。一是拥塞崩溃确实威胁到了新生的互联网，而解决这个问题的工作是互联网最终成功的基础。如果没有这些工作，就不可能有今天的全球互联网。

另一个原因是，拥塞控制在过去 30 多年里一直是富有成果的研究领域。流量拥塞控制，以及更广泛的资源配置，都是具有很大创新空间的开放设计空间。几十年的研究和实施建立在早期基础上，似乎可以合理假设，只要互联网存在，新方法或对现有方法的改进就会持续出现。

本书将探索互联网拥塞控制的设计空间，并介绍过去三十年来发展起来的管理或避免拥塞的主要方法。

延伸阅读:

V. Jacobson. Congestion Avoidance and Control. ACM SIGCOMM ‘88 Symposium, August 1988.

1.1 什么是拥塞?

任何高峰时间在高速公路上开车的人都经历过拥堵，其主要特点是有限的资源(高速公路上的空间)，以及一系列争夺这一资源的汽车、卡车等。随着高峰时间的到来，更多车辆到达，但道路照常运行，只是有更多车辆行驶在上面。但是，当车辆数量变得越来越多，每个人都不得不减速(因为在限速下，没有足够的空间让每个人保持安全距离)，在这个时候，道路对车辆移动的效率实际上变得更低。因此，就在需要更大容量的时候，实际用于移动流量的容量却更少了，如图 1 所示。这就是拥塞崩溃的本质，当拥塞非常糟糕时，系统性能明显比没有拥塞时更差。分组网络的拥塞崩溃机制与高速公路有很大的不同，但存在同样的问题^[1]。

图 1. 随着负载增加，吞吐量会上升，然后在拥塞崩溃点下降。

[1] 网络从业人员喜欢将网络拥塞类比为现实世界的拥塞，但重要的是要认识到这种类比并不完美。

本书重点是包交换网络的拥塞控制。分组交换的基础是多路复用(multiplexing) ，这是一种在多个用户或应用程序之间共享系统资源(如路由器中的链路或队列)的方法。在互联网环境下，数据包网络在统计上是多路复用的(statistically multiplexed) ，这意味着当数据包在某种程度上随机到达时，我们依赖到达的统计属性确保不会耗尽资源。但是拥塞崩溃的存在表明，有时统计数据并不如我们所愿。

要了解这是如何工作的，请考虑图 2 所示的简单网络，其中网络左侧的 3 台主机(发送者 S1-S3)通过共享一个只包含一条物理链路的交换网络向右侧的 3 台主机(接收者 R1-R3)发送数据。(简单起见，假设主机 S1 向主机 R1 发送数据，依此类推。) 在这种情况下，三组数据流(对应于三对主机)通过交换机 1 被复用到一条物理链路上，然后通过交换机 2 被解复用(demultiplexed ) 为单独的数据流。请注意，我们现在有意对"数据流"到底对应什么含糊其词，但将在后面的章节中更精确说明这一点。

图 2. 在一个物理链路上复用多个逻辑流。

统计多路复用意味着网络中所有主机只要可以就发送数据包，如果在一个交换机上同时出现几个数据包，其中一个将先被传输，而其他则被放入队列。所以链接和队列都是共享资源，而且都是有限的。链路每秒只能携带一定数量的比特，队列在开始丢弃数据包之前也只能容纳一定数量的数据包(或字节)。拥塞控制的本质就是管理这些共享资源的访问，并尝试防止拥塞崩溃。交换机正常工作时，偶尔将数据包放入队列，当交换机队列中有大量的包时，就会发生拥塞。稍后我们将讨论网络拥塞崩溃的定义，但首先要知道这是从拥塞的交换机、路由器或链路开始的。

为了更深入介绍统计多路复用，以及为什么是包网络的首选方法，请参考下面的文章。

延伸阅读:

Requirements. Computer Networks: A Systems Approach, 2020.

当交换机队列里有等待传输的包时，需要决定接下来发送哪个包，包交换网络中的交换机是逐个包独立做出决定的。这么做的问题之一是如何公平的做出决定。例如，许多交换机被设计成基于先进先出(FIFO)原则对数据包进行服务，或者以 round-robin 的方式循环传输每个流的包。这样做可能是为了确保某些流获得链路带宽的特定份额，或者确保在交换机中的延迟永远不会超过一定时间。试图为特定流分配带宽的网络有时被称为支持服务质量(QoS, Quality-of-Service) 。

从上面讨论可知，包交换网络的本质就是有时会拥塞。本书重点是介绍缓解拥塞方面所做的大量工作，无论是通过有效的应对方式来减轻拥堵，还是在拥堵发生之前预防拥堵。

1.2 控制拥塞

资源分配和拥塞控制是一个复杂的问题，自网络设计之初就一直是人们研究的课题，如今仍然是活跃的研究领域。使这些问题变得复杂的一个因素是，它们没有被隔离到协议层次结构的单个层级。资源分配部分在网络内的路由器、交换机、链路上实现，部分在终端主机上运行的传输协议中实现。终端系统可以使用信令协议向网络节点传递资源需求，网络节点用有关资源可用性的信息进行响应。应用协议本身可以被设计为减轻拥塞的，例如，通过根据当前的网络条件改变视频传输的分辨率。这是一个系统问题的典型例子，如果不关注所涉及的系统中的所有方面，就无法完全理解拥塞。

在进一步讨论之前，应该先澄清术语。通过资源分配(resource allocation) ，指的是网络组件试图满足应用程序对网络资源的竞争需求的过程，主要是路由器或交换机中的链路带宽和缓冲区空间。当然，通常不可能满足所有需求，这意味着某些用户或应用程序可能获得比想要的更少的网络资源。资源分配问题的一部分是决定何时对谁说不。

我们使用术语拥塞控制(congestion control) 来描述网络节点(包括终端系统)为防止或响应过载情况所做的努力。由于网络拥堵通常对每个人都不好，所以首先要做的就是让拥堵消失，或者从一开始就阻止拥堵的发生。可能只需要说服某些主机停止发送，就可以改善其他所有人的处境。然而，更常见的拥塞控制机制具有一定的公平性，即试图让所有用户分担痛苦，而不是让少数用户承受巨大的痛苦。 因此，我们看到许多拥塞控制机制都内置了某种类型的资源分配。

理解流量控制和拥塞控制之间的区别也很重要，流量控制包括保持快速的发送端不超过慢速的接收端。相比之下，拥塞控制的目的是防止一组发送者因为在某些时候缺乏资源而向网络发送过多的数据。这两个概念经常被混淆，正如我们将看到的，它们共享了某些机制。

考虑到所有可以实现拥塞控制和资源分配的不同地方和层级，从简单的方法开始很有帮助，这基本上就是 Jacobson 和 Karels 所做的(尽管他们的解决方案最终有相当多变动的部分)。

在早期互联网中，路由器实现了最基本的资源分配方法: 尾丢弃的 FIFO 队列(FIFO queuing with tail drop)。没有对流或应用程序的感知，只是在包到达时接受，当出站链路容量小于到达率时将包放入队列，基于 FIFO 规则为队列提供服务，并在队列满时丢弃到达的包("尾丢弃(tail-drop)")。这仍然是今天最常见的队列形式，我们将在后面的章节中讨论包括主动队列管理(Active Queue Management) 在内的其他排队方法。

早期互联网发生拥塞崩溃的原因是，被丢弃的数据包不仅仅是被丢弃和遗忘。当端到端传输协议是 TCP 时，就像大多数互联网通信一样，被丢弃的包将被重传。因此，随着拥塞增加，重传数据包的数量也会增加，换句话说，即使用户和应用程序负载没有实际增加，发送到网络的包的数量也会增加。更多的数据包导致更多的传输，进一步导致更多的重传，等等，可以看到这是如何导致崩溃的。

在此上下文中，一个有用的术语是*(有效吞吐)goodput*，它与吞吐量的区别在于，只有做有效工作的包才被计入 goodput。因此，如果一个链路以 100%的利用率运行，但该链路上的 60%的数据包由于早期丢包而被重传，可以说，goodput 只有 40%。

早期研究人员对拥塞控制的关键见解是，在拥塞期间，TCP 有可能也有必要做一些事情，而不是盲目重传丢失的数据包。TCP 必须检测拥塞(例如，可以通过关注丢包做到这一点)，然后通过减少发送的网络流量来响应拥塞。在拥塞期间，端到端协议和网络之间的这种相互作用形成了今天许多拥塞控制和避免方法的基础，我们将在后续章节中详细介绍这些方法的工作原理。

1.3 理论基础

人们已经做了很多重要的理论工作来理解拥堵。网络拥塞的核心是排队，排队背后有大量的理论，其中许多理论延伸到其他物理领域，如超市收银台和道路拥堵。关于包网络排队的标准参考是由阿帕网的早期先驱之一 Leonard Kleinrock 编写的。

延伸阅读:

L. Kleinrock. Queueing Systems, Volume 2.

随着包网络在 20 世纪 80 年代变得更加广泛，人们对流量的行为产生了极大的兴趣，人们越来越意识到它可能比最初认为的更复杂。最受欢迎的数据流量模型之一是泊松模型(Poisson model)，它适用于各种系统，如电话网络中的呼叫到达和人们在超市排队。但是，人们对互联网和其他分组网络研究得越多，泊松模型就变得越糟糕。有许多开创性的论文为更复杂的模型提供了理论基础，以下是其中两篇。

延伸阅读:

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.

这些论文和其他一些论文促成了这样一种共识，即互联网流量比早期模型所假设的更具有"突发性"，即数据包成群到达。此外，这种突发性显示了自相似性(self-similarity, 分形的一种特性)，当你放大时，会在更细的分辨率上看到类似的复杂性。对于互联网流量来说，这意味着在任何时间尺度上，从微秒到小时，都将看到类似的模式。

这项研究产生了许多实际成果，例如认识到包队列可能会变得非常长，因此路由器和交换机应该有相当大的包缓冲区。(正确调整缓冲区大小也是其研究课题。) 因为必须为不可预测的突发留出空间，因此链接利用率不可能一直可靠维持在接近 100%的水平。

在考虑避免拥塞时，公平(fairness) 和稳定(stability) 是两个特别重要的主题。当网络拥塞时，一些用户或流需要减少发送量。显然有必要问: 哪些流应该减少发送的数据？所有流都应该平等分担吗？如果一些流比其他流更关注拥堵信号，会发生什么？这些问题是公平问题的核心。Jain 的公平指数(fairness index) 是被广泛接受的衡量网络公平程度的方法之一。我们将在第三章深入探讨这个问题。

稳定性是任何控制系统的关键属性，也是拥塞控制的追求。当检测到拥塞时，就会采取一些措施来减少总流量，从而缓解拥塞。一旦拥塞缓解，似乎再开始发送更多流量也很合理，但这样会导致发生更多拥塞。可以想象，这种在拥塞状态和非拥塞状态之间的振荡会永远持续下去，网络要么无法被充分利，要么处于崩溃状态，这将会非常有害。我们希望能找到一个平衡点，在这个平衡点上网络很繁忙，但不会太忙以至于发生拥塞崩溃。过去几十年里，寻找稳定的控制回路一直是拥塞控制系统设计者面临的关键挑战之一。对稳定性的追求在 Jacobson 和 Karels 的早期工作中的重要指标，并且仍然是今后的各种方法必须满足的要求。

一旦初始的 TCP 拥塞控制算法得到实现和部署，研究人员就开始建立 TCP 行为的数学模型，这样可以建立丢包率、往返时间和吞吐量之间的关系。Mathis 及其同事奠定了相关基础，但随着拥塞控制算法的发展，还有大量工作正在进行。TCP 在给定稳定的 RTT 和丢包率下会收敛到一定的吞吐量，这也是 TCP 友好速率控制(TCP friendly rate control, TFRC) 的基础。TFRC 将类似 TCP 的拥塞控制扩展到不使用 TCP 的应用程序，基于这样的想法，仍然可以以公平的方式与使用 TCP 的应用程序共享可用容量。我们将在第 7 章回到这个话题。

延伸阅读:

M. Mathis, J. Semke, J. Mahdavi, and T. Ott. The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm. SIGCOMM CCR, 27(3), July 1997.

最后，关于拥塞控制的许多理论工作将该问题定义为"在竞争源之间共享网络资源的分布式算法，目标是选择源速率，以便在限定容量下最大化总资源效用"。制定拥塞控制机制作为优化目标函数的算法可以追溯到 Frank Kelly 在 1997 年的一篇论文，后来被 Sanjeewa Athuraliya 和 Steven Low 扩展，将流量源(TCP)和路由器排队技术(AQM)考虑在内。

延伸阅读:

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.

本书不涉及这些论文中的数学公式(以及随后的大量工作)，但我们发现，认识到在优化效用函数以及本书中描述的机制的实用方面之间存在既定的联系是有帮助的。拥塞控制是网络理论和实践有效联系在一起的一个领域，以探索解决问题的空间，并开发出健壮的方法来解决问题。

1.4 今天的拥塞控制

有时感觉网络协议已经被固定下来并标准化了几十年，但很少有领域像拥塞控制那样持续保持发展。虽然 Jacobson、Karels 和其他人的早期工作奠定了基础，但一系列创新一直延续到今天。后面的章节中将详细讨论这些问题，但可以放心，在未来几年，拥塞控制方面的新想法还将继续出现。

有时，环境的变化需要创新。例如，随着带宽从每秒兆比特增加到每秒千兆比特，任何时刻传输的数据量都在增加，这就增加了快速检测和响应拥塞的风险。高延迟链路，如跨洋电缆和卫星链路，通过提高往返时间(RTT)使问题更加严重。这些情况导致了使用延迟(以及延迟的变体)作为拥塞信号的创新(首次见于 TCP Vegas)。 此外，有了这些"更肥的管道"，玩家就有更大的动力快速填满管道，如果数据可以在 1-2 个 RTT 内发送，没人想花 10 个 RTT 去探测可以多快发送数据。这促使我们努力更快确定瓶颈带宽，这方面的技术包括 XCP、RCP 和 TCP 的 Quick-start。

在 TCP 的早期时代之后，无线网络成为主流，这导致了新的问题: 丢包不再是可靠的拥塞信号，而可以归因于无线电信道的噪声。这导致了要么对 TCP 主机隐藏丢包，要么改进 TCP 检测拥塞的机制等一系列方法。

云数据中心成为拥塞控制机制的另一个"用例"。与端到端延迟动态变化的普通互联网不同，数据中心中的 RTT 是可预测的，并且相对较小(<10ms)。由于网络结构是高度规则的(例如叶脊结构)，所以很容易理解在什么地方和什么情况下可能发生拥塞。这使得运行在数据中心的 TCP 适合使用目的优化算法，而不必使用运行在全球互联网上的通用机制。

新的应用程序也有助于改善拥塞控制，突出例子是视频流媒体的崛起，目前成为了互联网上主要的流量来源。同样，有很多方法可以让视频在拥塞的情况下更好的工作。其中一个取得了巨大成功的是基于 HTTP 的动态自适应流(DASH, Dynamic Adaptive Streaming over HTTP) ，在这种情况下，发送视频的服务器从一种编码质量切换到另一种编码质量(因此从一个比特率切换到另一个比特率)，以响应接收端路径上测量到的拥塞。这将拥塞控制回路向上移动到应用层，或者更确切的说，在 TCP 已经提供的控制回路之上增加了第二个控制回路。

本文对创新的简单介绍并不全面，接下来的章节中将看到更多关于这些方法和其他方法的细节，重要的是要理解拥塞控制会随着技术前景和应用需求的变化而不断发展。

1.5 参考实现

我们在 1.3 节中看到，有大量的文献研究了拥塞控制算法的数学特性，但拥塞控制仍然是一个高度实用的问题。据估计，TCP 连接承载了互联网上 85%的流量，这些连接被锚定在 TCP 的软件实现中，运行在每一个可以想象的操作系统中(例如，Linux, Windows, MacOS, iOS, Android)。作为一个实际问题，我们在本书中讨论的拥塞控制机制的具体实现是在内核级代码中表示的，通常是用 C 实现的。理论定义了代码的抽象模型，但代码实现了算法。

如果实现是现实规范，那么哪个实现是权威的，哪个可以作为参考实现(reference implementation) 呢？答案就是当今主流开源实现。最初是 Unix 的 BSD(Berkeley Software Distribution)实现，事实上，Jacobson 和 Karels 提出的初始算法是 1988 年 Tahoe 发布的 BSD 4.3 的特性。BSD Unix 和 TCP 拥塞控制算法之间的联系是如此之强，以至于算法的变体根据 BSD 版本而被熟知(命名): 例如，TCP Tahoe，以及后来的 TCP Reno。

延伸阅读:

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.

Berkeley Unix

任何互联网相关专业的学生都应该对 Berkeley Unix(又名 BSD)在互联网的成功中所扮演的角色心存感激。当然，Unix 起源于 20 世纪 70 年代早期的 AT&T 贝尔实验室，但 DARPA 投资支持 Unix 的开源实现(包括刚刚起步的 TCP/IP 协议栈)被证明是具有变革意义的。

当时，互联网能否成功还不确定。许多人认为这只是一种科研项目，在当时并没有获得计算机和电信行业太多支持。很大程度上是因为大学(和他们的学生)可以访问互联网协议栈的开放实现，以及运行它的廉价硬件，TCP/IP 才得以扎根。通过开放源码软件和现成的硬件传播变革性技术已经被证明是强大的策略，BSD 就是早期的成功例子。

BSD 及其后代一直延续到今天(尤其是 FreeBSD)，但最终在 21 世纪初被 Linux 取代，成为事实上的开源、基于 Unix 的操作系统。本书介绍的所有 TCP 拥塞控制变体都可以在 Linux 内核中找到(并且可以选择性激活)，它们已经成为这些算法的参考实现，这将我们带到了最后一点: 评估 TCP 拥塞控制机制的标准是经验的，通过基于 Linux 的 TCP 发送方和接收方实现之间运行真实的流量。问题是: 什么流量，在什么网络上？

虽然通过观察运行在实际互联网上的 TCP 连接的行为通常可以获得有用的见解，但"互联网"广泛的可变性(在时间和空间上)使得控制实验几乎不可能。相反，当前的最佳实践是在隔离但具有"代表性的网络拓扑"上运行"代表性流"的集合。对于流集合或网络拓扑集合，都没有既定的黄金标准，因此实验结果永远不会是决定性的。不过，这么多年来使用这种方法收集的大量证据已经证明这足以推动最先进的技术。

为了本书的目的，我们使用第 3 章中介绍的实验方法，从而可视化各种算法的行为(帮助建立直觉)，并强调有问题的场景，这些场景使拥塞控制成为一个具有挑战性和有趣的技术问题。

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。

微信公众号：DeepNoMind