互联网拥塞控制终极指南

2023-11-10

本文为媒矿工厂翻译的技术文章

原标题：The Ultimate Guide to Internet Congestion Control

原作者：Michael Schapira

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

翻译整理：马文涛

PART

介绍

拥塞控制是一个复杂的话题，围绕它人们已经进行了数十年的学术研究。事实上，直到今天，科学家们仍对它有着激烈的讨论。这篇文章旨在向非专家解释互联网拥塞控制的核心概念和方法。当然，这个领域有更多深层的内容，可以参考原文中其他资源的链接供进一步阅读。

今天的互联网是一个繁忙和拥挤的地方。有许多不同的服务和应用程序相互竞争以通过相同的网络基础设施发送它们的流量。有时，根本没有足够的空间供每个人使用。

Internet 流量被分割为数据包，这些数据包是单独的数据单元。当网络带宽不能支持互联网流量的每一个数据包的传输时，网络就会变得拥挤。这就像我们的高速公路在高峰时段被车辆堵塞一样。

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

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

PART

互联网拥塞控制

什么是互联网拥塞控制，它为什么重要？

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

拥塞控制与流量控制

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

流量控制关注的是防止发送方用过多的流量淹没接收方。这是一个相当简单的问题。接收方可以简单地告诉发送方它可以处理的流量速度，然后发送方相应地调整其发送速率。
拥塞控制是为流量找到有效利用网络的方法，并与竞争流量进行交互而不会压倒网络。网络是动态的并且提供有限的可见性，让发件人推断正在发生的事情。正如您在本电子书中所见，这可能是一项极其复杂的工作。

互联网的早期开始，流量控制就一直是一个问题，因为发送计算机的传输速度不能比接收者可以接收的速度更快。拥塞控制直到 1986 年才成为一个严重的问题，当时互联网经历了第一次“拥塞崩溃”。

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

为什么我们需要拥塞控制

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

如果水流不够强劲，最终用户需要很长时间才能装满浴缸。但是，如果水太多，可能会使管道紧张并导致泄漏。同样，如果数据通过网络传输的速度不够快，最终用户可能无法收到足够的数据来享受良好的体验质量 (QoE)。例如，如果有人正在观看高清电影，他们需要大量数据才能获得清晰锐利的画面。

如果过多的数据被泵入管材，管件可能无法来得及处理。它最终可能会泄漏数据，这种现象称为数据包丢失，导致最终用户因重复的视频重新缓冲而感到沮丧。因此，发送数据太快也会导致 QoE 不佳。

拥塞控制需要控制数据处在没有发送足够数据和发送太多数据之间。

拥塞控制不应与路由混淆，这是另一个基本的网络挑战。回到水管的比喻，虽然拥塞控制的任务是确保有效地使用管道，但路由负责确定水（数据）将流经的管道。Internet 路由算法确定数据流量将通过哪些路径。在今天的互联网中，与早期不同，拥塞控制和路由由单独的算法独立处理。

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

QoE 是指数据消费者在使用互联网时的满意度。例如，在视频流中，QoE 表现在：

您的流媒体视频开始播放需要多长时间。
图像质量，例如您是否可以欣赏高清或较低质量的电影，或者您是否在中途看到质量突然下降。
重新缓冲时间，这是您必须花费的时间来等待您的视频恢复。（研究表明，人们看到缓冲时的圈圈的身体反应类似于他们观看恐怖电影时的反应。）
延迟（“直播时间”）是指操作与其在屏幕上出现之间的时间延迟。这是实时体育广播的一个关键问题，即使是几秒钟的延迟，也可能导致观众在看到进球之前听到邻近公寓的欢呼声或在社交媒体上看到剧透。

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

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

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

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

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

PART

拥塞控制的三个目标

拥塞控制的三个目标是：

充分利用网络带宽
将数据丢失和延迟降至最低
在所有连接中保持公平

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

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

想象一个简单的场景，如下图 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%，可确保不会浪费额外的带宽。
将数据包丢失和延迟降至最低。流量进入链路的速度不会超过网络的处理速度，因此不会出现不必要的数据包延迟或数据包丢失。
在连接之间保持公平。每个发送方使用完全相同的带宽份额。

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

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

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

PART

为什么

为什么互联网拥塞控制如此具有挑战性？提示：因为现实世界很复杂

拥塞控制是网络研究和实践中解决的最持久和最关键的问题之一。妨碍互联网拥塞控制解决方案的主要问题都存在于具有挑战性的“最后一英里”，其中：

随着时间的推移，网络状况可能会发生巨大变化并迅速变化
传送速率决策是分散的
流量发送者关于网络状况的信息非常有限
不同的连接争夺网络带宽
共享同一网络的 Internet 应用程序和服务具有不同且相互冲突的需求

高度可变的网络条件

最后一英里网络通常是复杂、多样和动态的环境。不同的网段在大小、结构、丢失模式、网络延迟、竞争水平等方面可能有所不同。把它想象成一大堆混乱的管道，其中一些又大又宽，而另一些则狭窄、漏水和扭曲。

即使使用图 4 中的简单示例也可以说明网络条件的多样性。网络属性包括：

网络链路带宽
数据包通过链接所花费的时间（也称为链接延迟）
当链路容量耗尽时，RouterA用于存储多余数据包的缓冲区大小
RouterA缓存满时丢弃报文的排队策略
更多

所有这些特性对拥塞控制有着显著的影响。例如，如果网络队列或缓冲区很浅，那么即使是少量的带宽过冲也会导致数据包丢失。但是，如果缓冲区很深，超出带宽可能会导致数据包在网络内聚合，以便在拥塞再次缓解时发送，从而导致长时间延迟。

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

发送速率决策是分散的

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

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

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

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

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

连接之间的竞争

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

已经有许多拥塞控制解决方案，例如 TCP Cubic 和 BBR。任何新的拥塞控制解决方案都必须与其他解决方案共存，这些解决方案更加混乱，进一步增加了网络环境的不确定性。任何新的拥塞控制算法仍然需要对使用不同拥塞控制解决方案的连接保持公平。使用对使用其他算法的连接过于激进的拥塞控制解决方案是不公平的（例如，BBR），并拖累它们的性能。

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

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

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

对于像 Netflix 这样的点播视频，拥有支持高清观看的高带宽至关重要，因此对于观看者来说，画面始终清晰锐利。如果视频传输中存在较小的、持续的延迟，则不会给观看者带来不便。

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

Internet 应用程序的时间敏感性也有所不同。想象一下，您的智能手机在您播放电影时下载了软件更新。显然，电影是时间敏感的，在播放时应该给予更高的带宽优先级。如果您的电影不会被中断，不得不重新缓冲或以较低的清晰度而不是高清显示，那么您会更喜欢让软件更新需要更长的时间。

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

PART

介绍 TCP

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

TCP 依赖于数据包反馈

在我们图 4的示例中，每个发送方都传输数据包并接收有关数据包是否到达的反馈。该反馈采用确认 (ACK) 的形式，在接收到数据包时发送。

尽管这种反馈非常有限，但发送者仍然可以通过检查 ACK 来获取有价值的信息，以跟踪哪些数据包没有被接收到以及数据穿越网络需要多长时间。具体来说，当数据包经过足够的时间但从未收到 ACK 时，可以推断出数据包丢失。当接收到后续数据包的 ACKS 时，也可以推断出丢失，但接收方没有收到有关此数据包命运的消息。此外，可以通过检查发送的数据包到达发送方所需的 ACK 时间来估计网络延迟。从数据包传输到同一数据包返回 ACK 之间经过的时间称为其往返时间 (RTT)。

TCP拥塞窗口

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

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

TCP 控制拥塞窗口的大小。拥塞窗口越大，同时到达接收方的数据包就越多；这意味着以更快的速度发送流量。TCP 拥塞控制就是随时间调整拥塞窗口的大小。如果拥塞窗口过大，发送数据包的速率将超过网络容量，导致数据包丢失和/或延迟。如果拥塞窗口太小，可能会发送流量太慢以获得良好的体验质量。

请注意，TCP 并未明确更改发送速率。换句话说，TCP 发送方不会以“将发送速率更改为 7 Mbps”的形式做出决定。相反，通过更改拥塞窗口来间接更改发送速率。例如，如果窗口大小为 100，每个数据包的大小为 4000 位，RTT 为 1 秒，那么平均而言，发送速率为 (100x4000)/1 = 400,000 bps = 0.4 Mbps。稍后我们将在讨论 TCP 拥塞控制的替代方案时重新讨论这一点。

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

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

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

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

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

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

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

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

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

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

相比之下，在图 9 中，虚线表示 x+y=R，涵盖了两个连接的组合发送速率与链路容量完全匹配的每种情况：链路被充分利用。

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

当多个流交互时，TCP 的锯齿行为逐渐靠近公平带宽分配线，如下图 11 所示：

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

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

各种各样的 TCP 风格

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

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“太长”时减小窗口大小。Vegas 也只会在观察到 RTT“足够低”时才增加窗口大小。

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

特定环境的 TCP 变体

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

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

相对大量的不同 TCP 变体表明了 TCP 的算法缺陷，这需要设计不同的点解决方案。尽管 TCP 在 Internet 上的表现令人钦佩，但它在许多实际环境中的性能却是出了名的糟糕。

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

PART

TCP 不足之处

TCP 的硬连线响应并不总是有意义

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

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

任何数据包丢失都是网络拥塞的标志
发送方始终是拥塞的负责人

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

丢包的可能原因有很多，每个都需要不同的响应。即使是相同的连接也可能在不同的时间因不同的原因而丢失数据包。以下是一些可能的场景：

图 13 显示了对上述四种情况中每一种情况的最佳响应。

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

将流量减半的决定纯属武断。为什么是一半而不是三分之二或四分之一？没有真正的答案。

TCP 是一种尺寸，并不能适合所有的人

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

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

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

不同的网络表现出非常不同的特征。一些网络可能有大量与拥塞无关的丢包，这可能是个人在巴塞罗那的移动网络上观看体育直播的情况。这是因为移动网络连接不太稳定，网络带宽和随后的丢失率经常变化。在其他网络中，所有损失都可能与拥塞有关，曼哈顿智能电视上播放的电影可能就是这种情况。在某些网络中，带宽竞争可能非常激烈，而在其他网络中，发送方可以有效地与其他连接隔离。在某些情况下，网络缓冲区可能非常深，而在其他情况下，它们可能非常浅。

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

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

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

PART

TCP 的替代方案

TCP 的基于模型与无模型的替代方案

如果您着手为最后一英里网络等环境设计新的拥塞控制算法，则很难完全表征该算法将遇到的所有网络条件。在这种情况下，拥塞控制算法设计者必须决定他们可以对网络合理地假设什么，以及他们可以从他们的观察中自信地推断出哪些参数。

TCP 的替代方案主要有两种类型：基于模型的算法和无模型算法。它们之间的根本区别在于它们是否基于对网络及其行为方式的假设。

基于网络模型的算法依赖于网络环境的表示，即网络模型。该模型基于假设和来自观察到的网络动态的推论。该算法使用该模型来预测网络动态如何演变以及不同发送速率对性能的影响方式。

无网络模型算法将网络视为无法准确建模的黑箱。在没有任何预测基础的情况下，无模型算法会观察由不同发送速率产生的性能，并在经验上寻找速率和性能之间的“良好”映射。

这两种类型的算法具有不同的优势。如果您确信自己的假设和推论是正确的，那么基于模型的算法将使您获得比无模型算法的实验方法快得多的有效发送速率。但是，如果您的假设是错误的，那么您会在尝试为一个模糊的网络找到最佳发送速率时遇到很多挫折。

想象一下，在总带宽为 100 Mbps 的链路上有一个单独的连接。最佳发送速率为 100 Mbps。具有准确模型的基于模型的算法将从 100 Mbps 开始，因此几乎立即达到最佳发送速率。但这只有在它有一个准确的模型时才会发生。如果模型不正确，因为带宽如果是 200 Mbps 或者发送方不是单独在链路上，该算法要么无法充分利用链路，要么发送流量过快并导致数据包丢失。相比之下，无模型方法可能会花费宝贵的时间来探索不同发送速率对性能的影响。但是，如果基于模型的方法有错误的模型，则无模型算法可能会优于基于模型的算法，因为它不需要纠正错误的现实模型。

基于模型的方法非常适合可预测的网络，在这种网络中，可以从准确的网络模型开始。其中一些示例是大型组织（如 Google、Facebook 和 Amazon）内的私有内部网。这些网络稳定且行为良好；网络的所有基础设施都在集中控制之下。

无模型方法最适合难以准确建模的复杂网络环境，并且在动态条件下本质上更健壮。在互联网的最后一英里，条件在不断变化（正如我们上面所讨论的），因此无模型算法通常更合适。

我们将更深入地研究两种拥塞控制选项。BBR 是原型白盒、基于模型的方法，最初由 Google 为其内部网络开发。PCC 是黑盒、无模型方法的范例，并且是 Compira Labs 解决方案的基础。

PART

BBR

BBR - 基于模型的白盒拥塞控制方法

BBR是瓶颈带宽和 RTT 的缩写，是 TCP 最著名的替代方案之一。BBR 是一种拥塞控制算法，用于传送 YouTube 流量。它也被 Netflix 和其他一些重要的参与者采用。

简约之美

BBR 本质上是相当简单的。这是算法的基本结构。

想象一下，一个发送方正在向另一个通信端点发送数据。在沿途的某个地方，数据遇到瓶颈环节。尽管流量可能会穿越具有多个段和不同竞争的非常复杂的网络，但对于 BBR 而言，重要的是路径最窄点处的带宽。我们不知道是什么导致了瓶颈；它可能是来自其他流量、低带宽或多个其他问题的竞争加剧。BBR 通过将整个旅程归结为瓶颈宽度的单个链接来对整个网络进行建模。它探测网络以推断瓶颈带宽，然后调整其发送速率以匹配该带宽。我们将在下面解释 BBR 如何做到这一点。

BBR如何运作？

为了确定瓶颈链路带宽，BBR 会不断检查其相对于数据包到达接收器的速率的发送速率。考虑带宽为 100 Mbps 的链路上单独的发送方。现在，假设链路不拥塞。在这种情况下，数据包到达端点的速率应该与它们离开发送方的速率大致相同；这意味着 ACK 也会以大致相同的速率到达发送方。在我们的示例中，如果发送速率为 50 Mbps，则 ACK 也应以 50 Mbps 的速度到达。但是，如果发送速率超过带宽并且链路饱和，流量将以与带宽相同的速率到达接收器，因为这是链路可以支持的最快速率。ACK 也应该以大致相同的速率到达发送方，在我们的示例中为 100 Mbps。如果发送速率保持在带宽之上，当数据包排队等待交付时，队列将开始形成。通过比较发送速率和 ACK 到达速率，BBR 可以判断它的速率是否超过了链路带宽，并估计该带宽是多少。BBR 估计的瓶颈带宽是 BBR 的最佳操作点。它在不超过带宽的情况下充分利用链路，因此将丢失和延迟保持在最低限度。

要了解 BBR 如何选择何时以及如何增加/降低其发送速率，让我们继续使用 100 Mbps 链路上的单个发送器的简单示例。与 TCP 一样，BBR 以慢启动模式开始，每个 RTT 将其速率加倍。这一直持续到发送速率超过估计的瓶颈带宽。当这种情况发生时，BBR 会降低其速率以匹配估计的带宽并进入拥塞避免模式。BBR 会周期性地将其速率提高 25%，以检查瓶颈带宽是否发生了变化。如果接收速率同步上升，BBR 知道它可以以更高的速率继续。如果接收速率没有随着发送速率的增加而上升，则数据包的发送速率显然高于网络可以支持的速率。这意味着缓冲区中有一行数据包在等待，这可能会导致数据包丢失或过度延迟。为了解决这个问题，BBR 通过将发送速率降低到低于之前标准的 25% 来定期排空队列，因此可以发送缓冲的数据包而不会再堆积。如果我们在示例中绘制 BBR 发送方的发送速率图，它看起来像这样：

尽管我们的示例是针对由单个链接组成的网络路径，但 BBR 将整个路径建模为单个链接，无论该路径实际包含多少个链接。为此，BBR 在每种情况下都使用相同的过程来估计带宽。当多个持久的 BBR 连接在同一链路上发送流量时，实验表明它们通常都能获得公平的带宽份额。

BBR 与 TCP

BBR 与 TCP 的主要区别有两点：

BBR 调整发送速率，而不是拥塞窗口。我们已经解释过 TCP 改变的是拥塞窗口而不是实际的发送速率。对于 BBR，将决定以 Mbps 为单位的流量速度。
BBR 收集有意义的统计数据。与 TCP 不同，BBR 不规定对数据包级事件的硬连线反应。相反，它试图推断有关网络的有意义的统计数据，主要是通过 ACK 接收速率，并以此为基础来指导其速率选择。

在大多数情况下，BBR 的性能优于广泛使用的 TCP 变体，例如 TCP Cubic。通过明确针对瓶颈带宽，BBR 实现了更好的吞吐量和更低的延迟。此外，BBR 天生对非拥塞相关的丢失更具弹性，因为与 TCP 不同，它不会将数据包丢失视为拥塞信号。

也就是说，BBR 确实有缺点。

BBR 什么时候不合适？

BBR 依赖于其以易于处理且对决策有用的方式对网络进行建模的能力，无论其复杂程度如何。毫不奇怪，这并不总是可能的，尤其是在混乱的最后一英里。

尽管 BBR 似乎有一个很好的情况模型，但网络仍然可以包含各种意外。竞争性交通流量突然进出；基础路线可能会发生变化；不同的发送方可能会与采用不同拥塞控制算法的连接共享链路；用户移动性可能导致意外丢包和带宽波动等等。

当 BBR 模型偏离现实太远时，BBR 会做出不明智的决定。

另一个严重的缺点是 BBR 不是一个“公平”的拥塞控制解决方案。BBR 通常适用于使用相同协议的流量源。但是当 BBR 与其他流量控制协议对抗时，它的表现并不好。BBR 比其它流控制更加激进，从而接管所有有限的可用带宽。

PART

PCC

PCC - 一种黑匣子，无模型方法

PCC，即性能导向拥塞控制的缩写，由耶路撒冷希伯来大学和伊利诺伊大学厄巴纳香槟分校 (UIUC)的研究人员共同开发。与 TCP 一样，但与 BBR 不同的是，PCC 是拥塞控制算法的通用框架。所有 PCC 变体都是使用相同的效用函数和在线速率选择的通用架构构建的，我们将在下面更详细地讨论。PCC 变体在效用函数的具体选择和拥塞控制算法中内置的在线速率选择方案方面有所不同。

“无模型”的意义

正如我们所解释的，BBR 是一种基于模型的白盒方法，它利用网络统计信息来推断网络状况。PCC 正好相反。它作为一个无法理解的黑匣子接近网络。PCC 发送者从不尝试推断网络参数，例如瓶颈带宽或丢包的根本原因。

相反，PCC 将数据传输视为一系列“微实验”。在每个这样的微实验中，发送者量化当前发送速率的性能水平。它使用此信息随时间调整其发送速率。

PCC是如何工作的？

PCC 有两个主要组成部分：

效用函数
在线速率选择算法

效用函数，或效用框架，需要从所选择的发送速率得到统计数据，并将其转换成一个性能得分，或效用价值。此效用值表示以该速率发送所达到的性能水平。在线速率选择算法针对先前选择的发送速率观察到的效用值决定下一次发送的速率。

PCC 效用框架：灵活性的优势

当 PCC 发送方开始以特定速率发送数据包时，它会在 RTT 之后开始接收 ACK。这些 ACK 可以揭示信息，包括丢失的数据包比例、数据包延迟的上升或下降等。PCC 发送方收集这些信息并将其聚合为效用值或性能分数。

让我们考虑一个场景，在这个场景中，某个发送速率的性能被测量为安全到达目的地的流量比例。想象一个简化的连接，发送方以 50 Mbps 的速度发送数据包，其中 30% 的数据包，或每 100 个发送的 30 个数据包在途中丢失；这意味着 70% 到达。当使用这个简单的效用函数来量化性能时，派生的效用值等于 35，即 50 Mbps 的 70%。

该效用函数可以用以下等式表示：

U = X(1-L)

其中：

X 是发送速率
L 是丢包的比例；例如，L=0 表示没有丢包，L=0.1 表示丢了 10% 的包；L=0.5 表示有 50% 的数据包丢失；L=1 表示所有数据包丢失等。
U 是性能分数

例如，如果没有数据包丢失，那么 X 和 U 是相同的，因为所有数据包都到达了目的地。如果有一半数据包丢失，则 U=X/2。

效用函数的这种特定选择过于简单而无法发挥作用。原因如下：

如果您以 100 Mbps 的速度发送而没有任何数据包丢失，则 U 将等于 100。
如果您以 200 Mbps 的速率发送并看到 50% 的数据包丢失，则 U 仍等于 100。

U 在这两种情况下都是相同的，即使没有数据包丢失显然比丢失一半的数据包要好 - 没有在吞吐量方面获得任何好处。

本例中的效用函数完全忽略了延迟。它只会对网络缓冲区耗尽并且数据包被丢弃时的拥塞做出反应，而不是对拥塞的开始做出反应。因此，我们可以通过设置数据包延迟和数据包丢失的惩罚来创建更好的效用函数，以产生所需的属性。包延迟的惩罚表示为 p_D，丢包的惩罚表示为 p_L 。此类效用函数具有以下一般形式：

U = X – p_D X – p_L X

和以前一样，X 是发送速率，L 是丢失数据包的比例，U 是性能分数。随着延迟和丢失的增加，对数据包延迟和数据包丢失的惩罚应该增加。因此，p_D和 p_L 可以采用多种不同的形式。例如，当设置 p_L =100L 时，丢包对发送方效用值的负面影响比设置 p_L =L 时高 100 倍。观察到，当我们设置 p_D= 0 时，对数据包延迟没有惩罚，并且 p_L = L，我们得到

**U = X - L * X = X(1-L)**

这正是我们之前的简单效用函数。

现在该等式包括三个需要考虑的因素：

发送速率 (X)，我们希望尽可能地推高
数据包延迟（受 p_D惩罚），我们希望保持尽可能低
丢包率（受到 p_L的惩罚），我们也希望将其保持在尽可能低的水平

确定效用函数的好选择可能很微妙，因为效用函数有两个重要作用：

1. 为不同应用程序定制性能的灵活性

正如我们上面提到的，不同的应用程序有不同的需求。其中一些对延迟敏感，例如 Zoom，而另一些则需要带宽，例如 Netflix。可以调整实用功能以匹配每个应用程序的需求。例如，当使用 PCC 进行 Zoom 时，我们可以将数据包延迟的惩罚设置为高于使用 PCC 进行 Netflix 时的惩罚。这将导致更倾向于最小化延迟的行为，正如 Zoom 所青睐的那样，即使这是以降低带宽利用率为代价的，而带宽对 Netflix 来说更为重要。

2. 确保连接之间的公平性

我们已经讨论了公平性对于拥塞控制解决方案的重要性。使用 PCC，每个发送方都专注于根据其效用函数优化自己的发送速率。因此，存在一个发件人可能会垄断所有带宽而导致其他连接匮乏的风险。它们达到公平均衡的原因取决于博弈论。只要 PCC 用户是同类的，并且都使用某个家族的效用函数，就可以保证他们公平地共享带宽。在其他重要场景中也可以保证理想的带宽分配。

例如，这可以实现通过将一类效用函数用于主要的、时间敏感的流量（例如视频会议），以及另一类用于“清道夫”流量（例如软件更新）。

PCC 在线速率选择

在效用函数之后，PCC 的第二个组成部分是在线速率选择算法。PCC 发送者需要根据它观察到的先前选择的速率的效用值来决定接下来要使用的发送速率。这就是PCC的在线速率选择算法的作用。

这是它的工作原理。就像 TCP 和 BBR 一样，PCC 以慢启动模式开始，并在每个 RTT 中加倍速率。这一直持续到效用分数停止上升；这表明 PCC 将速率提高了太多，从而导致性能下降。此时，PCC 进入拥塞避免模式。

现在，假设 PCC 以特定速率 r 发送。确定它是否应该增加或减少其速率的简单方法如下。PCC 可以以略高于 r 的2% 的速率发送并检查派生的效用值，然后以略低于 r 的 2% 的速率发送，并再次检查派生的效用。在评估以更高和更低的速率发送如何影响性能（即效用值）之后，PCC 可以切换到更低或更高的速率，这取决于哪个产生了最高的性能分数。

不需要逆向工程

这种调整发送速率的算法的 PCC 的最早变体被称为PCCAllegro. 虽然很简单，但它避免了 TCP 的一些不足。考虑发送方遇到与拥塞无关的数据包丢失的情况。例如，假设每 100 个数据包中有 1 个被丢弃，无论您发送数据的速度有多快。在这里，提高发送速率不会增加丢失数据包的比例，但会导致更多数据包到达接收器并获得更好的性能分数。因此，PCC Allegro 将选择提高其发送速率。相反，如果发送方由于拥塞而遇到丢包，那么提高速率只会导致更多的丢包，而不会获得更多流量，从而导致性能下降。所以这时，PCC Allegro 将因此选择降低其发送速率。回想一下，无论丢包的原因如何，TCP 都会降低其发送速率，

与 BBR 不同，PCC 算法不会尝试确定为什么较高的速率比较低的速率更好，反之亦然。发送方不会尝试对网络条件进行逆向工程，例如通过明确推理经历的数据包丢失的可能原因。相反，发送方将网络视为一个黑匣子，只是试图了解其当前速率的哪些变化将带来最佳性能。

对 PCC Allegro 的改进

尽管 PCC Allegro 的简单算法是有效的，但它仍然存在一些缺点。主要的困难在于它总是以固定的步长改变其速率。在我们的示例中，这是 2%。正如我们将在下面讨论的，在某些情况下，这个步长会太大，而在其他情况下它会太小。

例如，下面的图 15 显示了一种 PCC 算法，该算法以 1% 的小步长降低发送速率。假设发送方最初以 r 的速率发送，该速率远高于网络带宽 R。由于发送速率明显高于网络所能支持的速率，因此会出现大量丢包和/或包延迟. 这些损失和延迟将继续，而速率以微小的增量缓慢下降，直到再次达到带宽阈值。或者，如果当前发送速率远低于可用带宽，则每次将发送速率提高 1% 可能需要很长时间才能达到合适的带宽利用率。

另一方面，图 16 显示了如果步长固定在太高的值（如 30%）会发生什么。首先考虑图 16(a) 中描述的场景，其中连接以 r1 的速率在链路上发送，该速率远低于可用带宽 R。这会导致网络利用率低下，因此 PCC 算法将提高其速率。由于步长很大，发送方将在一次巨大的跳跃中提高其速率，并且很可能大大超过网络容量，如图所示。然后，为了从这个错误中恢复过来，它会将其速率降低到过低，如图 16(b) 所示，然后再次增加，依此类推。

更先进的 PCC 速率控制方案建立在机器学习和博弈论的丰富文献基础之上，以解决这个问题。PCC Vivace 是一种比 PCC Allegro 更能响应网络变化并具有更好收敛速度的方案的例子。

无模型方法的好处

正如我们上面所讨论的，依赖于对网络的强假设的拥塞控制解决方案，如 TCP 和 BBR，当他们的网络模型偏离现实时，很容易导致性能不佳。由于其无模型方法避免了任何假设，PCC 在响应网络条件的意外变化方面更加稳健。这些变化是现实世界环境中的情况，尤其是在最后一英里。

在一个简单的对照实验中，我们比较了 BBR 和 PCC 在反映混乱最后一英里不可预测变化的情况下。我们的延迟、可用带宽和数据包丢失每秒都在变化。下图显示了对 PCC 和 BBR 的影响，以及理想的带宽利用率。

在图表上：

虚线表示充分利用可用带宽而不会造成丢包和延迟的最佳发送速率
点划线表示 PCC
实线显示 BBR

由于网络的混乱性质，您可以看到 PCC 和 BBR 性能之间的差距。PCC 比 BBR 率更接近地反映了最佳线的波峰和波谷。

PART

结论：拥塞控制的未来

正如您现在所了解的，拥塞控制几十年来一直是一项挑战。试图解决这个问题的计算机科学家需要克服许多障碍，包括模糊的、不断变化的最后一英里条件；来自其他连接的持续竞争；需要以最小的数据包丢失和延迟来平衡带宽利用率；以及在连接之间保持公平的要求等等。

对于互联网数据传输来说，这是一个激动人心的时刻，新的解决方案触手可及。很长一段时间以来，TCP 范式第一次受到质疑，并且其他方案——例如 BBR 和 PCC——已经被部署。随着我们的生活越来越多地需要网络，对高质量和公平网络访问的需求只会增长。我们已经看到企业和消费者对流媒体视频、视频会议、电子竞技、在线实时宗教服务等应用程序的需求不断增加。今天，我们需要更有效的方法来提高互联网体验质量。拥塞控制是服务提供商要考虑的关键因素。

讲师招募

LiveVideoStackCon 2022 音视频技术大会上海站，正在面向社会公开招募讲师，无论你所处的公司大小，title高低，老鸟还是菜鸟，只要你的内容对技术人有帮助，其他都是次要的。欢迎通过 speaker@livevideostack.com 提交个人资料及议题描述，我们将会在24小时内给予反馈。

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)