消除网络延迟：通过公平排队与主动队列管理优化互联网性能

GOTO Conferences

总结：

本视频中，Dave Taht深入探讨了困扰互联网多年的“缓冲区膨胀”（bufferbloat）问题，该问题导致在大量上传/下载或视频会议时出现严重的网络延迟和卡顿。他指出，尽管带宽不断增加，但高延迟仍然是影响用户体验的关键因素。

主要解决办法包括：

• 公平排队 (Fair Queuing) 和 fq_codel 算法: 通过为不同类型的流量（如Netflix流媒体和VoIP通话）创建独立的队列并进行智能调度，确保低速率、实时流量的优先传输，从而消除TCP锯齿效应。
• 主动队列管理 (AQM): 如fq_codel和CAKE算法，通过智能丢弃或标记数据包，及时通知发送方减速，将排队延迟控制在5-10毫秒的理想范围。
• 优化路由器固件: 鼓励用户刷新路由器为OpenWrt等支持SQM（智能队列管理）的固件，以改善家庭网络的延迟表现。

通过这些创新，Starlink等ISP已成功将网络延迟降至稳定的20毫秒以内，极大地提升了网络性能，为实时应用（如语音、视频会议、游戏乃至元宇宙）提供了更流畅的体验。

引言与个人愿景 [00:00]

Dave Taht自20世纪80年代初便投身互联网领域，其核心使命是消除不必要的网络延迟，让互联网更快。他的终极梦想是能像在家中插上吉他与远方的鼓手实时合奏那样，实现超低延迟的互动。他与Jim Gettys等“互联网元老”共同努力了超过15年，旨在从互联网中剔除冗余的延迟和抖动。

缓冲区膨胀（Bufferbloat）的挑战 [03:03]

缓冲区膨胀是导致互联网体验不佳的罪魁祸首。当用户进行大文件上传或下载时，整个网络会“冻结”，视频会议变得卡顿。

• FCC研究报告: 联邦通信委员会（FCC）的2023年延迟测量报告显示，尽管空闲延迟（Idle Latency）对语音和视频应用来说尚可接受，但在95%或99%负载下，延迟会急剧膨胀。
  • DSL在95%负载下的延迟从55毫秒飙升至790毫秒，99%负载下甚至达到近2秒，最大值达3秒。
  • 有线电视和Starlink等其他技术也存在类似问题。

    

• 简单测试: 用户可以通过访问 waveform.com/tools/bufferbloat 进行简单测试，检查自家网络是否存在缓冲区膨胀。
• 最初的解决方案: 早期，修复缓冲区膨胀的建议通常是购买支持“智能队列管理”（SQM）功能的路由器，如采用 fq_codel (RFC 8290) 或 CAKE 算法的设备。但这并非最终目标，理想情况是ISP（互联网服务提供商）自行部署这些技术。
• LibreQoS公司: Dave Taht目前所在的公司LibreQoS致力于将这些算法应用于中间盒子（Middlebox），将网络延迟从几秒缩短到稳定的30-35毫秒。
• Starlink的案例: Starlink工程团队采纳了这些建议，将整个网络的目标延迟设定在稳定的20毫秒，显著改善了用户体验。Dave Taht希望所有ISP都能效仿，让语音、视频会议、游戏、AR/VR等实时应用能同时在互联网上顺畅运行。

什么是拥塞控制？ [04:53]

• 历史背景: 互联网在1986年曾因缺乏拥塞控制而崩溃（归功于Van Jacobson的贡献）。
• 基本原理: 拥塞控制算法旨在管理多源多流的数据传输，确保网络在穿越瓶颈链路时公平共享带宽，并调整数据包的发送速率以适应输出速率。
• 带宽与延迟的关系: 网页加载时间（Web PLT）主要取决于往返时间（RTT），而非纯粹的带宽。
  • 一个10Mbps、10毫秒延迟的连接，其性能将远超一个10Gbps、100毫秒延迟的连接。
  • 内容分发网络（CDN）的出现正是为了将数据更靠近用户，减少延迟。带宽本身在很大程度上已不再是瓶颈。

    

• 缓冲区膨胀的“伪解决方案”: 为规避缓冲区膨胀，互联网流量逐渐演变为短时突发传输和速率受限的流媒体（如Netflix）。传统需要大文件上传/下载或VoIP、游戏等应用的流量反而受到了影响。

拥塞控制演示 [06:52]

Dave Taht邀请观众扮演“数据包”，通过生动的互动演示来解释TCP连接、拥塞控制和缓冲区膨胀的运作机制。

• 数据传输概念:
  • TCP连接与三向握手: SYN (请求连接) -> SYN-ACK (确认并响应) -> ACK (确认连接建立)。一旦连接建立，便可以发送数据。
  • 填充“管道”: 发送方首先发送一批数据包，以“填充管道”（fill the pipe），即利用光速在链路中传输数据。

    

  • 初始窗口（Initial Window, IW）: Linux的初始窗口为10个数据包（IW10），其他操作系统通常为4个。
• TCP的慢启动与拥塞避免算法 [14:22]:
  • 数据发送量呈指数增长，直到发生丢包。
  • 一旦丢包，TCP会减半发送速率，然后线性增加（拥塞避免）。

    

• TCP Reno/Cubic的“锯齿波”行为 [15:24]:
  • 这种先加速后减速，再逐步加速的行为被称为TCP锯齿波（TCP Sawtooth）。
  • 这是互联网为了保持稳定性而设计的一种协议行为，而非物理限制。它能在跨越巨大距离（如月球）和处理数万亿并发连接时保持稳定。

    

• 发送和接收窗口 [17:23]:
  • 当接收方的缓冲区过长，导致发送方无法及时收到确认信号时，发送方会继续发送数据，进一步加剧缓冲区拥塞，最终导致大量丢包。
  • 这种长时间的延迟会导致接收方无法及时处理数据，需要重新传输，进一步恶化延迟问题。
• 丢包和标记的作用 [18:57]:
  • 及时丢包或标记数据包对于网络的正常运行至关重要。
  • 缓冲区膨胀导致丢包信号延迟，从而使TCP协议无法及时响应，进一步延长延迟。
  • 在缓冲区膨胀项目启动时，卫星网络上的缓冲时间最长可达864秒，蜂窝网络也常有超过40秒的延迟。
• ACK时钟（Ack Clocking） [19:54]:
  • 互联网上没有流量控制信号直接告诉发送方减速。
  • TCP依赖于接收方发送的ACK数据包来“计时”，决定何时发送下一个数据块。
  • 如果ACK数据包在回程路径上遇到拥塞并被延迟，发送方将无法及时获得发送更多数据的信号，导致整个数据流停滞。因此，上行链路和下行链路的拥塞都会影响网络性能。

解决锯齿波问题：公平排队与主动队列管理 [20:48]

• 抖动缓冲区（Jitter Buffer）: 为了应对TCP锯齿波带来的延迟波动，视频会议等应用需要一个抖动缓冲区，其大小应略大于锯齿波的高度（例如，理想情况下锯齿波高度为90毫秒，视频会议工具通常有数百毫秒）。

  

• 队列长度的问题 [25:46]:
  • 理想的队列长度应小于“两个工作单元”，平均利用率小于等于1。
  • 然而，许多应用程序和网络设备中存在无限长或过大的队列，导致不必要的延迟。
  • 长队列意味着数据包需要等待更长时间才能被处理，从而引入延迟。
• 公平排队（Fair Queuing） [23:09]:
  • 这是一种1989年提出的老技术，但从未成为互联网的默认设置。
  • 它通过为每个流量流（如Netflix视频流、VoIP语音包）创建独立的队列，并轮流处理这些队列中的数据包，从而实现不同流量之间的公平性。
  • 这可以消除TCP锯齿波对实时应用的影响，因为小而频繁的VoIP数据包不会被大的Netflix数据块阻塞。

    

• fq_codel (RFC 8290) [28:40]:
  • 是公平排队的一种改进，称为“流量排队”（Flow Queuing）算法。
  • 它已在Linux、FreeBSD以及市场上许多家庭路由器（通过OpenWrt和SQM）中广泛实现。
  • 该算法能够自动适应线路速率，并通过优先处理空队列中的数据包，确保实时、低速率流量的优先传输。
  • 目前，几乎所有Apple和Linux设备都运行fq_codel。

    

• 主动队列管理（Active Queue Management, AQM） [25:53]:
  • AQM算法（如codel、pie、fq_codel、fq_pie、sch_cake）通过测量数据包在队列中停留的时间或队列占用率，智能地丢弃或标记数据包，以促使发送方减速，从而将排队延迟控制在相对固定的5-10毫秒。
  • Uber曾使用codel算法来决定何时丢弃高峰期的请求。

    

• ECN（Explicit Congestion Notification，显式拥塞通知）: 一种允许在不丢包的情况下进行拥塞控制的机制。Comcast的L4S项目利用ECN为高优先级、低延迟队列服务。

实际应用与建议 [29:29]

• DSL与光纤:
  • DSL因其糟糕的排队延迟而声名狼藉，但通过刷新路由器固件（如OpenWrt或DD-WRT），其性能可以显著改善。
  • 即使是光纤网络，如Lumen的100Mbps服务，也可能出现超过3秒的缓冲区膨胀。
  • CAKE算法能将光纤网络的固有延迟（例如60毫秒）降至0-3-4毫秒。

    

• Wi-Fi网络:
  • 过去，在拥塞环境下，Wi-Fi延迟可从10毫秒飙升至1400毫秒。
  • 通过在较新的硬件和芯片组（包括Eero）中部署fq_codel等算法，这个问题已得到解决，使Wi-Fi在拥塞下依然能保持较低延迟（例如40毫秒）。
  • Wi-Fi性能异常：信号强度随距离衰减，为了确保远距离传输，传统Wi-Fi会引入大量缓冲，导致近距离用户延迟增加。fq_codel解决了这一问题。
• 推荐:
  • 部署支持fq_codel和公平排队机制的解决方案。
  • 在家中和小型办公室路由器上应用SQM。
  • 使用OpenWrt等固件更新路由器。
  • 关注应用程序中的往返时间（RTT）。
  • 开发者应优先使用BBR等更先进的拥塞控制算法。
• 成果: Dave Taht所在的公司LibreQoS管理的400万台设备，其最小延迟为20-24毫秒，高负载下最高延迟仅38毫秒，这为元宇宙等未来实时应用提供了可能性。

问答环节 [31:45]

• UDP是什么？:
  • UDP（用户数据报协议）是一种无连接的传输协议，专为实时应用设计。它不保证数据包的到达顺序、可靠性或避免丢包。
  • 在拥塞控制中，如果UDP流量没有额外的管理，它会直接加剧丢包和延迟。
  • 然而，对于VoIP等应用，统计性丢包（例如，5个数据包中丢2个）可能比延迟更可接受。
• 为什么无法在路由器上直接获取这些算法？:
  • 问题不在于技术上无法实现，而是ISP和硬件制造商的商业策略。他们倾向于购买最便宜的设备并长期使用，而非更新固件以支持最新算法。
  • 用户可以通过刷入OpenWrt、DD-WRT等第三方固件来获得SQM、IPv6支持、广告拦截等额外功能，并提高安全性。
• Wi-Fi信号丢失对拥塞控制的影响:
  • Wi-Fi信号强度遵循反平方定律，距离越远，带宽越低。为了保证连接，Wi-Fi通常会引入大量缓冲。
  • fq_codel算法（也称为Wi-Fi性能异常解决方案）解决了这一问题，显著提升了拥塞下的Wi-Fi性能，将延迟从数百毫秒降低到几十毫秒。
• ISP骨干网过载问题是否已解决？:
  • 由于CDN的广泛部署，互联网已基本成为一个“单跳网络”，大多数内容距离用户仅一跳之遥，骨干网的带宽充足。
  • 然而，交互式流量（如视频、语音和游戏）仍然受到影响，因为云服务商的骨干路由器常常配置了过大的默认缓冲区（例如400毫秒），导致不必要的延迟。
• fq_codel与硬件卸载:
  • fq_codel在某些设备上已实现硬件卸载，但其硬件实现难度相对较高。
  • Pi算法（Comcast的L4S项目采用）更容易移植到硬件，未来有望看到更多硬件直接支持AQM技术。