LWN：QUIC扩展演进不够快！

关注了就能看到更多这么棒的文章哦～

Not so quickly extending QUIC

By Daroc Alden
March 6, 2024
ChatGLM translation
https://lwn.net/Articles/964377/

QUIC 是一种基于 UDP 的传输协议，构成了 HTTP/3 的基础。它最初是在 2012 年在 Google 开发的，并在 2021 年成为了 IETF 的标准。然而，协议的工作并没有随着它的标准化而停止。QUIC 工作组 发布了几个后续的标准。现在，它正致力于四个针对当前协议各种不足之处的 QUIC 扩展 — 尽管进展并不快。

QUIC 用作 TCP 和 TLS 的替代品，具有几个让人感兴趣的优点。它将建立连接和加密涉及到的握手合并，使得 QUIC 可以减少应用程序发送数据之前所需的往返次数 — 在某些情况下，甚至可以减少到零。它将加密与传输层结合起来，还允许 QUIC 将连接的细节对中间路由器（"middleboxes"）隐藏起来。QUIC 还支持在同一个底层连接上发送多个独立的流。这个功能对于像 web 服务器这样的应用程序非常有用，它们希望在同一连接上传输相关资源，而不需要因为一个流中的丢包而延迟其余的流 — 这是 TCP 的一个问题，称为 列头部阻塞（head-of-line blocking）。

负载均衡

QUIC 有一个有趣的功能，即 连接迁移（connection migration），它允许计算机在保持连接的同时无缝地更改 IP 地址。QUIC 数据包都包含一个连接标识符，即使数据包来自一个出乎预料的源地址，也可以根据这个连接标识符来确定该数据包属于哪个连接。这对于负载均衡器来说是一个挑战，因为它们通常根据源和目的地的 IP 地址和端口号来确定如何转发数据包。连接 ID 是数据包中少数未加密的组成部分之一 — 这样才能允许服务器告诉应该使用哪个加密密钥与数据包 — 因此，一个了解 QUIC 的负载均衡器可以使用连接标识符，但这与 QUIC 的另一个机制配合得不太好：连接 ID 旋转。

QUIC 允许服务器针对一个指定的连接向客户端提供一个连接 ID 池，以减少 "可链接性（linkability）"。如果一个 QUIC 连接长时间保持打开状态的情况下 — 例如它正在用于进行持续的电话通话 — 攻击者可以利用数据包的连接 ID 在用户迁移到不同的网络是对用户保持追踪。为了缓解这个问题，当一个客户端知道它即将更改网络（例如，因为它即将从蜂窝网络切换到 WiFi）时，可以在切换时开始使用连接 ID 池中的一个新的连接 ID。服务器知道它为客户端提供了哪些连接 ID，因此可以继续提供服务而不会中断。

任何未参与连接的人都看到源 IP 地址、端口号和连接 ID 同时发生变化，这使得很难将新的数据包流识别为属于同一连接。不幸的是，这包括位于服务器前端的那些负载均衡工具，它们无法正确判断从而将涉及到的数据包送给处理初始请求的同一服务器。

QUIC 工作组正在尝试通过 一个新标准 来增强负载均衡，该标准用于在连接 ID 中安全地编码（encoding）负载均衡信息。使用这个新标准的服务器通过将服务器 ID 和 加密随机数 结合起来创建连接 ID，然后使用与负载均衡器共享的密钥加密得到的字符串以生成连接 ID。这个密钥需要由配置系统的人员提供给服务器和负载均衡器。当负载均衡器接收到一个数据包时，它尝试对连接 ID 进行解密，然后将数据包转发到相关的服务器。该标准还包括版本更新或密钥迁移的相关规定。

在 2023 年 6 月，新标准之一的作者 Martin Duke 表示，该草案“基本上已经准备好了，但我们将其搁置，直到它在某个地方被部署为止”。自那时以来，有几处小的改动，但尚不清楚草案何时准备好迈出成为 IETF 标准的下一步，也就是提交给互联网工程指导小组 (IESG) 进行考虑。

多路径（Multipath）

在很多领域，TCP 仍然比 QUIC 有优势。其中之一就是 多路径支持。多路径 TCP 连接可以同时在不同网络路径上发送数据 — 例如，通过 WiFi 和蜂窝数据同时发送 — 从而提供比其中任何一条路径都更高的吞吐量。

正在进行的 QUIC 多路径扩展 将 QUIC 的连接迁移机制适配修改成允许多个路径同时使用。目前，当计算机开始在一个新路径上为现有连接发送数据包时，这被视为应该放弃先前路径的信号。如果连接设置了 enable_multipath 选项，那么在新路径上发送数据包的动作就会变成将该路径添加到连接中，并允许同时使用两个路径。

这里有一个复杂的问题，就是网络地址转换 (NAT) 重新绑定（rebinding）。QUIC 通过源和目的地的 IP 地址和端口来识别路径。不幸的是，这些参数对于给定的路径并不总是稳定的。一些路由器进行了 NAT 动作，允许多台计算机共享单个 IP 地址。当 TCP 连接通过这些路由器时，路由器可以观察到 TCP 会话的建立，并在连接期间将相同的外部端口映射到固定不变的内部 IP 地址。

这种方法对于 QUIC 来说不起作用，有两个原因。首先，QUIC 是一个相对较新的协议，许多现有的路由器代码都没有能对它进行处理。其次，QUIC 加密了关于连接的许多细节，以避免干扰和减少可链接性。这意味着 NAT 需要退回到用于其他 UDP 协议的相同的非连接感知的方法：在看到出站数据包时建立映射，然后在超时后解除这个映射关系。如果计算机负载过重，或者丢失了一个数据包、NAT 配置错误都可能会导致这个 timeout 值超期，哪怕当前的 QUIC 连接仍在正常进行活动。反过来说，这会导致 NAT 为下一个数据包选择一个不同的出站端口，使得路径看起来发生了变化。

在现有的 QUIC 中，服务器会认为这是一个连接迁移，并能正常继续工作。使用多路径扩展，服务器将改为将新路径添加到连接中，但仍然在旧路径上发送一些数据，这些数据将被 NAT 丢弃。为了克服这个问题，多路径 QUIC /要求/客户端在切换到新路径时使用新的连接 ID，如上所述。因此，如果服务器看到带有相同连接 ID 的路径更改，它可以识别出这个变改，将其作为 NAT 重新绑定事件，并停止向旧地址发送数据包。

另一个关注点是数据包编号和加密。QUIC 在加密数据包内容时，使用每个连接中数据包的包编号作为加密随机数。但是，当使用多个路径同时传输时，数据包编号变得更加复杂。如果在连接的所有路径中使用单一序列的数据包编号，那么很难判断数据包何时被丢弃，还是说数据包只是通过另一条路径发送，这使得计算不同路径的可靠性和拥塞程度变得困难。多路径扩展的作者为了简化实现，选择为连接中的每条路径使用独立的数据包编号集。这反过来又需要对数据包的加密方式进行更改，以防止 nonce 随机数被多次使用。

为了确保多路径 QUIC 的可行性，需要敲定许多其他考虑因素。该草案已经经历了多轮修订，并且工作组的工作仍在进行中。计划在即将于三月举行的 IETF 会议上更详细地讨论这个问题。

确认频率（Acknowledgment frequency）

:CUSTOM_ID: acknowledgment-frequency

由于 QUIC 被设计为 TCP 的替代品，它需要自己处理数据完整性和拥塞控制。为了确保所有发送的数据都被接收，QUIC 连接的两端都会发送确认消息。目前，这些消息是每当第二个数据包的时候会发送一次。这是在发送确认过快（浪费资源）和过慢（阻止拥塞控制算法及时响应网络变化）之间的折中。

不幸的是，并非每个 QUIC 连接都有等同的需求。一些非对称互联网连接在发送数据包时接收带宽会减少，使得确认变得更加昂贵。一些设备在电池功率或传输频率上有限制。一些设备通过可靠的路径连接，这些路径没有明显的抖动或损失。所有这些情况下的设备都会从较少的发送确认中受益。

不幸的是，单方面发送较少的确认是不可行的，因为连接另一端的计算机会将其解释为数据应该被重新传输，或者至少认为路径的往返时间比实际情况要差得多。然而，如果连接的另一参与者预期这样做，那么这里就可以有效地省掉这个确认。

确认频率草案扩展允许连接中的参与者请求更改确认机制。使用该扩展的系统可以设置在发送确认之前可以发生的最大数据包数量或时间量。

该扩展还添加了一个 IMMEDIATE_ACK 消息，以显式请求连接的另一端在收到消息后发送确认。文档的大部分内容详细介绍了这个实现里何时希望使用 IMMEDIATE_ACK 消息，以确保延迟确认不会导致速度不必要地降低。

该扩展理论上已经准备好进入标准化的下一步，因为其最后的征求意见期在 2023 年 10 月结束，没有引发另一轮修订。然而，扩展的作者并没有在 IETF 标准化过程中向前迈进，这促使工作组成员 Gorry Fairhurst 在 2 月中旬的邮件列表上询问“这个文档是完成了还是在等待应对 issue 的行动？”，但至今没有回应。

部分交付（partial delivery）

QUIC 允许在同一个连接上多路复用的不同的流各自独立出现失败情况 — 例如，在视频会议中，一个参与者遇到问题，而其他参与者则不会出错。当只有一个流遇到问题时，服务器可以发送一个 RESET_STREAM 消息，通知客户端某个特定的流受到了影响。当这种情况发生时，QUIC 规定客户端应该丢弃迄今为止收到的属于这个流的所有数据，服务器不应该响应重新传输该数据的要求。

这对于像 WebTransport 草案标准 这样的协议来说就是一个问题了，它们需要在这个流上确保可靠地接收一些初始数据，但仍然希望流可以被重置。QUIC 工作组正在通过 一个 QUIC 扩展草案 来解决这个用例，该草案定义了一个 RESET_STREAM_AT 消息。这将允许服务器在重置流的同时，指定在特定偏移量之前的数据仍然应该被保留或在传输中丢失时重新请求。

该草案在最后一次征求意见期于 2 月 8 日结束后，几乎已经准备好成为发布标准。IETF 在将标准提交给 IESG 考虑出版之前，规定了一些额外的流程，因此它可能还需要一段时间才能被采用。

结论

这些对 QUIC 的潜在改进承诺使得该协议更加有用和高效，特别是对于具有非对称或间歇性可用链接的设备来说。不幸的是，这些改进的进展并没有特别快。长期贡献者 Christian Huitema 对工作组进展表示沮丧：

在过去，IETF 倾向于找到一个足够好的解决方案，然后发布它，积累经验，稍后再修订标准以填补其中的问题。如果我们遵循这个过程，我们可能去年或前年就已经发布了 QUIC 多路径 RFC — 第 6 草案绝对是足够好的，之前的草案可能也不错。但我们决定在批准草案之前讨论所有细节。结果可能会更好，尽管更早积累经验也会帮助提高质量。无论如何，这个过程都不算快。

IETF 最终确定新标准还需要多长时间还不确定。同时，QUIC 的采用正在增长，在每个主要浏览器中都以某种形式提供了支持。QUIC 设计者关注的一个关键问题是避免协议僵化，但如果进一步改进协议的过程受到缓慢的标准制定过程的阻碍，那么 QUIC 反对僵化的设计的这个选择将无用武之地。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～