HTTP/3 是下一代跨 Web 的网络通信协议，这意味着它会部分取代 HTTP/1 和 HTTP/2。
HTTP/3 承诺让互联网连接更快、更稳定和更安全。它的前身为“HTTP over QUIC”，其目标是让 HTTP 在谷歌自己的传输层协议 QUIC 上运行，随后，它被提议为 IETF ，目前是 Internet 草案。在 2018 年 10 月，IETF HTTP & QUIC 工作组联席主席马克·诺丁汉（ Mark Nottingham）提议将 HTTP over QUIC 重命名为 HTTP/3 ，以澄清其本质特点及其与 QUIC 的独立性。
QUIC 是 HTTP/3 的关键元素，它为 HTTP/3 的主要特性提供了基础。QUIC 构建在 UDP 之上，致力于解决使用 TCP 协议遇到的主要问题，比如，连接建立的延迟和存在丢包情况下的多流处理。TCP 延迟问题源于其拥塞控制算法的需求，该算法要求在拥塞发生之前会缓慢地开始（slow start）评估可以发送多少流量。在 HTTP/1.0 中，每个 TCP 请求 / 响应交换都会被分配一个新的连接，就会导致启动缓慢的问题。
从此之后，规避 TCP 启动慢的尝试一直是 HTTP 协议改善的核心。
HTTP/1.1 引入了“keep-alive”连接，允许在同一个 TCP 连接上对多个请求 - 响应交换进行序列化，因此不需要为每个请求都设置新的连接建立阶段。然而，HTTP/1.1 的 keep-alive 连接不支持同时发送多个请求，随着 Web 页面日益复杂，又出现了新的瓶颈。
HTTP/2 则源自现在已被弃用的 SPDY 协议，它引入了在同一连接中嵌入第一等流的概念。这使得在保证多路复用的同时实现请求 - 响应交换成为可能，但是它有一个主要的缺陷：当数据包丢失增加时， HTTP/2 的性能会由于 TCP 处理包重传的方式（HOL 阻塞）而下降。这种影响可能非常严重，因为所有流都共享相同的连接。当数据包丢失超过一个给定的阈值时，HTTP/1 的多连接甚至会比 HTTP/2 运行地更高效。
如前文所述，QUIC 提供了对流的第一等支持，这解决了 HTTP/2 中连接初始化缓慢的问题。另外，它可以对它们进行单独处理，从而解决了由于数据包丢失而导致的性能问题。采用 QUIC 作为传输层协议是 HTTP/3 与 HTTP/2 最大的区别。由于 QUIC 本身实现了大量与流管理相关的特性，这些特性是 HTTP/2 规范的组成部分，因此可以从 HTTP/3 中删除它们。此外，由于 HTTP/2 HPACK 报头压缩严重依赖于 TCP 向端点传递包的顺序，所以需要采用 QUIC 来创建新的 HTTP 报头压缩方案，即 QPACK 。
最近几年来，谷歌一直在使用 QUIC 提供自己的服务，包括搜索、YouTube 等，而且在 Chrome 中也支持它。曾经有一段时间，在与支持 QUIC 的谷歌服务通信时，Chrome 是唯一的手段。最近， Mozilla 在 Firefox 72 中也增加了对 HTTP/3 的支持，尽管仍处于试验阶段。命令行工具 curl 在 7.66.0 版本中也增加了对 HTTP/3 的支持以及许多其他特性。在服务器端， LightSpeed 和 Nginx 支持 HTTP/3。
在云方面，除了谷歌之外，Cloudflare 几个月前宣布已经为部分客户启用了对 HTTP/3 的初步支持。Cloudflare 是 Quiche 背后的公司，Quiche 是一个支持 HTTP/3 客户端和服务器实现的开源 Rust 库。
如前所述，HTTP/3 仍然正在由 IETF 进行定义，还没有确定正式的发布日期。与此同时，在世界范围内，HTTP/3 的使用正在增长，全世界使用它的服务接近 300,000 个。谷歌仍然是部署 HTTP/3 的最重要组织，但是其他几个组织也占据了重要的份额。
以上就是今天的内容，希望对你有所帮助。
原文链接：The Status of HTTP/3

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程

免费领取

登录后留言

精选留言

由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。

收起评论



显示
设置



留言





沉浸
阅读





手机端



快捷键



回顶部