HTTP 已经有 30 多年的历史了，但它仍然是 Web 的基础，也是互联网上最流行的协议之一。它不仅用于浏览、看视频和听音乐，还用于应用程序和机器对机器通信，甚至还作为构建其他协议的基础，形成了经典互联网沙漏图中的“第二腰”。
为什么 HTTP 如此成功？一个答案是，对于大多数需要应用程序协议的应用程序来说，它击中了一个“甜蜜点”。 “使用 HTTP 构建协议” (由 HTTP 工作组 于 2022 年作为一项最佳当前实践 RFC 发布)一文认为， HTTP 的成功源于以下因素：
- 实施者、规范编制者、管理员、开发人员和用户的熟悉程度；- 各种客户端、服务器和代理实施的可用性；- 易用性；- Web 浏览器的可用性；- 重用现有机制，例如身份认证和加密；- 目标部署中存在 HTTP 服务器和客户端；以及- 穿越防火墙的能力。
另一个重要因素是使用、实施和标准化 HTTP 的社区。我们共同努力，积极维护和开发协议，以确保其可互操作，并满足当今的需求。如果 HTTP 停滞不前，另一种协议将(理所当然地)取代它，那么我们将失去社区的所有投资、共享理解和互操作性。
为此，Cloudflare 和其他很多人派工程师参与 IETF，这是大多数讨论和标准化大部分互联网协议的场所。我们还参加和赞助社区活动，例如 HTTP Workshop，讨论人们有什么问题，他们需要什么，并了解哪些更改可能有助于他们。
那么，在 2022 年进行所有这些工作组会议、规范文件和附带活动中发生了什么事情呢？Web 协议的实施者和部署者在做什么？接下来会发生什么呢？
新规范：HTTP/3
在规范方面，2022 年最重大的事件就是 HTTP/3 的发布，因为它通过更有效地使用网络来释放 Web 性能，在满足现代应用程序和网站的要求方面迈出了巨大的一步。
在 20 世纪 90 年代，HTTP/0.9 和 HTTP/1.0 对每个请求都使用一个新的 TCP 连接，这是对网络极其低效的利用。HTTP/1.1 引入了持久连接(通过`Connection: Keep-Alive`标头被向后移植到 HTTP/1.0)。这个改进帮助服务器和网络应对了爆炸式的 Web 流行，但即使是在那个时候，社区也知道它有重大局限性，特别是队头阻塞(某个连接上的一个未完成请求会阻止其他请求完成)。
这在 90 年代和 21 世纪初还不太重要，但今天的 Web 页面和应用对网络的要求使得这些限制对性能至关重要。页面通常有数百个资源争夺网络资源，而 HTTP/1.1 无法胜任。经过最初的一些错误，社区终于在2015 年通过 HTTP/2 解决了这些问题 。
然而，消除 HTTP 中的队头阻塞暴露了更低一层（即 TCP）中的相同问题。因为 TCP 是一种有序的、可靠的交付协议，数据流中一个数据包的丢失会阻止对后续数据包的访问，即使它们位于操作系统的缓冲区中。对于 HTTP/2 部署而言，这是一个真正的问题，尤其是在非最优网络上。
当然，答案就是取代 TCP——互联网的大部分都是基于这个古老的传输协议。经过 QUIC 工作组的大量讨论和多个草案， QUIC 第一版于 2021 年发布，作为上述替代。
HTTP/3 是使用 QUIC 的 HTTP 版本。虽然工作组实际上早在 2021 年就与 QUIC 一起完成了这个版本，但其发布被推迟到 2022 年，以便与其他文件的发布同步(见下文)。2022 年也是 HTTP/3 部署具有里程碑意义的一年； Cloudflare 看到对新协议采用和信心不断增加。
虽然 HTTP/2 和 HTTP/3 之间只有短短几年的间隔，但社区对开发 HTTP/4 的兴趣并不大。QUIC 和 HTTP/3 都是新事物，人们仍然在学习如何最好地实施协议、运行协议，并使用它们构建网站和应用。虽然我们不能排除迫使将来推出新版本的限制，但 IETF 基于有关现代网络的广泛行业经验构建了这些协议，并具有显著的可扩展性，可轻松实现任何必要的更改。
新规范：HTTP “核心”
2022 年 HTTP 规范的另一个重大事件是其“核心”文档的发布 ——这些文档是 HTTP 规范的核心。核心文档包括：HTTP 语义 —— 方法、标头、状态码和消息格式； HTTP 缓存 —— HTTP 缓存如何工作；HTTP/1.1 —— 将语义映射到网络上，使用人人都知道和喜爱的格式。
此外，HTTP/2 重新发布，以正确地集成以上语义文档，并修复一些突出的问题。
这是这些文档一长串修订中的最新一轮——过去有 RFC 723x 系列，（可能最众所周知的）RFC 2616，RFC 2068，以及最早的 RFC 1945。每个修订的目标都是提高可读性、修复错误、更好地解释概念并阐明协议运行。规范（或实施）欠佳的特性被弃用；改善协议运行的新特性被加入。查看每个文档的“修订记录”附件以了解详情。此外，重要的是，始终参考上面链接的最新修订；老的 RFC 现已过时。
部署 Early Hints
HTTP/2 包含_服务器推送(server push)_特性，当服务器知道客户端将需要什么东西时，它可以“推送”一个请求/响应对给客户端，这样就可以避免发起请求并等待响应的延迟。
在 HTTP/2 于 2015 年敲定后，Cloudflare 和其他很多 HTTP 实施推出了服务器推送，期待在性能上突飞猛进。不幸的是，事实证明这比看起来要难；服务器推送实际上要求服务器预测未来，不仅要预测客户端将发送什么请求，还要预测网络状况。而且，当服务器出错时(“过度推送”)，所推送的请求将与浏览器发出的真正请求相竞争，这意味着巨大的机会成本，有可能会损害性能，而不是促进性能。当浏览器缓存中已经有副本时，影响更大，因此根本不需要推送。
因此，Chrome 在 2022 年移除了 HTTP/2 服务器推送。其他浏览器和服务器可能仍然支持它，但社区似乎一致认为，它目前只适用于特定的用途，如浏览器通知特定的 Web 推送协议。
然而，这并不意味着我们要放弃。 103 (Early Hints) 状态码是由 HTTP 工作组在 2017 年作为实验性 RFC 发布的。它允许服务器在“真正的”最终响应之前，以非最终响应的形式向浏览器发送_提示_。如果您知道内容中将包含一些资源的链接，浏览器将获取这些资源，但需要更多时间向客户端发送响应(因为它将花费更多时间生成，或者因为服务器需要从其他地方获取它，如 CDN)，那么这是有用的。
Early Hints 可用于许多服务端推送被设计使用的情况——例如，当有页面将需要加载的 CSS 和 JavaScript 时。理论上，它们并不像服务端推送那样理想，因为它们只允许在有未完成请求时发送提示，而且将提示发送给客户端并进行操作会增加一些延迟。
然而，在实践中，Cloudflare 及其合作伙伴(如 Shopify 和 Google)在 2022 年试验了 Early Hints，发现它们使用起来更安全，有望带来性能提升, 包括关键 Web 性能指标的显著降低。
我们对 Early Hints 显示的潜力感到兴奋，因而将其集成到 Cloudflare Pages 中。我们也在评估使用协议中的这一新功能来提高性能的新方法。
注重隐私的中介
对于许多人来说，2022 年最令人兴奋的 HTTP 协议扩展是中介(intermediation) ——在协议中插入代理、网关和类似组件，以实现特定目标，通常侧重于改善隐私。
例如，MASQUE 工作组正在努力向 HTTP 添加新的隧道功能，以便中介可将隧道中的流量传递给另一个服务器。
虽然 CONNECT 实现 TCP 隧道已有很长时间， MASQUE 实现了UDP 隧道，允许更多协议更有效地传输，包括 QUIC 和 HTTP/3。
Cloudflare 满怀热情地与 Apple 合作使用 MASQUE 实施 iCloud Private Relay，并增强其客户的隐私，无需完全依赖于一家公司。我们也对该工作组未来的工作感兴趣，包括 IP 隧道，其将实现基于 MASQUE 的 VPN。
另一个专注于中介的规范是 Oblivious HTTP (缩写为 OHTTP)。OHTTP 使用一组中介来防止服务器使用连接或 IP 地址跟踪客户端，从而为收集遥测或其他敏感数据等工作提供更大的隐私保障。这个规范正在完成标准流程，我们使用它构建一个重要的新产品：Privacy Gateway，以保护我们客户的隐私。
我们和互联网社区的很多其他人相信这只是一个开端， 因为中介能分隔通信，是一个改善隐私的宝贵工具。
协议安全性
最后，2022 年期间，HTTP 协议的安全相关方面进行了大量工作。 Digest 字段规范是现已非常古老的`Digest` 标头字段的更新，允许将完整性摘要添加到消息中。HTTP 消息签名允许对请求和响应进行加密签名——这已经被广泛地临时部署，但直到现在依然缺乏标准。这两个规范都处于标准化的最后阶段。
Cookie 规范的一个修订在 2022 年也取得了重大进展，且应该即将完成。由于不可能在短时间内完全摆脱它们，人们已经做了很多工作来限制它们运作的方式以改善隐私和安全，包括一个新的`SameSite`属性。
Cloudflare 已投入多年努力的另一个安全相关规范是 Privacy Pass(隐私通行证)，又名“Private Access Token(私有访问令牌)”。这些加密令牌可以确保客户端是真实的人，而不是机器人，无需使用侵入性验证码，也不会跟踪用户的在线活动。在 HTTP 中，它们采用一种新的身份验证模式。
虽然 Privacy Pass 仍未完全通过标准程序，但在 2022 年，Apple 已经进行了广泛部署，这是一个巨大的进展。由于 Cloudflare 在我们的替代产品——Turnstile 使用了这一规范，您的用户今天就可以拥有更好的体验。
2023 年展望
那么，下一步将如何发展呢？此外，上述规范还没有完成，HTTP 工作组还有一些其他进行中的工作，包括 QUERY 方法 (想象 GET 但有 body)， 可恢复上传 (基于 tus)，Variants (用于缓存的 Vary 标头改进版)， 对结构化字段的改进 (包括一个新的 Date 类型)，以及一种将现有标头改造为结构化字段的方式。随着这些工作在 2023 年的进展，我们将进一步撰文介绍。
在 2022 年 HTTP 研讨会上，社区还讨论了我们可以开展哪些新工作来改进该协议。讨论的一些想法包括改进我们的共享协议测试基础设施 (目前我们有一些资源，但有很大改进余地)，改进(或替代) Alternative Services 以允许更智能和正确的连接管理，以及更彻底的更改，例如替代性的、标头二进制序列化。
社区中也在持续讨论 HTTP 是否应该支持 pub/sub，或者是否应该将其标准化，以便在 WebSockets (以及即将到来的 WebTransport)上工作。虽然现在还很难说，刚刚开始的 Media over QUIC 相关工作_可能_提供一个推进这方面工作的机会。
当然，以上并不是全部，HTTP 在 2023 年(及以后)会发生什么还有待观察。HTTP 仍在发展，尽管其继续兼容有史以来最大规模的分布式超文本系统——万维网(World Wide Web)。