互联网的未来：为什么我们需要 HTTP/3？

自1997年HTTP/1.1标准化以来，一直是首选的应用层协议。多年来，为了跟上互联网的发展和网络上交换内容的多样性，HTTP 不得不进行升级。本文展示了 HTTP 协议的演变，深入探讨了 HTTP/3，重点介绍了 HTTP/3 的特性，最后展望了HTTP/3 驱动下互联网的未来。

HTTP/3 的出现

HTTP 催生互联网

当 Tim Berners-Lee 构想互联网时，HTTP(超文本传输协议) 是一个“单行协议”。HTTP/0.9 由 ASCII 文本字符串请求组成：GET method，后跟文档地址、可选的端口地址，以回车符 (CR) 和换行符 (LF) 结尾。请求由一串 ASCII 字符组成，只能传输 HTML 文件，没有 HTTP 报头，也没有状态或错误代码。

多年来，HTTP 从 HTTP/1.0 发展到 HTTP/1.1，再到 HTTP/2。在每次迭代中，都会向协议中添加新特性，以满足当时的需求，例如应用层要求、安全考虑、会话处理和媒体类型。

HTTP/2 面临压力

在 Internet 和 HTTP 的发展过程中，HTTP 的底层传输机制基本没有变化。然而，随着移动设备技术的大规模普及，实时应用需求的增加，互联网流量不断增长，HTTP/2 的缺点也越来越明显。

其一，HTTP/2 的最终版本并没有在 HTTP/1.1 基础上改进很多。为了保持与 HTTP/1.1 的向后兼容，该协议必须保留相同的 POST 请求、GET请求 、状态代码（200、301、404 和 500）等。

其二，一些已实现的功能带来了安全问题。除了遗留的强制加密缺失之外，还包括容易受到攻击的压缩页面报头和 cookie。

HTTP/3 的目标是解决 HTTP/2 的传输相关问题，可以在各种设备上提供快速、可靠和安全的 Web 连接。为此，它使用了一种名为 QUIC 的协议，该协议运行在UDP互联网协议之上，而不是TCP。

与 TCP 的有序消息交换方案不同，UDP 允许消息的多向广播，这一特性有助于解决数据包级别的队头阻塞 (HoL) 问题。

TCP 和 UDP 中消息排序的区别（SYN=同步；ACK=确认）

此外，QUIC 重新设计了客户端和服务器之间握手的方式，减少了与建立重复连接相关的延迟。

TCP、TCP+TLS 和 QUIC 中重复连接数据第一个字节的消息数

HTTP/3 的出现

在IETF正式标准化 HTTP/2 的同时，谷歌正在独立构建新的传输协议 gQUIC，可以在网络状况不佳的情况下改善浏览体验。

采用 gQUIC 的呼声越来越高，它被重新命名为 QUIC。大多数 IETF 成员投票决定为 HTTP 建立一个新的规范以在 QUIC 上运行（HTTP over QUIC），也就是 HTTP/3。

HTTP/3 在语法和语义上与 HTTP/2 相似，遵循着相同的请求和响应消息交换顺序，其数据格式包含方法、报头、状态码和正文。HTTP/3 的显着差异在于 UDP 之上协议层的堆叠顺序，如下图所示。

HTTP/3 中的堆叠顺序显示 QUIC 与安全层和部分传输层重叠

HTTP/3 和 QUIC 如何解决 TCP 的局限性

HTTP/3 功能的优势来自于底层的 QUIC 协议。在我们讨论 QUIC 和 UDP 之前，先了解一下TCP 发展的局限性。

QUIC 中使用UDP 不会在出错时请求数据重发

TCP的局限性

TCP 会间歇性挂起数据传输

如果序列号较低的数据段尚未到达/接收，即使序列号较高的段已经到达/接收，TCP 的接收器滑动窗口也不会前进。这会导致 TCP 流暂时挂起甚至关闭，这个问题称为 TCP 流的队头阻塞 (HoL) 。

数据包级别的队头阻塞会导致 TCP 流关闭

TCP 不支持流级多路复用

虽然 TCP 允许与应用层之间的多个逻辑连接，但它不允许在单个 TCP 流中多路复用数据包。使用 HTTP/2，浏览器只能打开一个与服务器的 TCP 连接。它使用同一个连接来请求多个对象，例如 CSS、JavaScript 和其他文件。在接收这些对象时，TCP将同一流中的所有对象序列化。因此，它不知道TCP段的对象级分区。

TCP 导致冗余通信

在进行连接握手时，TCP 交换一系列消息，如果与已知主机建立连接，会有冗余的消息交换序列。

使用 TLS 加密通信会话开始时的TCP+TLS 握手

QUIC

QUIC协议在以下设计的基础上，通过引入一些底层传输机制的改变，解决 TCP 的这些限制。

选择UDP作为底层传输层协议

如果还在TCP 之上的建立新的传输机制，将仍继承前面所说的TCP限制。QUIC 是在用户级别构建的，它不需要在每次协议升级时更改内核，从而更易采用。

流复用和流量控制

QUIC 引入了在单个连接上多路复用流的概念。QUIC 实现了单独的、逐流的流量控制，从而解决了整个连接的队头阻塞问题。

使用 UDP，没有包级的队头阻塞

灵活的拥塞控制

TCP有严格的拥塞控制机制。每次 TCP 协议检测到拥塞时，它都会将拥塞窗口的大小减半。QUIC 的拥塞控制更加灵活，可以更有效地利用可用网络带宽，从而获得更好的流量吞吐量。

更好的错误处理

QUIC 提议使用增强的丢失恢复机制和前向纠错来处理错误的数据包，尤其是对于在传输中容易出现高错误率的缓慢的无线网络。

更快地握手

QUIC 使用与 HTTP/2 相同的 TLS 模块来实现安全连接。然而，与 TCP 不同的是，QUIC 的握手机制经过优化，可以避免在两个已知对等点相互建立通信时进行冗余协议交换。

使用 TCP 和 TLS 建立安全连接至少需要两次往返时间 (RTT)，增加了延迟开销。使用 QUIC，建立第一个加密连接是 1 个RTT，当会话恢复时，有效负载数据与第一个数据包一起发送，RTT 最少为零。

第一次连接和后续连接之间不同协议的 RTT 数量比较

语法和语义

通过在QUIC之上构建基于HTTP/3的应用层，可以获得增强传输机制的所有优势，同时保留与 HTTP/2 相同的语法和语义。但是HTTP/2 不能直接与 QUIC 集成，因为从应用到传输的底层帧映射是不兼容的。因此，IETF 的 HTTP 工作组建议将 HTTP/3 作为新的HTTP 版本，并根据 QUIC 协议的帧格式要求修改其帧映射。

压缩

HTTP/3 还使用了一种称为 QPACK 的新报头压缩机制，是对 HTTP/2 中使用的 HPACK 的修改。在 QPACK 下，HTTP 报头可以在不同的 QUIC 流中乱序到达。QPACK 使用了一种查找表机制来对报头进行编码和解码。

为什么 HTTP/3 很重要？

TCP 已经存在了40多年。它最初于 1981 年通过 RFC 793 标准化。多年来，它被证明是一个支持互联网流量增长的非常强大的传输协议。然而，在设计上，TCP 不适合处理有损无线介质上的数据传输。

在互联网的早期，有线连接是唯一的连接方式，所以这在当时来说不是什么大问题。但现在，智能手机和便携式设备的数量超过台式机和笔记本电脑，超过 50% 的互联网流量是通过无线传输的。随着这种增长，整体 Web 浏览体验随着响应时间的增加而恶化。

谷歌首次旨在解决 HoL 的测试证明，将 QUIC 作为谷歌服务的底层传输协议大大提高了响应速度和用户体验。将 QUIC 部署为 YouTube 视频的底层传输协议，谷歌报告称重新缓冲率下降了 30%，这对视频观看体验有直接影响。

在网络条件较差的情况下提升非常明显，这促使谷歌更加积极地改进协议，最终将其提交给 IETF 进行标准化。

凭借这些早期试验带来的改进，QUIC 已成为将网络带入未来的重要组成部分。

HTTP/3 的最佳用例

HTTP/3 的目的是改善整体网络体验，尤其是在高速无线互联网访问仍然不可用的地区。尽管 HTTP/2 非常适合其中的一些应用程序，但 HTTP/3 在以下场景中更有价值：

物联网 (IoT)

由于其局限性， HTTP 可能不是 IoT 的首选协议，但有些应用程序非常适合基于 HTTP 的通信。例如，HTTP/3 可以解决从附加传感器收集数据的移动设备的无线连接有损问题。这也适用于安装在车辆或移动资产上的独立物联网设备。

微服务

在微服务网格中，为了获取数据，遍历所有微服务会浪费大量时间。QUIC 的优势在于握手次数较少，因此可以在几毫秒内传递这些请求。HTTP/3 在这里的好处不在于大数据的吞吐量，而在于加速每个微交互。

网络虚拟现实 (VR)

随着浏览器功能的不断改进，内容格局也会相应发生变化。其中一个变化领域是基于网络的 VR。尽管仍处于起步阶段，但在许多情况下，VR 在增强协作方面发挥着关键作用。VR 应用程序需要更多带宽来呈现虚拟场景的复杂细节，因此迁移到HTTP/3会大有收获。

HTTP/3 的局限性

过渡到 HTTP/3 不仅涉及应用层的变化，还涉及底层传输层的变化。因此，与其前身 HTTP/2 相比，采用 HTTP/3 更具挑战性，后者只需要在应用层进行更改。

传输层要经过网络中间层的严格审查，如防火墙、代理、NAT 设备等，为了满足其功能需求，需要进行大量的深层包检测。因此，新传输机制的引入会对 IT 基础架构和运营团队产生了一些影响。

安全服务通常建立在应用程序流量（大部分为 HTTP）将通过 TCP 传输的前提下，TCP是以可靠性为中心、面向连接的协议。对 UDP 的更改可能会对安全基础设施解析和分析应用程序流量的能力产生重大影响，因为 UDP 是一种基于数据包的协议，而且可能不可靠。

另一个问题是，TCP目前是大多数web通信的首选协议，防火墙的默认数据包过滤策略可能能不支持长时间运行HTTP/3的UDP会话。

结论

HTTP/3 可以被认为是通过 QUIC 传输的 HTTP 语义，QUIC 是默认的加密传输协议，使用 UDP 进行拥塞控制。并不是 HTTP/2 的所有特性都可以映射到 QUIC 之上。一些 HTTP/2 功能需要顺序保证，虽然 QUIC 可以在单个流中提供这种保证，但它不能跨流提供相同的保证。因此，需要对 HTTP 进行新的修订。

QUIC 的两个主要目标是解决数据包级别的队头阻塞并减少 HTTP 连接和流量中的延迟。使用 UDP 允许多路复用和轻量级连接建立，改善了最终用户在低质量网络上的体验。

通过一些更改，IETF 验证了 HTTP-over-QUIC 的概念，并将其重命名为 HTTP/3。2022年6月6日，IETF QUIC 和 HTTP 工作组成员 Robin Marx 宣布，经过 5 年的努力，HTTP/3 正式被标准化为 RFC 9114，同时，HTTP/2 也更新为 RFC 9113标准，HTTP/1.1 和通用 HTTP 语义和缓存概念在 RFC 9110-9112 中也得到了加强。

*本文系SDNLAB编译自Ably博客

【转载须知】

若转载文章为原创文章，可在相应文章下或公众号后台留言；其他非转载类文章须在文首以不小于14号字体标明转载自SDNLAB。