2022 年 HTTP 发展现状

自诞生三十多年以来,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/
推荐阅读
相关专栏
前端与跨平台
90 文章
本专栏仅用于分享音视频相关的技术文章,与其他开发者和声网 研发团队交流、分享行业前沿技术、资讯。发帖前,请参考「社区发帖指南」,方便您更好的展示所发表的文章和内容。