PDFBufferbloat：互联网中的暗缓冲区
缺乏有效主动队列管理（AQM）的网络可能再次容易受到拥塞崩溃的影响。
Jim Gettys，贝尔实验室，阿尔卡特朗讯；Kathleen Nichols，Pollere Inc.
注意：请务必阅读本文的姊妹篇，BufferBloat：互联网怎么了？。- 编辑。
当今的网络正遭受不必要的延迟和较差的系统性能之苦。罪魁祸首是 bufferbloat，即网络内部存在过大且频繁满载的缓冲区。大量缓冲区未经充分考虑或测试就被插入到互联网的各个角落。它们破坏或击败了互联网最常见的传输协议的基本拥塞避免算法。来自 bufferbloat 的长延迟经常被错误地归因于网络拥塞，而对问题的这种误解导致提出了错误的解决方案。
拥塞是互联网上的一个老问题，以各种形式出现，具有不同的症状并造成重大问题。缓冲区对于数据包网络的正常运行至关重要，但过大、未管理和不协调的缓冲区会造成过度的延迟，让最终用户感到沮丧和困惑。许多造成延迟的问题并不新鲜，但它们的集体影响尚未被广泛理解。因此，缓冲问题已经积累了十多年。我们努力呈现这些问题及其影响，以便社区能够理解并采取行动解决问题，并且我们希望，学会预防未来的问题。
本文并非声称是第一个识别出过度缓冲问题的文章，而是旨在更广泛地理解普遍存在的问题，并发出行动号召。
互联网缓冲区和拥塞
数据包在网络中经历的延迟由传输延迟（跨通信链路发送数据包所需的时间）、处理延迟（每个网络元素花费在处理数据包上的时间）和排队延迟（等待处理或传输所花费的时间）组成。互联网中通信端点之间的路径通常由许多跳组成，链路具有不同的速率或带宽；路径上最小的带宽被称为瓶颈带宽。数据包到达目的地的速度不能快于以瓶颈速率发送数据包所需的时间；如果网络没有得到有效利用，延迟可能会更糟。
沿路径的延迟——从发送者开始传输数据包到数据包到达目的地的时间——可能比以瓶颈速率发送数据包所需的时间长得多。为了以最大速率维持数据包的稳定流动，“飞行中的数据包”必须足以填满发送者和目的地之间的延迟“管道”。缓冲区放置在通信链路的前面，以防数据包在链路正在使用时到达，从而在之前的到达被服务时需要存储。缓冲区的重要位置是在路径瓶颈处，但关键的快到慢的转换对于不同的路径可能不同，在反向路径中可能不同，并且随着动态带宽，可能沿同一路径变化。
图 1 显示了数据包网络的吞吐量和延迟之间的关系。吞吐量是网络传输到目的地的数据包计数等于发送到网络的数据包数量的最快速率。随着飞行中的数据包数量增加，吞吐量也随之增加，直到数据包以瓶颈速率发送和接收。在此之后，更多的飞行中的数据包不会增加接收速率。如果网络沿路径有大的缓冲区，它们可能会被这些额外的数据包填满并增加延迟。
没有缓冲区的网络没有地方让数据包等待传输；因此，额外的数据包会被丢弃，导致丢包率增加和吞吐量降低，尽管接收到的数据包将具有相同的恒定延迟。为了在没有缓冲区的情况下运行，到达必须完全可预测和流畅；因此，全局同步定时对于避免丢包至关重要。这样的网络复杂、昂贵且具有限制性（即，它们缺乏互联网的灵活性）。无缓冲网络的著名例子是分组交换接管之前的原始电话网络。向网络添加缓冲区并将数据包化为可变大小的数据包是通信领域的基本进步的一部分，它导致了互联网的诞生。互联网拥塞的历史及其解决方案是尝试找到在网络中部署和使用缓冲区的最佳方式的故事。这个故事仍在书写中，但过去的一些教训正在被忽视。
互联网的基本传输协议是 TCP/IP。TCP 的持久性证明了原始算法的强大和灵活的设计，以及数十年来许多研究人员和工程师对其进行调整的卓越努力。TCP 利用了管道大小的概念，以及数据路径上存在合理但不过度的缓冲的知识，一次发送一个窗口的数据包——最初将整个窗口发送到网络中，并等待其确认后再发送更多数据。
即使在适度负载下，一个或多个连接的飞行中的数据包也可能以突发形式到达瓶颈链路，并由于带宽不足而被丢弃。这导致了严重的丢包和与拥塞崩溃相关的吞吐量骤降。互联网研究人员和工程师不得不倡导足够大的缓冲区，以避免这种糟糕的网络利用率。1986 年，拥塞崩溃袭击了互联网的很大一部分。网络被重传的数据包阻塞，而有效吞吐量降至涓涓细流。作为解决方案的一部分，慢启动和拥塞避免算法被添加到 TCP 中，并在整个互联网中迅速部署。它们使早期的互联网得以恢复，并为 20 世纪 90 年代随着万维网应用的采用而实现的互联网快速增长奠定了基础。
这些 TCP 添加尝试使网络在吞吐量最大化、延迟最小化且几乎不发生丢包的拐点附近运行。发送者-目的地对的 TCP 尝试确定它们之间的管道大小，并在整个数据传输过程中保持正好数量的飞行中的数据包。由于网络是共享的，并且沿路径的条件会发生变化，因此算法不断探测网络并调整飞行中的数据包数量。慢启动算法（相对于它取代的算法而言是慢的）试图通过传输速率的初始指数增长阶段来初步猜测 TCP 可能运行的速度。当检测到第一个数据包丢失时，TCP 会降低其发送速率并进入拥塞避免阶段。
在 TCP 拥塞控制出现之初，缓冲区大小调整的建议是拥有一个带宽-延迟乘积 (BDP) 值的缓冲区，其中带宽是瓶颈链路，延迟是发送者和目的地之间的往返时间 (RTT)。理由是，如果所有数据包都以突发形式到达瓶颈链路，则这样的缓冲区可以容纳整个“飞行”的数据包。为了应用此规则，链路缓冲区大小调整中使用的带宽是紧邻的传出链路的带宽，因为实际瓶颈的位置是未知的。同样，对于 RTT 提出了一个规范值：100 毫秒，这是美国和欧洲的洲际延迟。
一旦充足的缓冲区成为常态，另一个问题可能会发生：缓冲区现在成为 TCP 非常擅长填充的管道的一部分。填充这些缓冲区会导致延迟增加，并且持久满载的缓冲区缺乏空间来吸收数据包网络的常规突发性。John Nagle 在 1985 年的开创性工作8 首先引起了人们对大型缓冲后果的关注。在研究 TCP 拥塞避免算法时，Van Jacobson 在 1989 年认识到“持久满载缓冲区”问题，最终在 1993 年与 Sally Floyd 共同开发了 RED（随机早期检测）。5
文献中提供了许多关于 RED 使用的实现、变体、模仿和报告。12 这些统称为 AQM（主动队列管理），它试图通过监控数据包队列的增长并及时丢弃（或标记）数据包来向发送者的 TCP 发出减速信号，从而防止瓶颈处的队列增长过大。已经采用了不同的方法来监控数据包队列并做出丢弃（或标记）决策。互联网研究任务组 (IRTF) 敦促在互联网中部署主动队列管理，并在 1998 年发布了一份 RFC，俗称“RED 宣言”。2
请注意，TCP 的数据包丢失本身不是问题，而是 TCP 在面对拥塞时发挥作用所必需的。来自持久满载缓冲区的过度和连续的数据包丢失确实会带来问题，这正是 AQM 的“警告”丢弃所要预防的（除了长延迟之外）。
事实是，AQM 在路由器中并未得到广泛或一致的配置和启用，并且在许多设备中完全不可用。此外，廉价内存的存在和避免数据包丢失的错误愿望导致在构成互联网的主机、路由器和交换机中部署了越来越大的缓冲区。事实证明，这是 bufferbloat 的秘诀。过去十年中，bufferbloat 的证据一直在积累，但其存在尚未引起广泛关注。下一节概述了 Jim 的个人发现之旅。
（重新）发现延迟
“今天的互联网很慢，爸爸。” 这已成为盖蒂斯家中经常出现的抱怨。当我想尝试调试问题时，就像鬼火一样，它通常会消失。在几次情况下，症状持续了足够长的时间，以至于我在我的 ISP 支持热线上浪费了大量时间，然后它们才消失。我将反复出现的问题归因于连接到我家的电缆质量可疑，或者设备因雷击而损坏。由于我的工作是沉浸式远程会议研究，我知道我必须深入研究间歇性网络性能不佳的问题，即使只是为了我自己。
一次富有启发性的午餐
怀疑我的有线电视提供商的功能是问题的一部分，我与 Comcast 的 Rich Woundy 会面，他提供了一些需要考虑的新问题
• “大缓冲区”问题，David Clark [互联网网络架构师，现任 MIT 高级研究科学家] 几年前就曾警告过这个问题。
• 宽带测量研究表明边缘缓冲区过大。
• AQM 缺失——许多 ISP 在即使他们真的应该这样做的情况下，也在没有任何 AQM 的情况下运行。
• 加州大学伯克利分校 ICSI（国际计算机科学研究所）的一个小组开发了一个非常好的网络诊断工具，称为 Netalyzr。
第二天，我记录了我的“确凿证据”，一个 smokeping 图，同时将 20 GB 的数据从我家移动到 MIT（见图 2）。这条路径的非拥塞 RTT 小于 10 毫秒，但我却经历了超过 1.2 秒的延迟、严重的丢包和痛苦的 Web 浏览体验。我暂停了几次 rsync 以阅读我的电子邮件，并且，正如在图中看到的那样，这几乎可以立即“修复”我的家庭网络。这就是“爸爸，今天的互联网很慢”现象：当我暂停我的大型数据传输时，延迟消失的事实解释了为什么当我寻找问题时问题就消失了；为了调试网络，我停止了导致问题的工作。
家庭和“国外”的数据包捕获
我捕获了同一路径上的大型文件传输。使用 Wireshark 滚动浏览此捕获显示了奇怪的行为：明显的糟糕行为突发，包含数百个重复的 ACK、多次重传、乱序数据包等，持续约 10 秒，然后是长时间看起来正常的行为。数据的图表显示，在 10 毫秒的路径上有 500 KB 的飞行数据。我的上行带宽为 2 Mbps，因此真正的 BDP 为 2.5 KB。我预计使用 100 毫秒的 RTT 进行缓冲区大小调整会导致 25 KB，但 500 KB 大了一个数量级。1 秒的 RTT 与以 2 Mbps 清空 500 KB 缓冲区是一致的。为了消除不确定性，我重复了实验，直接插入电缆调制解调器，看到了相同的结果。
我在我岳父母在新泽西州的光纤宽带服务上重复了我的测试。同样，结果显示飞行中的数据更多，RTT 时间也比预期的长得多：在 20 毫秒的路径上有 250 KB 未完成数据，延迟为 200 毫秒，形状几乎与我的电缆上的相同。在随后的几周里，我通过访问当地图书馆和其他机会目标添加到我的数据集；无论我走到哪里，模式都是相同的。最后，我已经收集了足够令人不安的数据，与大缓冲区问题一致，并且我怀疑这个问题在所有技术和提供商中都是普遍存在的。
呼叫专家
我将数据包跟踪发布给了一组 TCP 专家：Dave Clark、Dave Reed、Scott Bradner、Greg Chesson、Van Jacobson 和 Vint Cerf。他们的反馈表明，极端缓冲创建了一个人为的大管道大小，并且数据包丢弃是根据尾部丢弃发生的——也就是说，当数据包到达满载缓冲区时，它会被丢弃。数据包的目的地不知道丢弃的数据包，直到整个膨胀的缓冲区被传输完毕，这可能需要非拥塞 RTT 的许多倍。TCP 期望及时收到数据包丢失的通知才能正确运行。对于如此大的缓冲区，TCP 的慢启动算法看不到任何丢包，因此大大高估了正确的管道大小，并且需要多次丢包，TCP 才能进入其拥塞避免阶段。
Jacobson 提供了数据的图表，在图 3 和图 4 中重现。窗口大小演变的形状是 TCP 的 CUBIC 实现的特征，11 这是 Linux 中的默认实现。CUBIC 的初始窗口增长类似于 Jacobson 的原始算法，但它在表面上稳定的管道大小估计值处“趋于平缓”一段时间。13 如果它没有检测到拥塞事件（即数据包丢失），那么它会快速增加窗口。在图 3 的跟踪中，大约 5 秒钟过去了，没有丢包，然后 TCP 增加了窗口，试图找到一个新的工作点；10 秒后，缓冲区已满，并且发生数据包丢失。（由于卸载引擎，RTT 来自它接收到的巨型帧的最后一个数据包。）请注意，RTT 迅速增加到大约 1.2 秒，并且主要保持在那里。3 秒的 RTT 峰值显示了当缓冲区变满时发生大量丢包的位置。接下来是窗口大小和 RTT 的下降。反过来，这导致 TCP 关闭窗口大小。窗口大小曲线表明，有时算法会在进入 CUBIC 的第二探测阶段之前获得丢包。
图 4 显示了根据 ACK 确定的有效吞吐量与时间的关系。最初短暂的近 10 Mbps 的时期是 Comcast 的 PowerBoost 功能的结果，随后是稳定的 2 Mbps，表明我获得了我期望的所有带宽。图 4b 显示了在每个窗口大小处看到的 RTT。较低的数据集显然来自 PowerBoost 阶段，而较高的数据集是随后的 2 Mbps 阶段。这些点准确地显示了图 1 中抽象显示的情况：延迟最初约为 10 毫秒；然后窗口大小增加，缓冲区填满，延迟（通过 RTT 测量）线性增加。
TCP 应该大致在竞争流之间共享瓶颈链路。bufferbloat 对 TCP 行为的影响在两个方面是微妙而深刻的
• 为了使 TCP 拥塞避免对使用该链路的人有用，导致拥塞的 TCP 连接必须对瓶颈链路的需求变化做出快速反应，但 TCP 的反应时间与过度缓冲量成二次方关系。过度缓冲 10 倍的链路不仅会施加 10 倍的延迟，而且还需要 100 倍的时间才能对拥塞做出反应。您的短时交互式 TCP 连接完全输给了任何已饱和您的链路的长期流。
• 长期流无法响应拥塞可能会导致竞争传输（您的或任何共享链路的人）完全饿死。与远程服务相比，本地服务可能会过度缓冲另一个 10 倍的因素。
结束宽带 Bufferbloat 的案例
在过去十年中积累的过度缓冲的证据最终足以推动系统研究。
2007 年对近 2,000 个通过欧洲和北美有线电视和 DSL 公司连接的主机进行的一项研究侧重于测量住宅“最后一英里”。结果表明，DSL 的上游队列经常超过 600 毫秒，而有线的上游队列通常超过 1 秒。4
Netalyzr），一种用于最后一英里或接入链路的测量工具，一直是揭露 bufferbloat 的关键。2010 年对 130,000 次测量会话进行的一项研究揭示了宽带边缘普遍存在的严重过度缓冲。7 （此处的结果经作者许可使用。）图 5 是带宽与推断的缓冲区容量的散点图，每个点代表一个 Netalyzr 测试会话。实线对角线表示 Netalyzr 缓冲区测试暴露的延迟，以秒为单位。测试显示所有宽带技术的下行链路和上行链路都存在过度延迟。由于 Netalyzr 的上限为 20 Mbps，并且将测试长度限制为 5 秒，因此情况显然比显示的更糟。
仅关注有线电视客户，同一项研究表明，该设备具有两种主要的缓冲区大小：128 KB 和 256 KB（作为参考，3 Mbps 的上行链路将需要 340 毫秒才能清空 128 KB 的缓冲区；而 1 Mbps 的上行链路将需要大约 1 秒）。Netalyzr 作者注意到，为各种运行接入速率（来自不同的服务级别和动态变化的速率）调整缓冲区大小存在困难。结案。
事出有因
在我家路由器上观察到 8 秒的延迟，促使我安装 OpenWrt 以进行进一步调查。我将路由器传输队列设置为零，但没有看到对延迟有任何影响。我笔记本电脑的 Wi-Fi 链路质量很差（导致带宽约为 1 Mbps），因此瓶颈链路是我的 Wi-Fi，将队列放在我的笔记本电脑上而不是路由器中——并且由于我的测试是上传，因此瓶颈在我的笔记本电脑中！我最终意识到 AQM 不仅仅适用于路由器；出站瓶颈很容易出现在主机的队列中，而 Wi-Fi 现在经常是瓶颈链路。
在我的笔记本电脑上操作 Linux 传输队列将延迟降低了约 80%，显然，其他地方发生了额外的缓冲。“智能”网络接口芯片现在通常支持大的（大约 256 个数据包）环形缓冲区，这些缓冲区已被调整为在所有操作系统上最大化高带宽路径上的吞吐量。在最低的 Wi-Fi 速率 1 Mbps 下，这可能会增加 3 秒的延迟。设备驱动程序环形缓冲区需要仔细管理，操作系统中的所有其他缓冲区也是如此。在 1 Mbps 下，一个 1,500 字节的数据包是 12 毫秒的延迟；你可以看到，缓冲量必须在两个数量级上非常快速地动态调整，以免牺牲带宽或延迟。
更糟糕的是，现代操作系统会响应观察到的延迟来调整套接字缓冲区大小；因此，操作系统和驱动程序 bufferbloat 可能会导致网络堆栈中更高级别的过度缓冲级联，从而导致应用程序中更高的延迟。
Bufferbloat 不仅仅存在于宽带中。2009 年，Dave Reed [互联网网络架构师，现就职于 SAP Labs] 报告了 3G 网络中的问题：他看到高 RTT 而没有数据包丢失，并正确诊断了原因。10 观察到非常高的延迟，以至于数据包可能会被传递，但延迟太久以至于很少有用；人们在数据包到达之前超时。9
宽带和无线 bufferbloat 也是许多酒店和会议场所看到的互联网性能不佳的大多数根本原因。
尽管边缘更容易测量，但有一些关于核心拥塞的报告。“RED 宣言”通常被忽视，因此互联网各处都隐藏着“暗”缓冲区。
通往地狱的道路是用良好的意图铺成的
在过去十年中，不仅没有部署 AQM，而且在 RED 宣言发布时未知的新的因素也加剧了满载缓冲区的问题。早期的互联网链路速度慢，并且共享这些链路的并发数据传输数量非常少。无线网络不存在。第一个住宅互联网系统通过低带宽链路将个人计算机连接到相对高速链路的互联网中。互联网已经发展成为带宽非常丰富的核心。如今，住宅和小型企业互联网连接越来越多地通过较小带宽的链路将客户的高带宽存根网络连接到这个核心。互联网边缘的瓶颈很容易在无线接入（当其带宽较低时）和提供商的上行链路之间移动，这两者都可能具有高度可变的带宽。
内存也变得便宜了；您无法购买小到足以用于边缘设备缓冲的 RAM 芯片，并且这些设备没有自我限制机制。商品网络设备现在跨越了许多向下兼容的世代：以太网已从 10 Mbps 发展到 10 Gbps；无线网络的工作速率从 1 Mbps 到 100 Mbps 或更高；有线电视从 10 Mbps 到即将到来的数百 Mbps。结果是单个缓冲区静态地调整大小以适应更大的带宽，但对于较低带宽的链路来说却太大了。例如，在当今许多 802.11 设备驱动程序中发现的 256 个数据包的缓冲量，在 1 Mbps 下转换为超过 3 秒，这可能是您在某些无线网络上拥有的所有带宽。使情况复杂化的是，关于缓冲量的建议受到早期互联网缓冲区不足问题的早期互联网问题的影响，因此在更大的缓冲区方面犯错，可能没有意识到 AQM 很少使用或不可用。
无线链路和网络越来越多地成为边缘接入的一部分，并且比宽带带宽更具可变性：移动设备几厘米可能会使速率改变一到两个数量级；并且由于无线是共享介质，这也影响了速率。由于带宽可以在短时间尺度上变化 100 倍，因此静态缓冲永远是不合适的。
许多加速 Web 访问的方法通过同时将大量数据包转储到这些链路上，导致瞬时接入链路膨胀。
重新审视带宽-延迟乘积
BDP 大小缓冲区的有效性受到质疑。正如在 2004 年 SIGCOMM 的一次演示中所指出的那样，BDP 不适用于高度多路复用的核心链路。1 维护 BDP 缓冲区的理由仍然适用于网络边缘，在网络边缘，单个流可能会拥塞链路。问题在于确定该 BDP。两个或更多数量级的带宽变化显然会对带宽造成严重破坏。与此同时，随着内容分发网络 (CDN) 和其他旨在将常见 RTT 降至 10-30 毫秒的服务的出现，100 毫秒的延迟假设已被削弱。因此，即使接入链路是恒定带宽，并且其缓冲区大小调整为 100 毫秒，它仍然可能过大 3-10 倍。
十多年来，TCP 调优一直专注于高 BDP 环境所需的改进，在这些环境中，需要大的数据包窗口才能实现良好的吞吐量。这些新算法本身并非邪恶，而是专注于有效地填充管道，但研究人员无意识地使用了高带宽和启用 AQM 的缓冲区的模型。当大的管道大小来自缓冲区而不是带宽时，算法会有效地填充这些缓冲区，从而导致大的延迟。控制缓冲区使一个 TCP 可以在任何地方良好地工作成为可能，这种解决方案优于尝试创建专门用于接入链路的 TCP 版本。
显然，在全球互联网中不可能存在“正确”的静态缓冲量：自适应 AQM 是任何设备（包括您的计算机或智能手机）中具有网络缓冲区的唯一可行的长期解决方案。
现代世界的 AQM
在 1998 年初，本文的第二作者发现了 RED 中的缺陷，并开始与 Jacobson 合作进行改进。当时，主要关注的是找到一种可以通过设置单个速率参数为任何链路配置的算法，以及开发一种可行的方法来跟踪持久队列，同时忽略短期突发14。随后的研究试图修复一些缺陷，但未能创建一种可以保持持久缓冲区短而不会过度丢包的 AQM。网络运营商面临的只是需要专家手动配置的算法，这些算法可能会损害他们，因此可以理解地不愿意启用和配置 AQM。
在随后的十年中，无线网络得到了广泛部署，为许多边缘链路带来了剧烈变化的带宽；有线电视互联网接入变得普遍；设备的接入带宽很容易变化两个数量级。现在很明显，任何不将数据离开缓冲区的速率作为输入的 AQM 算法都无法在当今高度可变的带宽环境中工作。显然，如果没有这样的算法，bufferbloat 将很难被击败。
令大多数人惊讶的是，AQM 对于宽带服务、家庭路由器甚至操作系统至关重要：它不仅仅适用于大型互联网路由器。
何时过度缓冲会造成伤害？
每当您饱和链路时，过度缓冲都会造成伤害；例如
• 通过互联网复制文件。
• 运行旧版本的 BitTorrent 或其他文件共享应用程序。
• 向奶奶发送/接收带有附件的电子邮件。
• 将视频上传到 YouTube。
• Web 浏览，可能会短暂地伤害您或其他人。
饱和的链路可能位于路径的任何位置，在任一方向或两个方向：最容易和最常见看到的是操作系统、无线链路和宽带服务。
为什么过度缓冲是一个问题？
过大的缓冲区会填满并导致延迟，破坏互联网的许多用途
• 股票交易员和游戏玩家不希望他们的竞争对手比他们有 1 毫秒的优势。
• 为了播放音乐，抖动（延迟变化）和延迟必须受到控制并保持在 100 毫秒以下。
• 为了让某物“感觉”附着在您的手上（完美的橡皮筋效果），延迟需要低于 30 毫秒范围；为了使键盘回显不被察觉，需要 50 毫秒。
• 光速延迟在长途网络上主导 VoIP（互联网协议语音），使得接入延迟对于将端到端延迟保持在 150 毫秒以下（长期电话指标）至关重要。
• 由 bufferbloat 引起的过度数据包丢失可能会导致 DNS（域名系统）查找失败。
• 诸如 ARP、DHCP、RA 和 ND 之类的基本网络协议都假定及时响应，并且在没有及时响应的情况下可能会失败。
• 当延迟从数百毫秒变为数秒时，Web 浏览变得痛苦。
许多服务提供商希望能够在他们的网络中为客户提供低延迟服务，无论是远程游戏、托管桌面系统还是备份。解决 bufferbloat 问题对于他们的成功部署是必要的。
冰山一角
操作系统和硬件有惊人数量的缓冲区隐藏位置。随着软件和硬件的更新，可能会发现更多的膨胀来源。特别是，随着旧的 TCP 被现代的 TCP 取代，目前不会膨胀其接入缓冲区的用户可能会突然遇到更长的延迟（例如，Windows XP 不启用 TCP 窗口缩放，因此它一次永远不会有超过 64 KB 的飞行数据）。
当前常用的网络性能测试未能同时测试延迟和带宽：链路必须饱和才能使排队延迟变得明显。可能需要 10 秒钟才能填满宽带设备、家庭路由器或操作系统的缓冲区，而大多数消费者宽带测试都不会测试那么长时间——因此错过了 bufferbloat。
过度的接入延迟往往被认为是网络拥塞。采用更大的骨干管道和按比例分配带宽使用量无法改善拥塞接入上行链路的用户或通过提供商边缘膨胀的缓冲区查看下载的用户的性能。
缓解措施
有一些希望的曙光。DOCSIS（有线电缆数据服务接口规范）在 2011 年春季进行了修改，允许有线电视运营商减少电缆调制解调器中的缓冲。这种缓解措施最早也要到 2012 年才会生效，并且需要电缆调制解调器固件升级或（最有可能的）调制解调器更换，以及积极主动和知识渊博的运营商。
Web 浏览器的正确解决方案可以改善接入链路行为。这些解决方案包括 HTTP/1.1 管道化和 Google 的 SPDY，这两者都可以实现更好的性能，减少传输的数据包和字节总数，并使 TCP 更好地发挥作用。
对于知识渊博的人来说，一些缓解措施简单而直接。例如，家庭路由器或您的笔记本电脑几乎从不在操作系统可能已调整到的高带宽环境中运行。调整操作系统和/或设备驱动程序中的缓冲可以比默认设置有重大改进。不幸的是，虽然这些调整在您的笔记本电脑中可能是可访问的，但在您的家庭路由器或手持设备中可能不可访问。
带宽整形可以用于防止瓶颈缓冲区填满，但会牺牲带宽。将图 6 中的 smokeping 结果与图 2 中的结果进行对比；近两个数量级的改进还不错。
最重要的是，静态的、未管理的缓冲区不适用于现代网络元素。网络架构师和设计师必须进行调整。为了解决这个问题，Nichols 和 Jacobson 已经恢复了对稳健、自适应 AQM 的研究。
成为解决方案的一部分
情况可能会在好转之前变得更糟，必须立即采取行动。潜在的解决方案在广泛部署之前必须经过严格的测试和分析；否则，现有问题可能会变得更糟。不幸的是，如今，非常缺乏早期互联网特征的性能监控、调优和改进方面的资金。
第一步是使问题显而易见。消费者测试很重要 [例如，Speedtest.net、SamKnows、M-Labs、Netalyzr]，但迫切需要更好的测试，这些测试可以指出正确的故障，并且每个人都可以使用。消费者测试通常会使带宽越大意味着“速度”越快的神话永存，而更好的营销指标至关重要。Stuart Cheshire 的著名“关键在于延迟，笨蛋”的咆哮应该被铭记于心。3
一个开源项目 CeroWrt 正在 bufferbloat.net 上使用 OpenWrt 进行，以探索潜在的解决方案，包括 AQM。请来帮忙。任何算法都需要进行广泛的测试才能获得信心。由于我们的操作系统是商品，并且在当今的家庭路由器中使用，因此家庭路由器 bufferbloat 是主机 bufferbloat 的直接结果。解决一个，您就解决了另一个。
不幸的是，由于缓冲区膨胀（bufferbloat）会误导 TCP 的拥塞避免算法，使其对有效管道容量的判断失准，因此，在没有有效主动队列管理（AQM）的现代网络中，可能会再次因饱和的边缘缓冲区造成秒级的包延迟，从而容易发生拥塞崩溃。据报告，大型网络中曾发生过拥塞崩溃，需要完全关闭并仔细重启整个网络才能恢复（暂时的？）稳定性。
我们仿佛乘坐在一架互联网飞机上，在这架飞机上，我们不断地更换机翼、发动机和机身，大部分驾驶舱仪表都被拆除，但只重新安装了少数新仪表。它以前坠毁过；还会再次坠毁吗？
致谢
我们要感谢 Dave Clark、Dave Reed、Vint Cerf、Van Jacobson、Vern Paxson、Nick Weaver、Scott Bradner、Rich Woundy、Greg Chesson、Dave Täht 以及数百位人士。
参考文献
1. Appenzeller, G., Keslassy, I., McKeown, N. 2004. 路由器缓冲区大小调整. SIGCOMM, Portland, OR, (八月).
2. Braden, R., et al., 1998. 关于互联网中队列管理和拥塞避免的建议, RFC2309 (四月).
3. Cheshire, S. 1996. 关键在于延迟，笨蛋! http://rescomp.stanford.edu/~cheshire/rants/Latency.html.
4. Dischinger, M., et al. 2007. 住宅宽带网络特性分析. 互联网测量会议 (IMC), San Diego, CA (10月24-27日).
5. Floyd, S., Jacobson, V. 1993. 用于拥塞避免的随机早期检测网关. IEEE/ Transactions on Networking (八月).
6. Jacobson, V. 1998. 关于使用 RED 进行队列管理和拥塞避免的说明. 在 NANOG (北美网络运营商组织) 13 的演讲; ftp://ftp.ee.lbl.gov/talks/vj-nanog-red.pdf.
7. Kreibich, C., et al. 2010. Netalyzr: 照亮边缘网络. 互联网测量会议 (IMC), Melbourne, Australia (11月1-3日).
8. Nagle, J. 1985. 关于具有无限存储的包交换机. 网络工作组 RFC 970 (十二月); http://www.ietf.org/rfc/rfc970.txt.
9. Reed, D. P. 2009. 拥塞崩溃定义; 线程位于 http://mailman.postel.org/pipermail/end2end-interest/2009-September/007769.html.
10. Reed, D.P. 2009. 这张图有什么问题; 线程位于 http://mailman.postel.org/pipermail/end2end-interest/2009-September/007742.html.
11. Rhee, I., Xu, L. 2008. CUBIC: 一种新的 TCP 友好型高速 TCP 变体. SIGOPS 42 (5).
12. Villamizar, C., Song, C. 1994. ANSNET 中的高性能 TCP. 计算机通信评论 24(5): 45-60.
13. V. Jacobson 和 M. Karels, 拥塞避免和控制, SIGCOMM '88 会议论文集, 1988 年 8 月
14. V. Jacobson, "关于使用 RED 进行队列管理和拥塞避免的说明", 在 NANOG 13 的演讲, ftp://ftp.ee.lbl.gov/talks/vj-nanog-red.pdf, 另请参阅 http://www.nanog.org/mtg-9806/agen0698.html
喜欢还是讨厌？请告诉我们
Jim Gettys 就职于美国阿尔卡特朗讯贝尔实验室，目前致力于解决缓冲区膨胀问题，因为对于沉浸式远程会议而言，一个正常工作的低延迟互联网是必需的。他曾担任“每个孩子一台笔记本电脑”项目的软件副总裁，并且是麻省理工学院 X 窗口系统的原始开发者之一。他曾在万维网联盟工作，并担任互联网工程任务组 HTTP/1.1 规范的编辑。
Kathleen Nichols 是 Pollere Inc. 的创始人兼首席技术官，这是一家为政府和商业网络提供咨询服务的公司。她在网络领域拥有 30 年的经验，曾在多家硅谷公司工作，并且是 Packet Design 的联合创始人。她目前的兴趣包括寻求主动队列管理的圣杯，并致力于为具有挑战性的环境提供差异化服务。
© 2011 1542-7730/11/1100 $10.00
最初发表于 Queue vol. 9, no. 11—
在 数字图书馆 中评论本文
更多相关文章
David Collier-Brown - 你根本不懂带宽
当您的员工或客户抱怨互联网性能糟糕时，带宽可能不是问题所在。一旦他们的带宽达到 50 到 100 Mbps 范围，问题就变成了延迟，即 ISP 的路由器处理其流量所需的时间。如果您是一家 ISP，并且所有客户都讨厌您，请振作起来。这现在是一个可以解决的问题，这要归功于一群敬业的人，他们找到了这个问题，解决了它，然后在家庭路由器中验证了他们的解决方案。
Geoffrey H. Cooper - 使用 FDO 和不受信任的安装程序模型的设备入职
设备的自动入职是处理日益增多的“边缘”和物联网 (IoT) 设备的重要技术。设备的入职与大多数设备管理功能不同，因为设备的信任从工厂和供应链转移到目标应用程序。为了通过自动入职加快流程，必须在设备中将供应链中的信任关系形式化，以允许自动化过渡。
Brian Eaton, Jeff Stewart, Jon Tedesco, N. Cihan Tas - 通过关键路径追踪实现分布式延迟分析
低延迟是许多 Google 应用（例如搜索）的重要特性，延迟分析工具在维持大规模低延迟方面发挥着关键作用。对于包含功能和数据不断演变的服务的复杂分布式系统，将整体延迟保持在最低水平是一项具有挑战性的任务。在大型、真实世界的分布式系统中，现有的工具（例如 RPC 遥测、CPU 分析和分布式追踪）对于理解整个系统的子组件很有价值，但在实践中不足以执行端到端延迟分析。
David Crawshaw - 一切 VPN 都焕然一新
VPN（虚拟专用网络）已经有 24 年的历史了。这个概念是为与我们今天所知的互联网截然不同的互联网而创建的。随着互联网的增长和变化，VPN 用户和应用程序也在增长和变化。在 2000 年代的互联网中，VPN 经历了一个尴尬的青春期，与其他广泛流行的抽象概念交互不良。在过去的十年中，互联网再次发生了变化，这个新的互联网为 VPN 提供了新的用途。一种全新的协议 WireGuard 的开发为构建这些新的 VPN 提供了技术基础。
© 保留所有权利。