QUIC将席卷互联网

F5生态系统 | 2021年2月22日

QUIC（并非首字母缩略词）颇为独特，但更适合将其视为一种新的传输协议。它解决了互联网中许多长期存在的问题，并涵盖了TCP、TLS、SCTP、IPSec和HTTP/2所提供的大部分价值。HTTP有一个名为HTTP/3的新版本，旨在通过UDP/QUIC而非TCP/TLS运行。

早在2014年，Google就在其浏览器和Web服务器中部署了基于QUIC的早期版HTTP。IETF于2016年启动了标准化进程。经过多次演进和数据收集，首批RFC将于2021年初发布。包括F5在内的多家大型互联网公司已经推出采用QUIC的产品，或在其基础设施中部署了QUIC。截至2020年10月，Facebook 75%的流量通过HTTP/3和QUIC传输。

这些早期部署，以及IETF对基于QUIC制定新标准的热情，表明QUIC将成为互联网前沿应用的重要底层基础，甚至可能占据主导地位。

技术概述：为何选择QUIC？

图1：QUIC融合了多种传统协议的功能。

图1让读者大致了解QUIC的作用。不过，这种功能分解并未说明为何业内的早期采用者正在转向QUIC：

降低延迟。Web类数据传输的延迟主要来自三层握手：TCP握手、至少一次TLS握手，以及一次HTTP请求/响应。TCP/TLS的最新发展原则上可以将其缩短至一次往返，但在实践中很少奏效。QUIC可将其缩短至一次往返，最多不超过两次。
流。与HTTP/2类似，QUIC为应用提供多个字节流，使通过同一连接传输的不同逻辑数据彼此更加独立。在传输层实现这一机制，可进一步增强这种独立性。流天然适合流媒体视频传输的需求，各大互联网内容提供商也在积极推进通过QUIC提供流媒体服务。
更出色的丢包响应。 QUIC的设计改进了TCP检测丢包并从中恢复的能力。此外，QUIC提供多路复用流，而非单一的按序字节流，因此，包含某个对象的数据包丢失时，不一定会延迟其他对象的交付。
多宿主。与MPTCP和SCTP非常相似，QUIC连接的每个端点都可以关联多个IP地址。与这些协议不同，即使互联网会丢弃不熟悉的协议号和TCP标头选项，QUIC仍很有可能顺利通过。
安全与隐私。 QUIC在传输层而非其上层应用加密。整个UDP有效载荷均经过身份验证，可防止中间设备在不被察觉的情况下进行任何修改，并且几乎所有传输信息都经过加密。其影响足以单独撰写一篇白皮书。简而言之，这显著增强了隐私保护能力，并几乎消除了TCP带来的攻击面。与IPSec不同，QUIC目前已在Web规模的环境中运行。这还带来了：
可扩展性。TCP难以更改，因为其创建者预留的扩展空间有限，而且中间盒会强制沿用旧有的TCP行为。QUIC采用显式版本控制，并对中间盒隐藏协议细节，从而支持传输层的进一步创新。这将有助于支持未来的用例，并最终提升大批量数据传输能力，使其优于TCP。

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

复杂性：仅需要单一字节流且不关注加密的应用，无需承担这些功能带来的额外工作负载。
中间盒：相当一部分互联网路径不允许UDP流量通过。HTTP/3针对这些路径设计了TCP回退机制，但最终，对大型网站（Google、Facebook等）造成的性能影响可能会使相关设备被淘汰，除非某些国家出于监控目的强制要求使用这些设备。

它正在吞噬互联网

Google Chrome、Google App Clients和Facebook应用已支持HTTP/3。Safari、Edge和Firefox也已实现支持，但目前默认关闭。

在服务器端，Google、Microsoft、Facebook、Apple、Cloudflare、LiteSpeed、F5 BIG-IP、NGINX、Fastly和Akamai的实现和/或部署已经发布或即将发布。最近，一家欧洲主要ISP报告称，其20%的数据包使用QUIC。2021年2月，约有5%的网站使用HTTP/3，但我们预计RFC发布后，这一比例将会上升。

此外，标准组织正在积极推动QUIC拓展至HTTP以外的用例。IETF的标准草案提议通过QUIC承载DNS、WebSocket、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 SYN Cookie已被“重试数据包”取代，后者不易被中间设备伪造。已有标准的协调方式，可让服务器卸载重试数据包的生成和验证，但这同样需要投入开发工作。

传统的第4层负载均衡会导致QUIC地址迁移失效，因为它无法将地址或端口发生变化的流与原流关联起来，进而将其路由到同一台服务器。已有相关标准可用于协调并解决这一问题，但仍需投入资源。

IETF的MASQUE工作组正在研究基于QUIC的通用流量隧道技术，这可能成为下一代VPN方案的基础。与基于TCP的TLS相比，QUIC的特性更适合对任意流进行多路复用。这些隧道还可以利用适用于Web规模的加密技术取代IPSec隧道，从而改进部分服务提供商用例，甚至可以在获得客户端明确同意的情况下，针对移动链路类型优化QUIC连接。

QUIC将需要新的网络测量和分析工具。原本可测量TCP延迟和丢包的系统无法使用这些信号，但网络中存在一个显式延迟信号，未来还可能出现其他信号。随着更多传输信息被加密隐藏，数据包捕获的作用有所降低。不过，许多QUIC实现都遵循一种新兴的标准日志格式，人们正在构建分析工具来利用这种格式。