HTTP/3 + QUIC：性能有余 安全不足

HTTP 概述  

超文本传输协议（HTTP）全称Hyper Text Transfer Protocol，用于使用超文本链接加载网页。HTTP 是一种应用层协议，主要涉及客户端向服务器发出请求，然后服务器发送响应消息。  

HTTP 是一种无状态协议，目前主要与 TLS（传输层安全）协议一起使用，TLS为 HTTP 提供机密性、完整性和身份验证机制——通常称为 HTTPS。   HTTP 由各种不同的组件组成，用于交换实际数据和元数据：  

HTTP 请求方法（即 GET、POST、PUT、PATCH、DELETE）

HTTP 标头（即 Cookie、XFF、主机、内容类型、连接）

HTTP 响应码 - 表示请求状态的数值（例如：404 Not Found，表示在服务器上找不到请求的资源）

HTTP的历史  

历史上最早的HTTP协议是1989年CERN（译注：即“欧洲核子研究组织”的原称 - Conseil Européen pour la Recherche Nucléaire）的 Tim Berners-Lee 发明的，目前命名为HTTP/0.9。然而，由于缺乏现代的传输机制、头文件、方法等，它从未获得官方的RFC，实际上也不再被使用。下面列出了官方 HTTP 初始规范 RFC，重点介绍了它们引入时最重要的新功能：   HTTP/1.0 - 1996 年 5 月 - RFC 1945  

支持 HTTP 报头

支持 HTTP 状态码

支持 Content-Type 报头

增加了新的POST 和 HEAD 方法

HTTP/1.1 - 1997 年 1 月 - RFC 2068  

引入持久连接 - 可以通过单个连接发送多个请求

强制主机头 - 对web代理路由很重要

新的 HTTP 状态码 100

新的 HTTP 方法 - PUT、PATCH、DELETE、CONNECT、TRACE 和 OPTIONS

支持各种压缩和解压缩方法 - Gzip 最常用

  HTTP/2.0 - 2015 年 5 月 -  RFC 7540  

支持请求多路复用，引入 HTTP 流，现在请求/响应可以多路复用并且不是连续的

支持请求优先级，例如，CSS 文件应该在 JS 文件之前发送

自动 Gzip 压缩

HTTP 连接重置支持，如果在 HTTP 级别发生错误，可以立即重置连接

支持服务器推送，服务器可以在没有明确请求的情况下主动将内容推送回客户端。

支持报头压缩 (HPAK)  

  HTTP/3.0 - 2022 年 6 月 - RFC 9114  

使用 QUIC 协议代替TCP/TLS 栈 - RFC 9000

  2022 年 6 月，IETF（互联网工程任务组）HTTP 组不仅发布了 HTTP/3 RFC 9114，还决定对 HTTP RFC 结构进行细化、清理和重建。此外，有些东西已经从 HTTP 标准中分离出来，并移至它们自己的 RFC 中。  

HTTP 语义- RFC 9110：HTTP 的总体架构、常用术语和共享协议方面，例如请求和响应消息/doc/rfc9111s、方法、状态码、头和尾字段、消息内容、表示数据、内容编码等等。

HTTP 缓存- RFC 9111：HTTP 缓存和相关的报头字段来控制响应缓存的行为。

HTTP/1.1 - RFC 9112

HTTP/2.0 - RFC 9113

QPAC - RFC 9204

| 图 1 HTTP 相关 RFC  

在最初的HTTP/1.0发布之后，用户很快发现它缺少很多潜在的特性，需要进行一些优化。仅半年之后就发布了HTTP/1.1来解决这些问题。而新的官方HTTP/2标准花了整整18年的时间来开发，主要是为了解决性能方面的问题。7年后的2022年6月，HTTP/3协议被引入。

HTTP/3协议最大的变化是放弃了对 TCP/TLS 堆栈的支持，并用新的互联网协议——QUIC传输协议取而代之。  

让我们比较一下 HTTP/2 和 HTTP/3 协议。  

HTTP/2 与 HTTP/3



| 图2  HTTP/2 vs. HTTP/3  

我们逐层进行分析：  

1）第 3 层没有变化——IP 堆栈保持不变；支持 IPv4 和 IPv6

2）在第 4-6 层，我们看到了主要差异：

UDP（用户数据报协议）取代了TCP 协议进行包转发

QUIC：

取代了所有 TCP 协议功能，如面向连接、提供拥塞控制和避免、流量控制机制等

集成TLS1.3协议，负责流量加解密

TLS 层正在与 QUIC 集成，并提供密钥协商、身份验证和会话恢复功能

流复用机制也从HTTP层搬到了QUIC层

3）在 HTTP 层使用更高效的 QPACK 头压缩算法，可以利用 QUIC 协议功能   HTTP/2 和 HTTP/3 之间最大的区别是使用 QUIC over UDP 而不是 TCP 作为传输机制，其中 QUIC 协议不仅集成了 TCP 典型功能，还集成了 TLS 来提供安全性和流复用。值得一提的是，在 QUIC 实现中，TLS 的使用是强制性的——因此 HTTP/3 不再有纯文本 HTTP。  

HTTP/2 与 HTTP/3 - 性能考虑

减少线头阻塞

通过将流多路复用从HTTP层移到QUIC传输层，HOL阻塞的情况可能会减少，不过它在很大程度上取决于 Web 浏览器上的特定多路复用实现。  

0-RTT 会话设置

下图通过客户端和服务器之间示例流的往返时间来比较 HTTP/2 和 HTTP/3：



| 图 3 不同实现之间的 RTT 比较  

TLS1.3 的特性是0-RTT 会话恢复，假设我们最近与特定的 Web 服务器进行过通信，我们可以自动重用密钥，并在初始会话设置时开始传输实际数据。对于 TCP，它会将 RTT 减少到 2，而QUIC 可以减少到 1。  

下图显示了 TCP 和 QUIC 在最佳情况下的差异：



| 图 4 TLS1.3 0-RTT TCP与QUIC对比  

虽然这看起来只是节省一个 RTT，但是在卫星和长距离连接方面可能是一个巨大优势。  

连接迁移

由于 QUIC 协议使用了叫做源和目标Circuit ID (CID) 的新字段，现在在不丢失文件传输的情况下从一个连接迁移到另一个连接要容易得多。例如，连接可以轻松地从 Wi-Fi 迁移到 5G，并且仍然可以重用现有的 QUIC 会话。  

总结性能考虑因素——通常在现代城市地区——从 TCP+HTTP/2 迁移到 QUIC+HTTP/3 的好处可能不会那么大。然而，不太理想的连接条件将变成 QUIC+HTTP/3 应该表现得更好并提供更好的性能和可靠性。  

在性能方面，如果是在现代城市地区，从TCP+HTTP/2迁移到QUIC+ HTTP/3的优势可能不是那么大。然而，在连接条件不太理想的情况下，QUIC+HTTP/3的表现会更好，并能够提供更好的性能和可靠性。  

此外，TCP 实现通常是在操作系统内核上，这大大减慢了新 TCP 扩展和机制的开发和采用，而QUIC是用户空间实现。随着时间的推移，越来越多的 QUIC 功能将被转移到操作系统级别，以提高性能，此外还将引入 SmartNIC，将部分或全部 QUIC 功能卸载到硬件级别。

HTTP/2 与 HTTP/3 - 安全考虑  

HTTP/3 与 HTTP/2 有两个主要的安全考虑因素：  

最终用户角度

从最终用户的角度来看，默认情况下使用 HTTP/3 应该更加安全。HTTP/3目前仅支持 TLS1.3 安全通信，此外与 HTTP/2 相比，HTTP/3 暴露在网络报头中的信息要少得多。  

目前谷歌、Facebook等公司已经支持 HTTP/3了，甚至在 RFC 最终确定之前，谷歌服务实际上就在 QUIC 上使用 HTTP/2，所以它被称为 HTTP/2 over QUIC，后来变成了 HTTP/3。  

中间人视角（防火墙 TLS 代理）

所有主要的下一代防火墙都使用一种称为 TLS 代理的技术，以便能够解密 TLS 流量，基本上，防火墙成为充当代理的中间人设备，下图说明了这一点。



| 图 5 防火墙传统

TLS 代理解决方案，来源PaloAlto Networks   这种方法不再适用于 QUIC 协议，因为很少有支持解密 QUIC 协议的供应商，并且存在很多挑战，所有 NGFW检测模块都必须重写才能支持此类功能，这肯定会花费很多时间.  

另一个问题是，目前还没有真正的方法来有效地跟踪这样的连接。理论上，目标Circuit ID听起来是个不错的选择，然而，在活动连接期间，客户端可以随意更改其源Circuit ID。另一方面，在第4层，它看起来就像是动态src-port和dst-port为443的常规UDP数据包，打开此类流量可能会导致通过防火墙发起UDP打洞攻击。  

幸运的是，如果无法建立快速连接，则会自动回退到 HTTP/2 over TCP，然后防火墙可以对其进行解密和检查。  

HTTP/2 与 HTTP/3 使用统计  

根据Web Technologies Surveys，截至 2022 年 11 月，约 42% 的网络流量是 HTTP/2。但是，自 2021 年 11 月以来，它的使用率一直在下降。



| 图 6  HTTP/2的使用情况，2022 年 11 月   另一方面，HTTP/3 协议的使用自 2021 年以来一直在增加，并在 2022 年 11 月达到 26%。



| 图 7  HTTP/3的使用情况，2022 年 11 月   HTTP/3的缺点在于前述的与 QUIC 不兼容的中间防火墙内容检查和解密机制。截至撰写本文时，几乎没有支持 HTTP/3 解密和检查的防火墙供应商。  

总  结  

HTTP/3 主要是为了引入一个更健壮、灵活和现代的传输层协议——QUIC。QUIC 协议不必只与 HTTP 一起使用，有一些新的举措可以将它与其他协议一起使用，例如 DNS 和 SSH。  

其次是性能提升，如果与 HTTP/2+TCP+TLS1.3（0-RTT）的最佳可能实现相比，HTTP/3 仍然有一个往返时间 (RTT) 的优势。在现代、快速、城市化的网络中，这可能听起来不多，但绝对是一种改进。在较慢的网络和流量突发的情况下，加载页面/资源可能会节省几百毫秒。在连接迁移方面也有好处，特别是允许移动用户更改连接方法并且仍然能够继续下载文件或维持现有连接。  

最后，QUIC 仍处于开发阶段的早期，第 1 版专注于完成基本的传输和安全协议，更多高级功能尚未出现，并且随着时间的推移它只会变得更好更快。由于现有的实现是在用户空间而不是操作系统级内核空间中开发的，因此新的高级功能的开发应该更快更容易采用。目前HTTP/3 已经在互联网上得到了部署和使用。谷歌、Meta、微软、Akamai、Cloudflare、Fastly、F5 和爱立信等大型科技公司已经在大量使用它。   
   

审核编辑：刘清