3.1 实现选择

我们首先介绍在实现拥塞控制机制时将面临的4个实现选择，以及TCP/IP 的最终选择背后的设计逻辑。一些选择在当时的环境下看起来是“显而易见”的，但为了完整性——以及考虑到互联网持续发展意味着环境也在变化——审视所有选择是明智的。

3.1.1 中心化还是分布式

原则上来说，网络资源分配的第一个设计决策就是：采取集中式还是分布式方法？实际上，互联网的规模以及连接到互联网的不同组织的自治性，必然会导致采用分布式方法。资源的分布式管理也的确是互联网设计的明确目标，如Dave Clark所阐述。但是，理解这个设计决策很重要，原因有二。

更多阅读：D. Clark, The Design Philosophy of the DARPA Internet Protocols. ACM SIGCOMM, 1988.

• 互联网的拥塞控制方法是在其数百万个主机和路由器之间分布式实施的，我们可以合理地将它们视为以协作的方式来实现全局最优解。从这个角度看，存在一个共享的目标函数，所有元素都在执行一个分布式算法来优化该目标函数。本书中描述的各种机制只是定义了不同的目标函数，但是一直存在的挑战是，当多种不同的机制部署之后，如何考虑这些目标函数之间的竞争。

• 虽然对于整个互联网来说，采用中心化方法不太可行，但对于一个有限的范围来说，这种方法可能却更加合适。例如，一个逻辑上的中心化控制器可以收集关于网络链路和交换机状态的信息，计算出全局最优的资源分配方案，然后向终端用户建议（甚至限制）每个用户可用的容量。这种方法肯定受限于中心控制器响应网络变化的时间快慢，但它已经成功应用于 B4 和 SWAN 这一类粗粒度资源分配的流量工程机制中。在粗粒度流量工程决策和细粒度拥塞控制决策之间，并没有明显的界限，但是对可用选项保持开放的态度是有好处的。

更多阅读：S. Jain, et al. B4: Experience with a Globally-Deployed Software Defined WAN. ACM SIGCOMM, August 2013.

中心化控制在数据中心内部已经被有效的应用起来。数据中心是拥塞控制问题的一个有趣的环境。首先，它的 RTT 非常低（指的是对于数据中心内服务器间的流量，而不是进出数据中心的流量）。其次，在许多情况下，可以将数据中心视为一个干净的环境，因为受控所以不用考虑各种现存的拥塞控制算法，从而使得新的拥塞控制算法实施可能性更大。Fastpass 就是这样一种集中式方法的良好例证，它是 MIT 和 Facebook 研究人员合作开发的。

更多阅读：J. Perry, et al. Fastpass: A Centralized “Zero-Queue” Datacenter Network. ACM SIGCOMM, August 2014.

3.1.2 以路由器为中心还是以主机为中心

既然资源分配是分布式的，那下一个问题就是：应该在网络内部（即，在路由器或交换机处）还是在网络边缘（即，在主机中，或许作为传输协议的一部分）实现拥塞控制机制。这并非严格的非此即彼的选择。具体的实现两个地方都有涉及，真正的问题在于主要的决策会落在哪里？路由器总是负责确定哪些数据包用来转发，哪些需要被丢弃。但是，路由器该以何种程度与终端主机就有关数据包转发还是丢弃进行交互，以及终端主机该如何理解路由器决策行为，存在各种选择。

一个极端是以路由器为中心。路由器可以允许主机来向自己预留容量，然后确保每个流的数据包基于该容量相应地被传送。例如，他们可以通过实施一个信号协议以及Fair Queue来做到这一点，只在当有足够容量时才接受新的数据流，同时也管理主机，以确保它们的数据流只使用给它们预留的资源。这对应于一个基于预留的方法，其中的网络可以保证 QoS。但我们认为这个内容超出了本书的讨论范围。

另一个极端是以主机为中心。路由器不提供任何保证，也不提供关于可用容量的明确反馈（当其缓冲区满时会静默丢包），而是由主机负责观察网络状况（例如，他们成功通过网络发送了多少个数据包）并相应地调整其行为。

第三种方法介于这两个方案中间的位置。路由器可以采取更积极的措施来帮助终端主机完成拥塞控制的任务，但这不是通过预留容量和缓冲区空间来实现。当路由器的缓冲区满时，它会向终端主机发送一个反馈。我们将在第6章描述一些这种形式的Active Queue Management（AQM），但是在接下来两章介绍的以主机为中心的拥塞控制机制中，都认为路由器在队列满的时候会默默的tail-drop 数据包。

一般来说，以主机为中心的拥塞控制算法实现在位于传输层的TCP中，或者一些其他模仿TCP的传输层协议，例如DCCP(datagram congestion control protocol) 或 QUIC（一种为基于HTTP的应用设计的相对较新的传输协议）。然而，也可以在应用程序本身中实现拥塞控制。DASH（Dynamic Adaptive Streaming over HTTP）就是一个例子，尽管它通常被认为是传输层（因为它是基于TCP运行的）和应用层的拥塞控制的组合。通过测量的网络性能，视频流服务器可以向客户端发送不同的视频编码，并因此改变HTTP流的速率。实际上，TCP会尝试找到数据流的稳定带宽，然后应用程序调整其发送速率，以完全利用该稳定带宽，同时不发送超过当前网络条件下可承受的数据量。拥塞控制的主要责任属于TCP，但应用程序旨在保持管道充满，同时也维护良好的用户体验。

3.1.3 基于窗口还是基于速率

在确定了以主机为中心的方法后，下一个实现选择是基于窗口 的还是基于速率 。TCP 使用基于窗口机制来实现流控制，因此对于 TCP 拥塞控制的设计决策似乎很明显（即使用相同的方式）。事实上，第四章描述的拥塞控制机制围绕着一种计算 拥塞窗口 的算法展开，在传输过程中，发送方的发送速率将受限于以下两者中较小的一个：接收端宣告的的流控窗口或发送端自己计算出的拥塞控制窗口。

但其实也可以通过计算出网络能承受的速率，然后调整传输速度来实现拥塞控制。真实的传输速率是在某个时间段（如RTT）内传输的字节数。我们在这里同时提出基于速率和窗口的方法，是因为在不同的场景适用不同的方法。例如，基于速率的方法更适合于多媒体应用程序，这类程序以某种平均速率生成数据，并且需要一定量最小的吞吐量才能有效工作。例如，一个视频编解码器可能以平均速率1 Mbps生成视频，峰值速率达到2 Mbps。

通过基于资源预留的方法来实现不同QoS等级的系统中（注，即以路由器为中心的极端方法），采用基于速率的拥塞控制方法是合理的选择。但即便在像互联网这样的尽力而为传输模型中，也可以实现一种自适应的基于速率的拥塞控制机制，该机制会通知应用程序何时需要通过例如调整其编解码器，来调整其传输速率。这就是 TCP-friendly rate control （TFRC） 的核心思想，它将TCP 预防拥塞的概念扩展到那些需要以特定速率发送数据包的应用程序中（例如，以特定质量级别的视频编解码产生的比特率）。TFRC通常与RTP一起使用，RTP是为实时应用设计的传输协议。我们将在第7章看到这类机制的示例。

最后，TCP拥塞控制领域一个最新的进展是BBR（Bottleneck Bandwidth and RTT），它结合了基于窗口的拥塞控制和基于速率的拥塞控制，以限制网络内队列的堆积。我们将在第5章详细介绍这种方法。

3.1.4 基于控制还是基于规避

我们最后关注的实现选择，相对来说有点微妙。这里的挑战在于终端主机，它需要基于反馈和观察来计算当前网络有多少可用容量，并以此调整其发送速率。大体上来说，有两种策略：一种是激进的方法，主机会故意以造成数据包丢失的速率发送数据包，然后真正丢包时作出响应；另一种是保守的方法，主机试图探测路由器队列堆积的开始阶段，并在队列真正溢出到丢包之前放慢速度。我们将第一种机制称为基于控制（control-based），第二种机制称为基于规避（avoidance-based）。

更多阅读：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.

这两种方法的区别最初由Raj Jain和K.K. Ramakrishnan Jain在1988年提出。它们的区别经常被忽视，并且“拥塞控制”一词通常被泛泛地用来指代两者，但我们需要知道它们有着重要的区别。不过，必须承认，如果区别不是很关键的时候，我们还是会用“拥塞控制”一词来泛指两种方式。

同时需要注意的是，我们称之为“基于控制”的和“基于避免”的方法，有时也会分别被称为 基于丢包（loss-based）和 基于延时（delay-based），这是根据它们使用哪种标准来作为调整拥塞窗口的信号。前者在检测到丢包时调整窗口，而后者在检测到延迟变化时调整窗口。从这个角度看，接下来四个章节介绍的每种算法实际上都是以某种方式改进了这些信号的准确性。