自诞生三十多年以来，HTTP 一直是应用最广泛的网络协议之一，用户不仅通过它浏览网页、观看视频和听音乐，还通过它打开应用、进行机器通信，甚至构建其他协议。

为什么 HTTP 如此成功？答案是：它符合大多数需要应用协议的应用程序的需求。“用 HTTP 构建协议”（2022 年由 HTTP 工作组发布为最佳实践 RFC ）认为，HTTP 的成功可以归功于以下因素：

1. 实现者、说明者、管理员、开发者和用户都熟悉 HTTP；
2. 提供多种客户端、服务器和代理实现；
3. 易于使用；
4. 可以在网页浏览器中使用；
5. 利用现有机制，如认证和加密，
6. 目标部署中有 HTTP 服务器和客户端；
7. 可以穿越防火墙。

还有一个重要的因素是——使用、实现和规范 HTTP 的社区的形成。社区一起协作，积极维护和发展 HTTP 协议，确保 HTTP 的互操作性，使其满足不断变化的需求。如果 HTTP 停滞不前，必然会被另一个协议取代，我们就会失去在 HTTP 社区的所有投入、共识和互操作性。

大多数互联网协议是由 IETF 讨论并标准化的，Cloudflare 等公司通过派遣工程师参与 IETF 的工作。我们还参加和赞助 HTTP 研讨会等社区活动，在研讨会上讨论遇到的问题、需求以及改进方向。

2022 年的工作组会议、规范文件和边会发生了什么? 实现和部署网络协议的人在做什么？接下来会有什么变化？

新规范：HTTP/3

根据规范，2022 年最轰动的事件是 HTTP/3 的发布，它通过提高网络使用效率来增强网络性能，在适应现代应用和网站需求方面是一个极大的进步。

90 年代，HTTP/0.9 和 HTTP/1.0 对每个请求都使用新的 TCP 连接，网络使用效率非常低。之后，HTTP/1.1 引入了持久连接，通过“Connection: Keep-Alive”请求头来实现。这项改进帮助服务器和网络适应了网页的快速普及，但它有很大的局限性——特别是“队头阻塞”（连接上的一个未完成请求会阻碍其他请求的完成）。

这在 90 年代和 21 世纪初影响不大，但现在的网页和应用程序需要性能更强的网络连接。网页上数以百计的素材在争夺网络资源，但 HTTP/1.1 不能满足需求。经过多番尝试，社区终于在 2015 年发布了 HTTP/2，这些问题迎刃而解。

然而，消除 HTTP 中的“队头阻塞”后暴露了下层的 TCP 中有同样的问题。TCP 是一个有序的、可靠的传输协议，一个数据流中的单个数据包的丢失会阻碍对后面数据包的访问，即使这些数据包在操作系统的缓冲区中。这对 HTTP/2 的部署是一个问题，尤其在网络不好的情况下。

解决方案当然是替换 TCP 这个老传输协议。经过 QUIC 工作组的多次讨论与起草，QUIC 第一版于 2021 年发布。

HTTP/3 是使用 QUIC 的 HTTP 版本。虽然工作组在 2021 年就与 QUIC 一起完成了 HTTP/3，但直到 2022 年才发布，目的是为了与其他文件的出版同步（见下文）。 2022 年也是 HTTP/3 部署的一个里程碑年，Cloudflare 见证了新协议被逐渐采用的过程。

社区在 HTTP/2 发布的 7 年后就发布了 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。每次修订都是为了提高可读性，修正错误，更好地解释概念并澄清协议操作，移除不良的指定（或实现）功能，添加改善协议操作的新功能。详情请参见每个文件中的“变化”附录。注意：一定要参考上面链接的最新修订版，旧的 RFCs 已经过时。

部署早期提示

HTTP/2 包括服务器推送，这一功能旨在让服务器在知道客户端需要某些东西时向客户端“推送”请求/响应对，避免发出请求和等待响应之间的延迟惩罚。

2015 年，HTTP/2 发布后，Cloudflare 和许多其他 HTTP 实施方案很快推出了服务器推送，期待获得巨大的性能优势，但事实证明这很难。服务器的有效推送需要服务器能预测未来，不仅要预测客户端将发送什么请求，而且要预测网络状况。如果服务器出错（“过度推送”），推送的请求会直接与浏览器正在进行的真实请求相竞争，这极有可能会降低性能。如果浏览器的缓存中已经有了一个副本，就会造成更大的影响，因为根本不需要推送。

因此，Chrome 在 2022 年删除了 HTTP/2 服务器推送。可能仍有浏览器和服务器支持该功能，但社区似乎默认只在特定情况下使用服务器推送，比如，浏览器通知（特定的网页推送协议）。

这并不意味着我们要放弃服务器推送。2017 年，HTTP 工作组发布了 103（早期提示）状态代码，作为实验性 RFC。它允许服务器在非最终响应（在“真正的”最终响应之前）状态下向浏览器发送提示。发送的内容非常有用，包括浏览器能获取的资源链接，只不过需要更多的时间将响应送到客户端（因为它需要更长的生成时间，或者因为服务器需要从其他地方获取它，就像 CDN 一样）。

早期提示可以用在服务器推送设计的多种情况下，例如，需要用 CSS 和 JavaScript 加载的页面。理论上来讲，它们并不像服务器推送那样理想，因为它们只允许在有未完成的请求时发送提示，而且将提示送到客户端处理会增加一些延迟。

但在实践中，Cloudflare 和合作伙伴（比如 Shopify 和 Google）花了很多时间对 Early Hints 进行实验，发现它们使用起来更加安全，且具有良好的性能优势，其中包括关键网页性能指标的显著降低。

我们对 Early Hints 所表现出的潜力感到兴奋，已经将其集成到 Cloudflare Pages 中。我们也正在评估使用协议中的这一新功能来提高性能的新方法。

关注隐私的中介服务

许多人认为，2022 年 HTTP 协议扩展最令人振奋的是“中介”——在协议中插入代理、网关和类似组件以实现特定的目标的能力，通常侧重于提高隐私性。

例如，MASQUE 工作组正在努力为 HTTP 增加新的隧道功能，以便中介可以将隧道流量传递给另一个服务器。

虽然 CONNECT 已经启用 TCP 隧道很长时间了，但 MASQUE 启用了 UDP 隧道，使更多协议（包括 QUIC 和 HTTP/3）能被更有效地隧道化。

Cloudflare 热衷于与苹果公司合作，使用 MASQUE 来实现 iCloud 隐私中继，并且不依赖单一公司，增强客户的隐私。我们对工作组未来的工作也很感兴趣，例如实现基于 MASQUE 的 VPN 的 IP 隧道。

另一个关注中介的规范是 Oblivious HTTP（或 OHTTP）。OHTTP 使用一组中介来防止服务器使用连接或 IP 地址来跟踪客户，在收集遥测或其他敏感数据时提供更大的隐私保证。这个规范刚刚完成标准化，我们正在用它来构建一个重要的新产品——隐私网关，目的是保护客户的隐私。

我们都认为这只是一个开始，中介可以分割沟通，这是提高隐私安全的一个宝贵的工具。

协议安全

2022 年，HTTP 在安全方面有很大发展。摘要字段规范是对古老的 `Digest` 头字段的更新，允许将完整性摘要添加到消息中。HTTP 消息签名规范允许对请求和响应进行加密签名，这一点已经得到广泛的临时部署，但直到现在还缺乏一个标准。这两个规范都处于标准化的最后阶段。

2022 年，Cookie 规范的修订也取得了很大的进展，应该很快就能完成。由于不可能快速且彻底的停止使用，所以我们已经采用了很多方法来限制它们的操作方式，以提高隐私和安全，其中包括新的“同网站”属性。

Cloudflare 投资多年的另一套安全相关规范是 Privacy Pass，也称为“私人访问令牌”。这些是加密令牌，目的是确定客户是真正的人，而不是机器人，不使用侵入性的 CAPTCHA，也不跟踪用户的在线活动。它们是 HTTP 中的一种新的认证方案。

虽然 Privacy Pass 仍未完全通过标准程序，但苹果公司在 2022 年已广泛部署 Privacy Pass，这是一个巨大的进步。Cloudflare 在 CAPTCHA 替代品 Turnstile 中使用它，为用户提供更好的体验。

展望 2023 年

那么，下一步是什么呢？除了上述尚未完成的规范外，HTTP 工作组还有一些正在进行的其他工作，包括 QUERY 方法（考虑 GET 但有主体）、可恢复上传（基于 tus）、变体（一个改进的用于缓存的 Vary 头）、对结构化字段的改进（包括一个新的日期类型），以及一种将现有头像改造成结构化字段的方法。我们会在 2023 年写更多关于这些方面进展的文章。

在 2022 年的 HTTP 研讨会上，社区还讨论了可以开展的改进协议的新工作。其中包括改进我们的共享协议测试基础设施（我们现在有一些资源，但可以更好)，改进（或替换）替代服务，以保证更智能和正确的连接管理，以及更激进的变化，如头文件的替换，二进制序列。

社区还在继续讨论 HTTP 是否应该容纳 pub/sub，或者是否应该将其标准化，以便在 WebSockets（以及很快的 WebTransport）上工作。虽然现在还很难说，但邻近的 QUIC 上的媒体工作刚刚开始，可能会是推动该进程的一个机会。

当然，2023 年及之后的 HTTP 会发生什么，还有待观察。HTTP 仍在不断发展，即使它与有史以来最大的分布式超文本系统（万维网）保持兼容。

我们保护企业网络，帮助客户有效地建立互联网规模的应用，加速网站或网页应用，抵御 DDoS 攻击，使黑客无处遁形，为客户打造零信任体系。

欢迎大家使用任何设备访问 1.1.1.1，使用我们的免费应用程序，享受更快更安全的互联网。

要了解更多关于我们的信息，请点击这里开始。如果你正在寻找新工作，请查看我们的空缺职位。

原文作者：Mark Nottingham
原文链接：https://blog.cloudflare.com/the-state-of-http-in-2022/