互联网拥塞控制终极指南 : 上[翻译]

原文:https://www.compiralabs.com/ultimate-guide-congestion-control

1.简介

拥塞控制是一个复杂的话题，围绕它进行了数十年的学术研究。事实上，直到今天，科学家们仍然对此存在着激烈的争论。本电子书旨在向非专家解释互联网拥塞控制的核心概念和方法。当然，可以更深入地了解它，我们在本指南中提供了一些其他资源的链接，以便进一步阅读。

​今天的互联网是一个繁忙而拥挤的地方。许多不同的服务和应用程序相互竞争，通过同一网络基础设施发送流量。有时，根本没有足够的空间容纳每个人。 互联网流量被分段为数据包，数据包是单独的数据单元。当网络带宽无法支持每个互联网流量数据包的传输时，网络就会变得拥塞。这就像我们的物理高速公路在高峰时段被车辆堵塞一样。

当交通量上升到压倒性水平时，拥塞控制的必要性就变得显而易见。一个例子是在超级碗周日期间，每个人都同时在线试图观看比赛。当网络容量太有限而无法支持中等流量时，也会发生这种情况，这种情况可能发生在带宽有限的偏远或农村地区。也就是说，需要永久地进行拥塞控制。因为我们都共享相同的网络资源，而需求往往远远超过供给，所以我们需要以合理的方式共享它们。

互联网拥塞控制通过以有组织的方式在用户之间共享带宽，为这个拥挤的流量系统带来秩序。这样，每个人都可以享受到更好质量的体验。

2什么是拥塞控制以及它为什么重要

拥塞控制就是控制每个流量源在任何给定时间点发送数据的速率。简而言之，拥塞控制控制着如何在所有传输数据的网络之间分配总网络容量。我们需要拥塞控制来防止互联网流量堵塞并淹没网络。由于其复杂性和重要性，拥塞控制是通信网络长期面临的挑战。

拥塞控制与流量控制

我们深入研究拥塞控制之前，这里先简单解释一下有时会混淆的两个术语：拥塞控制和流量控制。

流量控制涉及防止发送方用过多的流量淹没接收方。这是一个相当简单的问题。接收方可以简单地告诉发送方它可以处理的流量速度，发送方相应地调整其发送速率。

拥塞控制是为了找到有效利用网络的流量的方法，并与竞争流量交互而不压垮网络。网络是动态的，可见性有限，让发送者能够推断正在发生的事情。正如您将在这本电子书中看到的那样，这可能是一项极其复杂的任务。

自互联网早期以来，流量控制一直是一个令人担忧的问题，因为发送计算机的传输速度无法快于接收方的接收速度。拥塞控制直到 1986 年才成为一个严重问题，当时互联网经历了第一次“拥塞崩溃”。

下图显示了连接到互联网的用户的增长情况。（是的，1969年只有4个。）1986年，当在线用户只有5000人时，带宽突然供不应求。当劳伦斯伯克利实验室 (LBL) 和加州大学伯克利分校之间的几跳网络路径变得拥塞时，吞吐量从通常的 32 Kbps 下降到 40 bps（下降了 1000 倍！）。这是创建互联网拥塞控制算法的历史触发因素：

@Robert H Zakon

什么我们需要拥塞控制

在解释互联网拥塞控制时，我们最喜欢用通过管道泵送水的类比，如下图 2 所示

如果水流不够强，最终用户将需要很长时间才能注满浴缸。但是，如果水太多，可能会使管道变形并导致泄漏。同样，如果数据通过网络传输的速度不够快，最终用户可能无法收到足够的数据来享受良好的体验质量 (QoE)。例如，如果有人正在观看高清电影，他们需要输入大量数据才能获得清晰锐利的图像。
​
​如果将太多数据泵入管道，管道可能无法处理该数据量。它最终可能会泄漏数据，这种现象称为数据包丢失，导致最终用户因重复的视频重新缓冲而感到沮丧。因此，发送数据太快也会导致 QoE 较差。

拥塞控制需要在未发送足够数据和发送过多数据之间找到界限

拥塞控制不应与路由相混淆，路由是另一个基本的网络挑战。回到水管的类比，拥塞控制的任务是确保管道得到有效使用，而路由则负责确定水（数据）将流经哪个管道或管道序列。互联网路由算法决定数据流量将经过哪些路径。在当今的互联网中，与早期的互联网不同，拥塞控制和路由是由单独的算法独立处理的。

拥塞控制对体验质量的重要性

QoE 是指数据消费者在使用互联网时体验到的满意度水平。以视频流为例，QoE 体现在：

` 您的流媒体视频需要多长时间才能开始播放。

` 图像质量，例如您是否可以欣赏高清或较低质量的电影，或者您是否在中途看到质量突然下降。

` 重新缓冲时间，这是您必须花在看着可怕的轮子一圈又一圈地等待视频恢复上的时间。（研究表明，人们看到缓冲轮时的身体反应与观看恐怖电影时类似。）

` 延迟（“实时延迟时间”）是指操作与其在屏幕上显示之间的时间延迟。这对于实时体育转播来说是一个至关重要的问题，即使是几秒钟的延迟也可能导致观众在看到进球得分之前听到邻近公寓的欢呼声或在社交媒体上看到剧透。

拥塞控制是对此类服务的 QoE 影响最大的因素之一，远远超过更快的互联网连接。

互联网提供商可能声称升级到 5G、光纤电缆或更高的带宽将解决您的 QoE 问题。这些往往都是空洞的承诺。根据《华尔街日报》报道的研究，即使是最高带宽的用户通常也只有大约 36% 的时间接收高清视频。当问题出在其他地方时，消费者可能将钱浪费在大型互联网套餐上 。

QoE 的真正问题通常是数据离开云或内容交付网络 (CDN) 并到达最终用户设备的“最后一英里”。数据传输中的不同问题经常在数据到达消费者家中之前很久就出现。因此，通过增加带宽来扩大家庭互联网连接就像扩大狭窄管道的口一样。水不能仅仅因为管口更宽而流过管道的其余部分更快。

如下图 3 所示，CDN 通过使用位于世界各地的代理服务器网络，在使内容交付更快、更可靠方面大有帮助。CDN 服务器距离最终消费者越近，内容到达消费者设备所需的时间就越短。然而，无论距离有多短，服务器和用户仍然经常被数据必须穿越的具有挑战性的网段分开。值得注意的是，对于视频会议等不可缓存的内容，CDN 根本没有帮助

最后一英里通常是一个混乱的旅程，可能包括不同网络（CDN、ISP、家庭）和网段（移动、有线、无线、家庭 WiFi）之间的多次传输。这一旅程的每一段都涉及到不断变化的条件，使得拥堵控制变得非常复杂。成功的拥塞控制必须同时满足三个不同的目标，这些目标可能相互矛盾。

3拥塞控制的三个目标

成功的拥塞控制的三个目标是：
· 充分利用网络带宽
· 将数据丢失和延迟降至最低
· 在所有关系中保持公平

这三个目标之间存在明确的权衡。尽管您希望充分利用网络带宽，但您不想过度使用，因为这会导致数据丢失。您可以不惜一切代价优先考虑公平性，但这可能会导致您未充分利用网络带宽。

除非实现这些目标中的每一个，否则无法完全解决拥塞控制问题。这是更深入的解释。

想象一个简单的场景，如下图 4 所示，显示了三个连接对

通常，互联网连接是双向的。例如，Facebook 将数据发送给最终用户，但这些最终用户也将数据发送回 Facebook。每个发送者也是接收者，反之亦然。为了简化事情，我们假设在所有三个连接中，一个端点（发送方）正在向另一端点（接收方）发送流量。具体来说：

Facebook 服务器（发送方 1）将流量发送至 Facebook 用户（接收方 1）
Netflix 服务器（发送方 2）将流量发送到 Netflix 视频客户端（接收方 2）
Zoom 视频会议用户（发送方 3）将流量发送给不同的 Zoom 用户（接收方 3）

假设三个发送方共享带宽为 120 Mbps 的网络链路，这意味着它每秒可以传送 120 兆位（120,000,000 位）的数据。
三个连接应使用什么数据传输速率？这正是拥塞控制算法必须确定的。以下是我们的三个拥塞控制目标影响算法结果的方式。

• 充分利用网络带宽

Internet 服务和应用程序通常希望以尽可能高的速率发送数据，因为这可以为用户带来更好的 QoE。因此，拥塞控制应该使应用程序能够使用尽可能多的可用带宽。

在我们的示例中，我们的带宽为 120 Mbps。该算法可以允许每个连接使用 10 Mbps，但这意味着它们总共只使用可用 120 Mbps 中的 30 个。这会留下大量闲置带宽，未使用。这还意味着应用程序可能会被限制为低于良好 QoE 所需的带宽。因此，理想情况下，三个发送方应一起以 120 Mbps 的速率注入流量，从而充分利用链路。

• 将数据包丢失和延迟降至最低

当数据包进入网络的速度超过网络可支持的速度时，就会产生拥塞，而拥塞会导致数据包延迟和/或丢失。
例如，假设每个应用程序以 60 Mbps 的恒定速率传输数据。它们的总传输速率为 3 x 60 = 180 Mbps，比网络带宽高出 50%。

这是一个问题。网络无法在数据包进入网络后立即发送所有数据包，因为数据包太多了。网络将额外的数据包存储（缓冲）在路由器 A 上，直到它可以继续发送它们。这会导致数据到达接收器的延迟，如果网络中没有足够的空间来存储数据，甚至可能导致数据被丢弃和丢失。

• 连接之间公平

最后一个要求是算法必须公平对待所有发送者。当谈到拥塞控制时，通常很难定义“公平”的含义。对于我们的简单示例，我们将说“公平”意味着每个发送者都可以以相同的平均速率传输数据。如果 Facebook 可以以 80 Mbps 的速度发送数据，但 Netflix 和 Zoom 只能以 20 Mbps 的速度发送数据，那么这对 Netflix 和 Zoom 或使用这些应用程序的人来说不太公平。

为了解决所有 3 个目标，我们可以说每个发送方应以 40 Mbps 的速度传输数据。这似乎是完美的解决方案，它解决了所有 3 个要求：

充分利用网络带宽。总网络使用量为 120 Mbps，即 100% 的容量，确保不会浪费额外的带宽。
将数据包丢失和延迟降至最低。流量进入链路的速度不会超过网络处理速度，因此不会出现不必要的数据包延迟或数据包丢失。
在关系中保持公平。每个发送者使用完全相同的带宽份额。

它看起来看似简单。那么为什么拥塞控制是一个如此复杂的挑战呢？这是因为现实世界的互联网流量比我们的简单示例复杂得多。

在现实世界的互联网拥塞控制中，每个发送者都独立于其他发送者做出决策。这是在没有太多有关网络内条件（例如链路容量）的信息的情况下完成的，并且网络条件不断变化。更重要的是，可能有远远超过三个的连接竞争网络带宽，新的连接意外地进入网络，而其他连接则突然离开。

我们将在下一节中更详细地讨论这一点。

4为什么网络拥塞控制如此具有挑战性

拥塞控制是网络研究和实践中解决的最持久和最关键的问题之一。 阻碍互联网拥塞控制解决方案的主要问题都存在于具有挑战性的“最后一英里”中，其中：
· 网络状况可能会随着时间的推移而发生巨大变化并迅速变化
· 流量决策是分散的
· 流量发送者有关网络状况的信息非常有限
· 不同的连接竞争网络带宽
·共享同一网络的互联网应用程序和服务具有不同且相互冲突的需求
· 高度可变的网络条件

最后一英里网络通常是复杂、多样且动态的环境。不同的网段在大小、结构、丢失模式、网络延迟、竞争水平等方面可能有所不同。可以将其视为一大片混乱的管道，其中一些管道又大又宽，而另一些则狭窄、泄漏且扭曲。 即使使用图 4中的简单示例，也可以说明网络条件的惊人多样性。网络属性包括：
· 网络链路的带宽
· 数据包穿过链路所需的时间（也称为链路延迟）
· 当链路容量耗尽时，RouterA用于存储多余数据包的缓冲区大小
· RouterA 在达到缓冲区满容量时丢弃数据包的排队策略
所有这些属性在拥塞控制方面都具有重大影响。例如，如果网络队列或缓冲区很浅，那么即使是少量的带宽超调也可能导致数据包丢失。但如果队列很深，带宽超调可能会导致数据包在网络内聚合，以便在拥塞再次缓解时发送，从而导致长时间延迟。

此外，通过这些管道传输的数据量不断变化。每一秒，不同流量的交通都在争夺同一段管道。此外，一些管道本身可能会出现具有挑战性的条件，例如移动网络或卫星网络，这些管道很容易出现损失。在此类网络中，连接经历的数据包丢失可能根本不是由于拥塞，而是由于其他原因，例如物理介质或用户移动性。网络状况的不确定性使得很难就当前发送速率做出明智的决策。

• 发送速率决策是分散的

目前，每个发送方对于发送数据包时使用的速率做出自己独立的决策。没有中央机构监督这些决策，任何给定的发送者也没有明显的方法来了解竞争的发送者正在使用哪些速率，甚至有多少其他发送者在网络带宽上与其竞争。尽管我们希望利率决策能够相互良好地相互作用，但没有办法确保这一点。

• 关于传输成功和失败的有限反馈

由于发送者对网络本身的可见性非常有限，这一事实使问题变得更加复杂。除了非常特定的网络环境（例如数据中心）之外，互联网网络，特别是最后一英里网络，不会向发送者提供任何直接反馈。您在最后一英里环境中看到的唯一反馈是最终接收者和发送者之间的端点反馈。

这很像试图了解看不见的水管网络中正在发生的事情。您知道水已经离开自来水公司的水库，但您不知道当水通过不同的管道到达用户的浴缸时会发生什么。可能会出现总水管爆裂、水进入较小管道时流量过多或最终用户家庭管道出现一系列泄漏的情况。其中任何一个都会导致用户在注水时遇到困难。也有可能房子里的其他人同时洗碗来转移水。

通过互联网发送流量在很多方面都是相似的。发送者不知道其数据在发送给用户的途中发生了什么，只知道数据是否最终到达用户（有时他们甚至不知道）。如果数据在途中丢失或延迟，没有人确切知道为什么会发生这种情况。
​

• 连接之间的竞争

​当多个连接在同一网络上交互时（如我们前面的示例所示），一个发送者的动态行为可能会显着影响其他发送者。在图 4 中，我们显示了三对用户通过同一网络进行连接。如果发送方 1 立即决定显着提高其传输速率，则可能会导致拥塞，从而导致所有三个发送方丢包。或者，如果发送者的传输突然终止，网络带宽将立即释放以供其他连接使用。发送者无法明确知道哪些其他发送者正在使用或已停止使用网络，但尽管缺乏信息，但仍需要有效地采取行动。

它变得更加复杂。已经有许多拥塞控制解决方案，例如TCP Cubic和BBR。任何新的拥塞控制解决方案都必须与其他解决方案共存，这会使情况更加混乱，进一步增加网络环境的不确定性。任何新的拥塞控制算法仍然需要对使用不同拥塞控制解决方案的连接公平。使用对使用其他算法的连接过于激进的拥塞控制解决方案是不公平的（我们正在寻找您，BBR），并降低了它们的性能。

• 需求多样且相互冲突的互联网服务

在这种混乱的因素组合中，还有更多的问题需要考虑。互联网服务和应用程序在带宽和延迟方面可能有不同的要求。实时视频流等服务；增强现实、虚拟现实或混合现实；和宽带物联网，都有不同的要求。有时，不可能同时见到所有人。

想一想图 4 中的第一个示例，其中 Facebook、Netflix 和 Zoom 都共享一个连接链接。每个应用程序都希望为其用户提供“良好的 QoE”，但它们对“良好”的定义各不相同。

对于像 Netflix 这样的视频点播，拥有支持高清观看的高带宽至关重要，这样观众才能始终看到清晰锐利的图像。如果视频传输有相当小的、一致的延迟，就不会给观看者带来不便。

Zoom视频会议首先需要低延迟，以防止不同人讲话时出现时间滞后。即使是半秒的延迟也会导致参与者互相交谈并错过谈话的重要部分。

互联网应用程序的时间敏感性也有所不同。想象一下，您的智能手机在您观看电影时下载了软件更新。显然，电影对时间敏感，在播放时应给予带宽更高的优先级。如果软件更新时间更长的话，您可能会非常高兴，因为这可以防止您的电影被中断、不得不重新缓冲或以较低的清晰度而不是高清显示。

应用程序需求的多样性意味着如何划分网络带宽并不总是很清楚。这可以用骆驼和斑马一起穿越沙漠的寓言来解释。他们的水量有限，所以公平地说，他们同意每人喝等量的水。当他们到达绿洲时，斑马几乎因脱水而倒下，但骆驼几乎没有接触到水。就像斑马和骆驼一样，不同的互联网服务有不同的需求，按照人为的“平等”标准对待它们有时是不可取的。

5TCP简介

输控制协议 (TCP) 是一种流行的拥塞控制解决方案，其历史可以追溯到互联网的早期。它依靠数据包反馈来计算出最佳的数据传输速率。现在我们解释 TCP 拥塞控制的工作原理。

• TCP 依赖于数据包反馈

在图 4的示例中，每个发送方传输数据包并接收有关数据包是否到达的反馈。该反馈采用确认 (ACK) 的形式，在收到数据包时发送。 尽管这种反馈非常有限，但发送者仍然可以通过检查 ACK 来获取有价值的信息，以跟踪哪些数据包未收到以及数据通过网络需要多长时间。具体来说，当数据包到达目的地已经过去了足够的时间但从未收到 ACK 时，可以推断数据包丢失。当收到后续数据包的 ACKS 但没有从接收方收到有关该数据包命运的消息时，也可以推断出丢失。此外，可以通过检查发送的数据包到达发送方所需的时间来估计网络延迟。传输数据包和返回同一数据包的 ACK 之间所经过的时间称为其往返时间 (RTT)。

• TCP 拥塞窗口

TCP 拥塞控制中的一个关键概念是拥塞窗口。拥塞窗口是在任何给定时间从发送方到接收方的途中（或“飞行中”）的最大允许数据包数量。一旦数据包到达接收方并且发送方收到 ACK，数据包就已到达并且不再“在飞行中”。实际上，拥塞窗口指定了在任何给定时间可以“传输”的数据字节数，但为了简单起见，我们将根据数据包的数量来考虑它。

下面的图 5说明了拥塞窗口的概念。想象一下拥塞窗口是 10 个数据包。如果发送方已经发送了 4 个数据包，它仍然可以发送另外 6 个数据包，同时等待前 4 个数据包到达目的地。但是，如果发送方发送了 10 个数据包，则在收到表明数据包已到达接收方的 ACK 之前，它无法发送另一个数据包。否则，发送方将超出可传输的数据包数量

TCP 的工作原理：慢启动和拥塞避免

TCP 首先将拥塞窗口设置得非常小，并在每个 RTT 中将其加倍。这个阶段称为“慢启动”。它会一直持续到 TCP 连接遇到困难为止，例如，数据包丢失，或者拥塞窗口超过某个阈值。当慢启动终止时，连接进入“拥塞避免”阶段。在拥塞避免期间，拥塞窗口的大小在成功接收到 ACK 时增大，在检测到数据包丢失时减小。

TCP Reno 在前 20 秒内缓慢启动，然后避免拥塞，如图 6 所示。TCP Reno 是 1990 年提出的 TCP 的经典变体。假设使用 TCP Reno 的发送方单独在一条链路上。当处于拥塞避免模式时，只要没有数据包丢失并且已发送数据包的 ACK 继续到达发送方，发送方就会增加其拥塞窗口大小。每个收到的 ACK 的窗口大小的增加是适度的，以避免网络容量超调。

在某些时候，发送速率将超过链路容量，链路的缓冲区将达到饱和点，并且数据包将丢失。当这种情况发生时，TCP Reno 会将拥塞窗口大小减少一半。这导致了雷诺著名的“锯齿”行为，如下所示。在这里，发送方达到链路容量，看到数据包丢失，然后急剧下降，然后重新开始上升。这种行为形式被称为加法-增加-乘法-减少（简称 AIMD），其中当收到 ACK 时，拥塞窗口增加固定的加法因子，而当检测到数据包丢失时，拥塞窗口减少乘法因子。如果 TCP Reno 在一段时间内没有收到任何反馈，它还可以将流量速率拖回慢速启动状态。

TCP 的工作原理：慢启动和拥塞避免

TCP 首先将拥塞窗口设置得非常小，并在每个 RTT 中将其加倍。这个阶段称为“慢启动”。它会一直持续到 TCP 连接遇到困难为止，例如，数据包丢失，或者拥塞窗口超过某个阈值。当慢启动终止时，连接进入“拥塞避免”阶段。在拥塞避免期间，拥塞窗口的大小在成功接收到 ACK 时增大，在检测到数据包丢失时减小。

TCP Reno 在前 20 秒内缓慢启动，然后避免拥塞，如图 6 所示。TCP Reno 是 1990 年提出的 TCP 的经典变体。假设使用 TCP Reno 的发送方单独在一条链路上。当处于拥塞避免模式时，只要没有数据包丢失并且已发送数据包的 ACK 继续到达发送方，发送方就会增加其拥塞窗口大小。每个收到的 ACK 的窗口大小的增加是适度的，以避免网络容量超调。

在某些时候，发送速率将超过链路容量，链路的缓冲区将达到饱和点，并且数据包将丢失。当这种情况发生时，TCP Reno 会将拥塞窗口大小减少一半。这导致了雷诺著名的“锯齿”行为，如下所示。在这里，发送方达到链路容量，看到数据包丢失，然后急剧下降，然后重新开始上升。这种行为形式被称为加法-增加-乘法-减少（简称 AIMD），其中当收到 ACK 时，拥塞窗口增加固定的加法因子，而当检测到数据包丢失时，拥塞窗口减少乘法因子。如果 TCP Reno 在一段时间内没有收到任何反馈，它还可以将流量速率拖回慢速启动状态。

• 多个发送方的 TCP 收敛和公平性

当多个 TCP 发送方共享相同的网络带宽时，它们必须不断地对彼此的发送速率做出反应，而实际上并不知道这些速率是多少。

假设两个发送方共享同一网络链路，如下图 7 所示，并且链路容量为 R Mbps。

理想情况下，两个发送者随着时间的推移平等地共享带宽，就像两股相等的水流流过管道一样，而不是一股水流占据整个管道，并且不为其他水流留下空间。但这很难实现，尤其是在两个发送者之间没有直接协调的情况下。

令人惊讶的是，TCP 在公平分配带宽方面做得相当好。要了解原因，请查看下面的图 8-10，其中连接 1 和连接 2 在容量为 R Mbps 的链路上发送流量。x 轴显示连接 1 的发送速率，y 轴显示连接 2 的发送速率。在图表上的任何给定点，总发送速率为 x+y。该图还显示了“公平线”，代表两个连接以相同速率发送的每种情况。

公平线上的某些点显然是不可取的。例如，当公平线大约为零时，发送速率非常低效并且远低于链路的全部容量。在线路另一端的某个时刻，发送速率之和过高并超过 R，导致数据包丢失。

相反，在图9中，虚线显示x+y=R，涵盖了两个连接的组合发送速率与链路容量完全匹配的所有场景：链路被充分利用。

发送速率的理想组合是图 8 中的线与图 9 中的线相交的点。图 10 显示了 x=y=R/2 的理想点，这最大限度地提高了带宽的公平性和利用率。


图 11 显示了以下场景中两个发送方的联合发送速率。从图中可以看出，连接1的发送速率最初高于连接2的发送速率。随着时间的推移，每个发送方以线性方式增加其速率，直到它们的联合速率达到总链路容量的 R 线。此时，他们都开始看到数据包丢失，并且速率下降了一半。因此，具有较高流量速率的发送方（即连接 1）比较慢的发送方将其速率降低得更多，导致两个连接的发送速率比以前更加接近。这种线性增加和速率减半的情况持续进行，每次都使两个发送速率更接近，从而更好地接近公平的结果。

无论有多少发送者，这种发送者越来越接近公平线的行为都成立；发送速率较快的发件人总是会比速率较慢的发件人降低速率更多（因为较快速率的一半比较慢速率的一半还要多），从而使速率较慢的发件人最终能够赶上。

• TCP 风格多种多样

到目前为止，我们已经使用 TCP Reno 作为示例来说明 TCP，但 TCP 有许多不同的变体。其他类型的TCP也有慢启动阶段和拥塞避免阶段；并响应于接收或未接收ACK来调整拥塞窗口。TCP 变体之间的差异在于拥塞窗口调整的方式，并且通常集中在拥塞避免阶段。

• Cubic

一个突出的例子是 TCP Cubic，它于 1998 年提出，并且仍然是当今网络中的主导 TCP。Cubic 是许多操作系统的默认拥塞控制算法，特别是 Linux 操作系统。TCP Cubic 尝试比 TCP Reno 更快地接管可用带宽，同时仍然对其他 TCP 连接公平。与 TCP Reno 一样，当在拥塞避免模式下检测到数据包丢失时，Cubic 也会将其拥塞窗口减半。

主要区别在于 Cubic 如何在拥塞避免期间提高速率。假设 TCP Cubic 发送方在拥塞窗口大小为 W 时经历数据包丢失，然后将其拥塞窗口减半。直观上，Cubic最初会急剧增加拥塞窗口，然后随着接近W而逐渐减慢拥塞窗口的增长，这是它之前遇到问题的地方。如果拥塞窗口超过W而没有看到丢包，Cubic会逐渐增加拥塞窗口的增长。这种先凹后凸的行为模仿了三次多项式的图形，因此得名。图 12 说明了拥塞窗口由于丢包而减半后拥塞窗口的变化。

• TCP Vegas

另一个有趣的 TCP 变体是 TCP Vegas。Vegas 对延迟敏感，这与 Reno 和 Cubic 不同，后者纯粹是基于丢失的。对于基于丢失的拥塞控制算法，数据包RTT对增加或减少拥塞窗口的决策没有影响。相比之下，当 Vegas 处于拥塞避免状态时，它不仅会像基于丢失的 TCP 变体那样在遇到数据包丢失后减小窗口大小，而且还会在 RTT“太长”时减小窗口大小。只有在观察到 RTT“足够低”时，Vegas 才会增加窗口大小。

与 Reno 和 Cubic 不同，当数据包在网络队列中等待时，Vegas 会增加 RTT。因此，当数据包开始在网络内聚合时，它可以通过降低速率来保持较低的数据包延迟。虽然这在理论上听起来不错，但它也带来了一个主要缺点。当 TCP Vegas 发送方与 TCP Reno 或 Cubic 发送方在相同链路上竞争时，前者总是为后者让路。这是因为维加斯的发件人很早就开始降低速率，从而只占用很小的网络带宽份额。由于 Reno/Cubic 发送方没有注意到 RTT 捕获的数据包延迟的增加，因此它们会继续全速发送，直到看到数据包丢失。

• 针对特定环境的 TCP 变体

某些 TCP 变体针对特定环境进行了优化，例如数据中心、WiFi 网络和卫星网络。例如，卫星数据传输的往返时间（RTT）可能长达数百毫秒，这对于互联网而言是一个很长的时间。高 RTT 意味着发送方可能需要很长时间才能收到有关数据包的任何反馈。最重要的是，卫星数据传输网络经常会遇到不可忽略的、与拥塞无关的数据包丢失。标准 TCP 假设任何丢失都表明拥塞；但如果丢失与拥塞无关，则发送者将无缘无故地降低流量速率。因此，一种不同形式的卫星 TCP（称为 TCP Hybla）被发明来解决这些问题。

WiFi 和移动网络通常还会遇到非拥塞相关的丢失，以及其他挑战，例如由于信号强度或用户移动性变化而导致的带宽频繁变化。这鼓励研究人员和从业者针对这些特定环境定制解决方案。

相对大量的不同 TCP 变体表明了 TCP 算法的缺陷，这需要设计不同的单点解决方案。虽然 TCP 为互联网提供了令人钦佩的良好服务，但众所周知，它在许多现实环境中的性能很差。

现在我们将详细说明 TCP 的缺点和可能的替代方案。

6 不足之处对于TCP

• TCP 的硬连线响应（hardwired response）并不总是有意义

每个 TCP 变体的解决方案中都内置有硬连线响应。TCP 是一个严格的公式，可为数据包级事件生成固定的响应。例如，每当检测到丢包时，TCP都会以相同的方式响应，而没有考虑丢包的不同原因可能需要不同的响应。通常，这涉及将发送速率减半，如 TCP Reno 和 Cubic 中所做的那样。

TCP 的回应反映了其基本假设。关于丢包的两个强有力但隐含的假设是：

· 任何数据包丢失都是网络拥塞的迹象
· 发送者始终是造成拥塞的原因

然而，这些假设在实践中经常被违反，正如我们在下面解释的那样。

丢包的可能原因有很多，每种原因都需要不同的响应。即使同一连接也可能在不同时间由于不同原因而遭受数据包丢失。以下是一些可能的情况：

Packet loss cause	Ideal response
The sender is sending at a much faster rate than the network can handle, inducing packet loss for itself and others.	Sender should cut rate drastically
Other senders sharing the same links are sending too fast, so reducing your rate is unnecessary or even unhelpful. Say, for example, a sender starts transmitting data on a link that’s already dominated by another sender. In this scenario, cutting your own extremely low rate will harm your performance needlessly since it would have no effective influence on the network.	Continue sending at the same rate and wait for those actually causing congestion to cut their rates.
The link has a very shallow buffer and you are sending alone on the link. Packet loss could occur because you slightly overshoot the link’s bandwidth.	Drop rate only slightly, to match the link’s bandwidth.
A different cause unrelated to congestion, such as: changes to the connection’s underlying route, the recipient moved between mobile base stations, packets became corrupted due to some issue at the physical layer, or other possibilities.	Continue increasing the send rate because the network is not yet congested and decreasing it won’t reduce packet loss.

Figure 13 shows the best response to each of the four scenarios described above:

在许多情况下，硬连线 TCP 响应实际上与最有效的响应相反。例如，如果数据包丢失与拥塞无关，则发送方应提高其发送速率，而不是将其减半。导致 TCP 算法拥塞控制效率低下的根本问题是，任何不考虑原因或上下文的对数据包丢失的硬连线响应都将无法提供高性能。

将流量降低一半的决定纯粹是任意的。为什么是一半而不是三分之二或四分之一？没有真正的答案。

TCP 是一种单一尺寸，并不适合任何人

TCP 的另一个基本限制是您无法针对不同应用程序和网络条件的需求对其进行定制。

无论您是在曼哈顿通过智能电视观看 VoD，还是在巴塞罗那通过移动设备观看体育直播，TCP（默认为 Cubic）都将以完全相同的方式运行。它不能适应网络上运行的不同互联网应用和服务的特定要求，也不能根据网络条件定制其速率调整规则。

之前，我们举了一个例子，某人在移动设备上观看电影，同时在后台下载软件更新。理想情况下，对时间敏感的电影（即主要用户）应优先于软件下载（称为清道夫）。但是，如果两个应用程序都使用 TCP Reno 或 TCP Cubic，则不会发生这种情况。正如我们在第 4 节中讨论的，Reno 和 Cubic 将尝试确保两个连接（几乎）平等地共享网络带宽。这可能会导致流视频获得的带宽少于支持高清观看所需的带宽，而软件更新下载速度却过快。

不同的网络表现出截然不同的特征。某些网络可能存在大量与非拥塞相关的数据包丢失，对于在巴塞罗那的移动网络上观看体育直播的个人来说可能就是这种情况。这是因为移动网络连接不太稳定，网络带宽经常变化，从而导致丢包率增加。在其他网络中，所有损失可能都与拥塞有关，曼哈顿智能电视上播放的电影可能就是这种情况。在某些网络中，带宽竞争可能非常激烈，而在其他网络中，发送方可以与其他连接有效隔离。在某些情况下，网络缓冲区可能非常深，而在另一些情况下，网络缓冲区可能非常浅。同样，没有理由期望相同的硬连线响应能够在如此广泛的网络环境中提供高性能。

有了 TCP，互联网数据传输就变得不太适合任何人。它没有根据每个用户、应用程序或网络的需求进行定制。为了解决这个问题，通过根据特定上下文定制硬连线响应，为特定网络环境或特定应用程序设计了 TCP 变体。然而，TCP 算法框架的局限性通常会提供远非最佳的性能，即使在它们设计的环境中也是如此。

计算机科学家一直在探索其他类型的拥塞控制算法来克服这些基本问题。较新的非 TCP 拥塞控制算法（例如BBR和PCC）采用完全不同的方法。这些替代方案基于收集有意义的数据并使用它来确定最佳行动方案。

这些 TCP 替代方案可以大致分为基于模型的方法和无模型的方法。

剩余部分见之后文章

🔗

tcp 模型之分
BBR：YOU ARE NOTICED
CC debate
TCP 公平性