慢速互联网的隐藏原因以及如何解决它

2010年，目前在Google工作的一位资深电脑程序员Jim Gettys在家上向他的工作服务器上传一个大文件。他的孩子进入了他的研究，说：“爸爸，互联网今天很慢。”想知道他的上传活动如何影响他的孩子的下载，他开始调查。

通过在互联网连接上进行乒乓和各种负荷等级，他发现延迟通常比应该预期的4至10倍。他称之为“bufferbloat”的现象。他的结论是，关键数据包被困在过大的缓冲区中。

从Gettys开始宣传并开始宣传，思科和谷歌等公司的研究人员已经调查，测试和写作Bufferbloat的研究。我们还进行了自己的简单测试。bufferbloat是真实的。不完全理解的是它对​​正常互联网流量流动的影响。

那么，谁受到这种现象的影响最大？

任何正在积极浏览或使用搜索引擎的人。此外，任何使用像语音或视频等实时应用的人。一个例子是员工，在家，在酒店的公路上或在Wi-Fi热点。我们的研究表明，酒店和Wi-Fi咖啡馆容易出现非常糟糕的Bufferbloat问题。

什么样的交通受到影响？

流动在相反方向上具有高带宽利用率的链路流动将恶化。使用诸如VoIP，DNS和ARP等小型数据包的应用也可能受到影响。对VoIP的影响将增加延迟和抖动。DNS查询可以在正常响应时间的两到八倍中返回。

如何在这么长时间内影响互联网的操作？

有三个主要原因。首先，该问题与TCP协议如何运行以及网络缓冲区的管理方式密切相关。这些都没有广泛地理解。其次，存在广泛的信念，即互联网中的数据包总是一件坏事。事实是，丢弃数据包对TCP的适当操作绝对必不可少。第三，存在广泛的定罪，即消除性能几乎任何恶化的方式是添加带宽。

那么，Bufferbloof究竟是什么？

在互联网中的尝试减少数据包丢失，网络运营商，开发人员和工程师多次增加了网络缓冲区的大小。这增加了延迟，但对吞吐量没有效果。因此，诸如VoIP，DNS和TCP'Acks中的临界小型数据包可以被困在从文件传输和其他批量传输的更大数据包之后的缓冲区中，例如自适应比特率视频。

有一个与缓冲管理相关的感知问题。测试，白皮书和甚至导师经常将缓冲区描述为内存的小块。更常见的是，缓冲区可以在任何瞬间持有数百个甚至数千个数据包。

而且，它们不仅仅是在网络设备中。它们还在结束站，网卡驱动程序和端台之间的路径中的每个网关的协议栈中。

Bufferbloat对TCP操作的影响是什么？

我们的绝大多数网络流量使用TCP作为传输协议。了解TCP如何操作揭示为什么BufferBloat是一个问题。当建立TCP连接时，存在三通握手，其中发送和接收TCP实体协商交换的参数，包括初始序列号。

假设已被要求提供FTP服务器传输大文件。TCP通常通过发送四个部分并等待其交付确认来开始转移。通常的确认策略是在每个其他接收的段之后发送“ACK”。

当四个段是“ackEd”时，接收器通过发送八个片段来增加发送速率并等待确认。在确认这些段后，发送率增加到16等。

这种递送阶段被称为缓慢的开始。这个想法是将链接与数据包饱和。然而，在称为慢速启动阈值的级别，发送方通过在每轮中的时间添加一个段而不是加倍速率来增加速率。

然而，由于缓冲区将溢出，将会有一个关键点，因为缓冲区将溢出。将删除一个或多个数据包。

当发件人检测到发生这种情况时，它通常将其发送速率缩短为一半并重新启动慢启动。最终，TCP速率将适应正在使用的电路的容量。这种组合的步骤称为TCP拥塞控制算法。

那么，Bufferbloat如何干扰？

让我们考虑高速链路与低速链路之间的连接。这是缓冲区被认为是关键的情况。例如，假设我们将一个1Gbps与电缆或DSL调制解调器类似的住宅网关。此外，假设调制解调器连接到ISP连接，以向下提供10Mbps和2Mbps。

FTP服务器将使缓冲区更快地进入快速连接，而不是出口速率进入较慢的链路。这是ACKS返回的速率最终确定发送者可以传输的速率。

但是，如果该缓冲区很大，则可能发生两件事。首先，如果缓冲区填充，则删除最后一个数据包。这被称为尾滴。通知发件人此丢弃的ACK将不会发送，直到下一个数据包（丢弃之后）到达并被声明无序。

它可以通过大缓冲区需要相当长的时间。我们使用自适应比特率视频执行的一些实验显示，在发送站重新发送丢弃的段之前，可以在近200个段中传送。

此外，如果有多个流入它，则队列可能会发展到站立队列中。也就是说，它可能达到稳定状态，其中队列中存在固定或几乎固定数量的分组。如果此数量不足以冻结缓冲区，则不会删除数据包，并击败TCP拥塞控制。但是，缓冲区所有用户的延迟都增加了。

管理缓冲区

有一段时间，有意识到应该管理网络队列。要为某些流量添加优先级，可以设置IP层DiffServ位以实现策略，该策略优先于某些类型的流量，例如网络控制或VoIP。它们通过将这些优先级的流量类型分成单独的队列来完成此操作。

但是，这不会消除bufferbloat。一些包含非优先级流量的队列继续存在太大问题。这些通常包含许多大型TCP段。因此，我们仍然存在对TCP拥堵机制的负面影响的问题。

已经引入的若干有效队列管理（AQM）技术包括红色（随机早期丢弃）和WRED（加权红色）。这些旨在在缓冲区达到临界水平时丢弃数据包，但不一定满。但这些技术缺陷，并配置红色被证明是困难的。因此，红色和卷并未被广泛实施。所需要的是一种自动，永不调整方法。

2012年，Kathie Nichols和Van Jacobsen开始推广一种称为Codel或控制队列延迟的技术。此方法通过跟踪数据包在队列中的时间来管理队列，因为队列中的占用时间真的是至关重要的问题。

有两个关键参数，间隔和阈值。如果一个间隔的数据包的数据包比目标长时间，则随机丢弃数据包。请注意，此技术不依赖于队列的大小。也不是尾滴。

测试程序显示普遍更好的延迟行为，而不是红色和更好的结果。对于无线访问链接，这尤其如此。此外，该技术承诺很容易嵌入硬件。

缓解缓冲区的下一个建议来自Dave Taht，Eric Dumazet，Jim Gettys和其他一些人。称为FQ-Codel，旨在通过队列对各种流程提供更均匀的影响。即使是Kathie Nichols和Van Jacobson也倡导使用FQ-Codel。

此方法默认将队列分隔为1024个子队列。然后它随机将每个新流程分配给单独的队列。在每个子队列中，应用Codel以帮助TCP拥塞控制。DE-QUEUE策略基于DRR（赤字循环）。

Codel和FQ-Codel做什么？

首先，他们确保TCP拥塞控制功能如设计。其次，通过将数据包混合在队列中，诸如DNS响应和TCP ACK的小型关键数据包不会被困在大队列中。换句话说，它使得大量数据包和小包更公平地进行治疗。相当大的研究表明使用FQ-Codel的益处。事实上，它在Linux的最新分布中。

我们从哪里开始？

不幸的是，对缓冲器的意识仍然不普遍。我们需要更多网络运营商和用户来运行易用的测试，如ICSI Netylyzr和www.dslreports / speedtest /的测试。

然后，如果检测到一个重要的BufferbLoat问题，则您有几个备选方案：

1.使用包含FQ-Codel的Linux的新分发将您的访问硬件更改为设备。确保打开功能。

2.在计算机和具有FQ-Codel功能的网关/路由器之间放置一个设备。这将限制路由器的大缓冲区的使用。

3.如果所有其他人失败，请应用速率限制以上行链路和下载链接到额定容量下的内容。这将有助于消除大型站立缓冲区。在轻量负荷下，它将花费您在吞吐量下降。但是，它应该大大改善DNS，ARP和TCP ancknowment等临界流。

有几个伴随着缓解缓冲区的供应商。思科与康卡斯特合作，已接受队列管理技术调用饼（比例积分控制器增强型），主要由Cisco卓越的研究工程师荣泛开发。

时间华纳电缆似乎很易于主题，并准备采取措施缓解缓冲器。ActionteC是Verizon和Centurylink的住宅网关的主要供应商，研究了Bufferbloat。他们说他们正在采取措施减轻其影响。Ruckess Wireless是瞻博网络的合作伙伴，致力于继续改进Access Link缓冲问题。

但是，我们谈到的一些供应商似乎没有意识到了Bufferbloat。其他人像Cox电缆一样，这一问题取决于硬件和硅的制造商。不幸的是，我们联系的大多数主要网络测试设备制造商似乎不知道这个问题。

这种情况需要改变。重要的是要理解整体吞吐量不是最重要的不利因素，特别是在浏览等活动中。最重要的因素是延迟。

HTTP Get命令的响应通常是短暂的突发文件传输，其中慢速启动过程几乎没有开始，直到它终止。因此，会议建立和终止的延迟成为对会话持续时间的重大影响。此外，对流行的网站的典型访问可能经常有10到25个DNS查询/响应交换，在get命令之前。如果由于Bufferbloof由于BufferBloof由于3倍，您肯定会注意到它。

我们强烈建议网络运营商研究了BufferBloat主题已经提供了大量的研究。然后，在关键的网络连接（如无线和移动接入点），我们需要测试BufferBloat。您可能希望从这些测试中拥有数据来与您的服务提供商或无线接入点供应商交谈。

HippeNsteel是一名教授，顾问和作家，具有40多年的高等教育经验。他可以在[email protected]达到他。

这个故事，“互联网的隐藏原因以及如何解决它”最初由网络世界发布。