博客 | 首席技术官办公室

QUIC 将吞噬互联网

F5 缩略图
F5
2021 年 2 月 22 日发布


QUIC（不是首字母缩略词）是一种独特的东西，但最好将其视为一种新的传输协议，它解决了互联网中许多长期存在的问题，并捕获了 TCP、TLS、SCTP、IPSec 和 HTTP/2 提供的大部分价值。 HTTP 有一个新的版本，称为 HTTP/3，它设计用于通过 UDP/QUIC 而不是 TCP/TLS 工作。

谷歌早在 2014 年就在其浏览器和网络服务器中部署了 HTTP over QUIC 的早期版本。 IETF 标准化进程于 2016 年开始。 经过大量的演变和数据收集，将在 2021 年初产生第一批 RFC。 包括 F5 在内的几家大型互联网公司要么已经推出了使用 QUIC 的产品，要么在其基础设施中部署了 QUIC。 截至 2020 年 10 月， Facebook 75% 的流量通过 HTTP/3 和 QUIC 传输。

这些早期的部署以及 IETF 对 QUIC 之上新标准的热情表明，这将成为互联网上尖端应用的重要且可能占主导地位的基础。

技术概述——为什么选择 QUIC？

快速层
图 1. QUIC 借鉴了许多传统协议的功能。

图 1 让读者了解 QUIC 的作用。 然而，这种功能分解并不能解释为什么工业界的早期采用者转向 QUIC：

  1. 降低延迟。 类似 Web 的数据传输主要受三层握手的延迟影响：一层用于 TCP，至少一层用于 TLS，一层用于 HTTP 请求/响应。 TCP/TLS 的最新发展原则上可以将其压缩为一次往返，尽管在实践中这很少奏效。 QUIC 将把这个往返减少到一次，最多两次。

  2. 流。 与 HTTP/2 一样，QUIC 为应用提供多个字节流，以增加通过同一连接传输的概念上不同的数据的独立性。 在运输过程中这样做只会增加这种独立性。 Streams 自然满足了流视频传输的需求，主要的互联网内容提供商也正在顺利通过 QUIC 传输流。

  3. 更好的损失响应。 QUIC 的设计提高了 TCP 检测和恢复数据包丢失的能力。 此外，通过提供多路复用流而不是单个有序字节流，包含一个对象的数据包的丢失不会延迟不同对象的传送。

  4. 多宿主。 与 MPTCP 和 SCTP 非常相似，QUIC 连接可以与每个端点的多个 IP 地址相关联。 与这些协议不同，QUIC 很有可能在丢弃不熟悉的协议号和 TCP 报头选项的互联网上成功传播。

  5. 安全和隐私。 QUIC 在传输层应用加密，而不是在其之上。 整个 UDP 有效负载都经过验证，可防止中介进行任何透明修改，并且几乎所有传输信息都经过加密。 此事的影响本身就是一份白皮书。 可以说，这大大提高了隐私属性，并且实际上消除了 TCP 提供的攻击面。 与 IPSec 不同的是，它目前在网络规模上运行。 它还会导致：

  6. 可扩展性。 TCP 很难改变，因为它的创建者留下的扩展空间有限，并且中间件强制执行旧的 TCP 行为。 QUIC 将显式版本控制与中间件的不透明性相结合，以允许在传输方面进一步创新。 这将支持未来的用例，并最终提高与 TCP 相比的批量传输能力。

除了惯性之外，有些应用可能不会迁移到 QUIC 的原因还有两个：

  • 复杂性：只需要单个字节流并且不关心加密的应用不需要与这些功能相关的额外工作量。

  • 中间件： 相当一部分互联网路径不允许 UDP。 HTTP/3 已设计了这些路径的 TCP 回退，但最终对主要网站（谷歌、Facebook 等）的性能影响可能会导致负责的设备过时，除非民族国家希望监控另有规定。

它正在吞噬互联网

Google Chrome、Google App Clients 和 Facebook 的应用程序已经支持 HTTP/3。 Safari、Edge 和 Firefox 实现支持它，但（目前）默认处于关闭状态。

在服务器端，Google、微软、Facebook、苹果、Cloudflare、LiteSpeed、F5 BIG-IP、NGINX、Fastly 和 Akamai 的实施和/或部署已经发布或即将发布。 最近，一家领先的欧洲 ISP 报告称，其 20% 的数据包是 QUIC 。2021 年 2 月，约有5% 的网站使用 HTTP/3 ，但我们预计，一旦 RFC 发布，这一数字将会增长。

此外，标准组织正在做大量工作，使 QUIC 超越 HTTP 用例。 IETF 的草案标准提议通过 QUIC 实现 DNS、Websockets、SIP 以及 TCP 和 UDP 隧道。QUIC 完全融入 5G 架构有点太晚了，但 QUIC 对服务提供商的兴趣和适用性是显而易见的。 最后，HTTP/2 和 HTTP/3 的上层 API 非常相似，因此在 HTTP/2 上运行的任何协议或应用都可以轻松移植到 HTTP/3 和 QUIC 而不是 TCP 上运行。

威胁与机遇

QUIC 和 HTTP/3 将塑造各种各样的市场。 高性能网站和应用 一旦生态系统完全成熟，我们就有强烈的动机切换到 HTTP/3 和 QUIC，并且我们预计我们的客户对 HTTP/3 的支持需求将以与部署 HTTP/2 类似的速度进行。

在以 QUIC 为基础的互联网中，安全产品需要进行根本性的重新评估。 如果无法访问 TLS 会话密钥，数据包检查就会变得更加困难，而这通常只有拥有域的私钥才有可能。 这提高了与应用程序级代理集成的安全解决方案的价值，而不是一系列单一功能的设备。

此外，传统的 DDoS 防御也需要调整。 不仅数据包识别和检查变得更加困难，而且 TCP syncookies 已经被“重试数据包”取代，而“重试数据包”不容易被中介机构欺骗。 有标准的协调方法可以让服务器卸载重试数据包的生成和验证，但同样，这需要开发工作。

传统的第 4 层负载平衡将破坏 QUIC 地址迁移，因为它无法将改变其地址或端口的流关联到自身，然后路由到同一服务器。 再次，有标准来协调和克服这个问题，但这需要投资。

IETF 的MASQUE 工作组正在研究通过 QUIC 实现的通用流量隧道，这可能是下一代 VPN 方案的基础。 与 TCP 上的 TLS 相比，QUIC 在多路复用任意流方面的性能要好得多。 这些隧道还可以用网络规模加密替代 IPSec 隧道，改善某些服务提供商的使用案例，甚至提供一种在客户明确同意的情况下优化移动链接类型的 QUIC 连接的方法。

QUIC 将需要新的网络测量和分析工具。 可以测量 TCP 延迟和丢失的系统无法使用这些信号，但网络存在明确的延迟信号，并且其他信号可能正在传输中。 由于更多的传输信息隐藏在加密之后，数据包捕获的用处越来越小。 然而，许多 QUIC 实现都遵循一种新兴的标准日志格式，人们正在构建分析工具来利用这种格式。

F5 密切关注事态发展

F5 员工多年来一直在监控 IETF 的标准工作，并在我们认为可以帮助客户的地方做出贡献。 BIG-IP 从一开始就一直在跟踪 QUIC 和 HTTP/3 的草案版本，包括自 TMOS v15.1.0.1 以来的公开版本。 NGINX 有一个HTTP/3 alpha 版本，并将很快将其合并到主线中。

我们将继续关注该领域的趋势并构建新的令人兴奋的产品以反映这些协议所提供的新功能。

结论

QUIC 得到了广泛的行业支持，并有可能成为大多数通过互联网提供商业价值的应用的基础。 任何通过互联网提供应用的人都应该开始思考他们的运营应该如何改变，以反映这些协议带来的新威胁和机遇。