仓库源文站点原文


title: HTTP/3 slug: http categories: [http, http3]

author: blue

HTTP3 是 HTTP 协议的最新版本。从诞生之初,HTTP 就是交换超文本文档的首选应用层协议。 多年来,为了跟上互联网的发展,以及 WWW 上交换的内容种类增加,HTTP 进行了几次重大升级。

本文将深入探讨 HTTP/3,介绍 HTTP 协议的演变历程,重点介绍 HTTP/3 的特点,并对 HTTP/3 将会带来的互联网变化提供新的视角。

多年来,HTTP 从 HTTP/1.0 发展到 HTTP/1.1,再到 HTTP/2。在每一次迭代中, 协议都增加了新的功能,以处理大量的需求,如应用层需求、安全考虑、会话处理和媒体类型等。 要深入了解 HTTP/2 及其从 HTTP/1.0 演变而来的 HTTP/2,请看我们的 HTTP/2 概念文章。

尽管经历了几次修订,但 HTTP 的底层传输机制基本没有变化。但是,随着互联网流量的激增, 在移动电话的推动下,HTTP 的传输机制在保证网页浏览体验的流畅性方面变得问题重重。

HTTP/3 是为了处理 HTTP/2.0 的传输相关问题而生的,可以在各种设备上更快地访问 Web。 它基于一个新的传输层协议,称为 QUIC(Quick UDP Internet Protocol),在 UDP 之上工作。 这一选择与之前版本的 HTTP 截然不同,之前版本都是基于 TCP。TCP 是一个比 UDP 更可靠的协议, 那么为什么要在 UDP 之上重新设计 HTTP 的传输层呢?

让我们来看看在 TCP 上运行 HTTP 的局限性,并深入了解一下基于 QUIC 协议的 HTTP/3 的设计思想。

从语法和语义上看,HTTP/3 与 HTTP/2 相似。HTTP/3 遵循相同的请求和响应消息交换顺序, 其数据格式包含方法、标题、状态码和 body。然而,HTTP/3 的显著的偏差在于协议层在 UDP 之上的堆叠顺序。

微信图片_20200514173935

流复用和流控。QUIC 引入了连接上的多路流复用的概念。QUIC 通过设计实现了单独的、 针对每个流的流控,解决了整个连接的行头阻塞问题。

微信图片_20200514174900

灵活的拥塞控制机制。TCP 的拥塞控制机制是刚性的。该协议每次检测到拥塞时, 都会将拥塞窗口大小减少一半。相比之下,QUIC 的拥塞控制设计得更加灵活, 可以更有效地利用可用的网络带宽,从而获得更好的吞吐量。

更好的错误处理能力。QUIC 使用增强的丢失恢复机制和转发纠错功能,以更好地处理错误数据包。 该功能对于那些只能通过缓慢的无线网络访问互联网的用户来说是一个福音, 因为这些网络用户在传输过程中经常出现高错误率。

更快的握手。QUIC 使用相同的 TLS 模块进行安全连接。然而,与 TCP 不同的是,QUIC 的握手机制经过优化,避免了每次两个已知的对等者之间建立通信时的冗余协议交换。

微信图片_20200514174927

灵活的拥塞控制机制。TCP 的拥塞控制机制是刚性的。该协议每次检测到拥塞时, 都会将拥塞窗口大小减少一半。相比之下,QUIC 的拥塞控制设计得更加灵活, 可以更有效地利用可用的网络带宽,从而获得更好的吞吐量。

更好的错误处理能力。QUIC 使用增强的丢失恢复机制和转发纠错功能,以更好地处理错误数据包。 该功能对于那些只能通过缓慢的无线网络访问互联网的用户来说是一个福音,因为这些 网络用户在传输过程中经常出现高错误率。

更快的握手。QUIC 使用相同的 TLS 模块进行安全连接。然而,与 TCP 不同的是,QUIC 的握手机制经过优化,避免了每次两个已知的对等者之间建立通信时的冗余协议交换。

现在,随着智能手机和便携式设备的数量超过台式机和笔记本电脑的数量,超过 50% 的互联网流量已经通过无线传输。这种趋势给整体的网络浏览体验带来了问题, 其中最重要的是在无线覆盖率不足的情况下,TCP 中的行头阻塞。

Google 的一些初步实验证明,QUIC 作为 Google 部分热门服务的底层传输协议, 极大地提高了速度和用户体验。部署 QUIC 作为 YouTube 视频的底层传输协议,导致 YouTube 视频流的缓冲率下降了 30%,这直接影响了用户的视频观看体验。在显示谷歌搜索结果时, 也有类似的改善。

网络条件较差的情况下提升非常明显,这促使谷歌更加积极地完善该协议,并最终向 IETF 提出标准化。

由于这些早期的试验所带来的所有改进,QUIC 已经成为带领万维网走向未来的重要因素。 在 QUIC 的支持下,HTTP 从 HTTP/2 到 HTTP/3 的改头换面,朝着这个方向合理地迈出了一步。

然而,HTTP/3 被广泛采用的另一个问题是,它是基于 QUIC 的,在 UDP 上运行。大多数的 Web 流量,以及 IETF 定义的知名服务都是在 TCP 之上运行的。这也是为什么长时间运行 HTTP/3 的 UDP 会话会被防火墙的默认数据包过滤策略所影响的原因。

随着 IETF 正在进行的标准化工作,这些问题最终都会得到解决。此外,考虑到 Google 在早期 QUIC 实验所显示的积极结果,人们对 HTTP/3 的支持是压倒性的, 这将最终迫使中间层厂商标准化。

针对受限的 IoT 设备,HTTP/3 由于过于繁琐从而无法采用。许多 IoT 应用部署的设备的 外形尺寸非常小。因此,它们的 RAM 和 CPU 功率都是有限的。为了使设备在电池功率、 低比特率和有损连接等限制条件下高效运行,必须执行此要求。HTTP/3 在现有的 UDP 之上, 以 QUIC 的形式在传输层处理,增加了 HTTP/3 在整个协议栈中的占用空间。这使得 HTTP/3 较为笨重,不适合那些 IoT 设备。但这种情况很少出现,而且存在专门的协议,这就避免了 直接在此类设备上支持 HTTP 的需要。此外,还有以物联网为核心的协议,如 MQTT。

以下是支持 HTTP/3 和 QUIC 传输 lib 的列表。请注意,这些实现都是基于互联网标准草案 某一个版本,而这个版本很可能会被更高的版本所取代,最终的标准会在 RFC 中发布。

Quiche (https://github.com/cloudflare/quiche)

Quiche 提供了通过 QUIC 协议发送和接收数据包的底层编程接口。它还支持 HTTP/3 模块, 通过其 QUIC 协议实现发送 HTTP 数据包。除此之外,它还为 NGINX 服务器提供了一个 非官方的补丁,可以安装和托管一个能够运行 HTTP/3 的 Web 服务器。除此以外, 还提供了额外的程序来支持 Android 和 iOS 移动应用上使用 HTTP/3。

Aioquic (https://github.com/aiortc/aioquic)

Aioquic 是 QUIC 的 python 实现。它还内置 HTTP/3 的测试服务器和客户端库。Aioquic 建立在 asyncio 模块之上,asyncio 模块是 Python 的标准异步 I/O 框架。

Neqo (https:/github.com/mozilla/neqo)

Neqo 是 Mozilla 使用 Rust 实现 QUIC 和 HTTP/3。

原文地址:https://www.ably.io/concepts/http3?utm_medium=referral&utm_source=reddit&utm_campaign=evergreen#limitations

引用地址:https://mp.weixin.qq.com/s/i-QUbVRVicqzMSZ9FUVCfQ


评论:

有人说, 当他们身在中国大陆使用 UDP 服务时会被 QoS 限流.

虽说是将来的标准, 但整体来说, 这还是未来式.

我们可以通过 https://caniuse.com/#feat=http3 来了解浏览器对其的支持情况.