写点什么

HTTP/3 的过去、现在和未来

2019 年 10 月 10 日

HTTP/3的过去、现在和未来

HTTP 协议为 Web 的发展提供了驱动力,它始于 1991 年的 HTTP/0.9,在 1999 年演变为 HTTP/1.1,并由 IETF(互联网工程任务组)负责进行标准化。HTTP/1.1 存在了很长一段时间,但 Web 不断变化的需求要求推出更好的协议,于是 HTTP/2 在 2015 年出现了。去年年底,IETF 又推出新版本 HTTP/3。对于有些人来说,这是一个惊喜,但也会让他们感到有一点点困惑。想要更好地了解 HTTP/3 的前世今生,以及它接下来的规划,来自 Cloudflare 博客的这篇最新文章将为你指点迷津。


在去年的“生日周”期间,我们宣布了对新生 Web 标准 QUIC 和 HTTP/3(当时称为“ HTTP over QUIC”)的初步支持,从而可以更快、更可靠、更安全地连接到网站和 API 等 Web 端点。我们还请客户加入一个等候队列,这样 QUIC 和 HTTP/3 可用后他们就能立刻试用。



从那以后,我们一直在通过互联网工程任务组(包括谷歌 Chrome 和 Mozilla Firefox)与业界同行合作,以迭代 HTTP/3 和 QUIC 标准文档。在标准日趋完善的同时,我们还致力改善网络的支持能力


现在我们很高兴地宣布,Cloudflare 边缘网络已提供 QUIC 和 HTTP/3 支持。我们很高兴能与两家领先的浏览器供应商和合作伙伴谷歌 Chrome 和 Mozilla Firefox 共同合作完成这项工作,为所有人打造速度更快、更加可靠的互联网。


用谷歌高级软件工程师 Ryan Hamilton 的话来说,“HTTP/3 会改善所有人使用 Web 的体验。Chrome 和 Cloudflare 团队密切合作,将 HTTP/3 和 QUIC 从新生标准发展为广泛应用的 Web 技术改进。行业领导者之间的强大合作伙伴关系推动了互联网标准创新,我们期待双方能继续合作。”


这对 Cloudflare 的客户又意味着什么呢?你们选择我们的服务和边缘网络,是为了让 Web 更快、更安全。在 Cloudflare 仪表板为你的域启用HTTP/3支持后,你的客户就可以使用 HTTP/3 与你的网站和 API 交互。我们一直在邀请 HTTP/3 等候队列中的客户启用该功能,在接下来的几周内我们将向所有人开放该功能。


如果你是互联网用户,通过浏览器等客户端与网站和 API 交互,那么这份公告又意味着什么呢?从今天开始,你可以使用Chrome Canary通过 HTTP/3 与 Cloudflare 和其他服务器交互。如果你想用命令行客户端的人,curl也提供了对 HTTP/3 的支持。后文将介绍如何通过 HTTP/3 使用 Chrome 和 curl。


母鸡和鸡蛋

互联网的标准创新一直举步维艰,这是一个先有鸡还是先有蛋的问题:是服务器先支持新标准(例如 Cloudflare 或其大型响应数据源),还是客户端先支持(例如浏览器和操作系统等)呢?连接的两端都需要支持新的通信协议才能正常工作。


Cloudflare 推动 Web 标准发展的历史由来已久,从HTTP/2(HTTP/3 之前的 HTTP 版本)到TLS 1.3,再到加密SNI等等。我们与志同道合的组织合作推动标准进化,这些组织都认同我们"希望帮助建立更好的互联网"的愿望。我们将 HTTP/3 推向主流的努力也是如此。


在 HTTP/3 标准的整个开发过程中,我们一直与行业合作伙伴紧密合作,以建立和验证与我们的边缘支持兼容的 HTTP/3 客户端支持。我们很高兴能与谷歌 Chrome 和 curl 合作,今天它们都可以通过 HTTP/3 向 Cloudflare edge 发出请求。Mozilla Firefox 预计也将为 nightly 版本提供支持。


总而言之,今天对于互联网用户来说是美好的一天。HTTP/3 的广泛普及将为所有人带来更快的 Web 体验,而今天的支持工作是朝着这一方向迈出的一大步。


更重要的是,今天也是互联网的好日子:Chrome、curl 和 Cloudflare,以及不久之后的 Mozilla 迅速推出了实验性但实用化的 HTTP/3 支持,表明互联网标准创建已经走入正轨。在互联网工程任务组的协调下,行业合作伙伴、竞争对手和其他主要利益相关者可以齐心协力制定让整个互联网,而不仅是少数巨头受益的标准。


Firefox 的 CTO Eric Rescorla 给出了很好的总结:“开发新的网络协议很困难,要使其走入正轨则需要每个人的共同努力。在过去的几年中,我们一直与 Cloudflare 和其他行业合作伙伴一起测试 TLS 1.3 到现在的 HTTP/3 和 QUIC。Cloudflare 对这些协议的服务端早期支持已帮助我们解决了客户端 Firefox 实现中的互操作性问题。我们期待这些合作能共同提高互联网的安全性和性能。”



发展历史

在深入探究 HTTP/3 之前,我们先来快速浏览一下 HTTP 多年来的发展,从而更好地理解为什么互联网需要 HTTP/3。


这一切始于 1996 年HTTP/1.0规范的发布,该规范定义了我们今天熟知的基本 HTTP 文本连线格式(为了方便论述,我假装 HTTP/0.9 不存在)。在 HTTP/1.0 中,客户端和服务器之间交换的每个请求/响应都会创建一个新的 TCP 连接,这意味着所有 TCP/TLS 握手均在每个请求之前完成,因此所有请求都会产生延迟。



更糟糕的是,TCP 不是在建立连接后尽快发送所有未完成的数据,而需要“慢启动”的预热时间,这使 TCP 拥塞控制算法能够随时确定可以传输的数据量,防止网络路径发生拥塞,并避免将无法处理的数据包都堆到网络中。但是,由于新连接必须经过缓慢的启动过程,因此它们无法立即使用所有可用的网络带宽。


几年后,HTTP 规范的HTTP/1.1修订版试图引入“保持活动”连接的概念来解决这些问题,它允许客户端复用 TCP 连接,从而分摊了建立初始连接和针对多个请求缓慢启动的成本。但这不是灵丹妙药,尽管多个请求可以共享同一个连接,但它们仍需逐个序列化它们,因此任意时点上客户端和服务器只能为每个连接执行一次请求/响应交换。


随着网络的发展,多年来网站所需资源(CSS、JavaScript 和图像等)不断增长,浏览器在获取和呈现网页时需要越来越多的并发性。但由于 HTTP/1.1 只允许客户端同时进行一次 HTTP 请求/响应交换,因此在网络层上获得并发能力的唯一方法是并行使用多个 TCP 连接到同一来源,代价就是牺牲了活动连接的大多数好处。尽管连接仍会在一定程度上(但程度不大)被复用,但我们又回到了起点。


十多年过去了,SPDY 和HTTP/2终于相继诞生;后者率先引入了 HTTP“流”的概念:这是一种抽象概念,允许 HTTP 实现将不同的 HTTP 交换并发地复用到同一 TCP 连接上, 使浏览器更高效地复用 TCP 连接。



但这也不是灵丹妙药!HTTP/2 解决了最初的问题——单个 TCP 连接的使用效率低——因为现在可以通过同一连接同时传输多个请求/响应。但是,即使只有单个请求丢失数据,所有请求和响应也会同样受到数据包丢失(比如因为网络拥塞)的影响。这是因为尽管 HTTP/2 层可以在不同的流上隔离不同的 HTTP 交换,但是 TCP 不了解这种抽象,并且后者所看到的只是字节流,没有特殊含义。


TCP 的作用是以正确的顺序从一个端点到另一端点传递整个字节流。当承载某些字节的 TCP 数据包在网络路径上丢失时将在流中造成间隙,并且 TCP 需要在检测到丢失时重新发送受影响的数据包来弥补这一间隙。这样做时,即使丢失数据之后的数据属于完全不同的 HTTP 请求,自己也根本没有丢失,也能正常传递成功,它们还是不能正常传递给应用程序。因此它们只能毫无必要地产生延迟,因为 TCP 无法知道应用程序缺少了丢失的数据包时能否处理后面的数据。这个问题称为“行首阻塞”。


了解 HTTP/3

这就是 HTTP/3 的用武之地:它不是使用 TCP 作为会话的传输层,而是使用QUIC(一种新的互联网传输协议)。该协议率先在传输层将流作为一等公民引入。多个 QUIC 流共享相同的 QUIC 连接,因此不需要额外的握手和慢启动来创建新的 QUIC 流。但 QUIC 流是独立交付的,因此在大多数情况下,只影响一个流的丢包不会影响其他流。这是因为 QUIC 数据包封装在 UDP 数据报的顶部。


与 TCP 相比,使用 UDP 可以提供更大的灵活性,并且可以使 QUIC 实现完全存在于用户空间中——协议实现的更新不像 TCP 那样依赖操作系统的更新。借助 QUIC,可以将 HTTP 级别的流简单地映射到 QUIC 流的顶部,从而在享受 HTTP/2 所有好处的同时避免了行首阻塞。


QUIC 还结合了典型的 3 向 TCP 握手和 TLS 1.3 的握手。结合这些步骤意味着加密和身份验证能够默认提供,并且还可以更快地建立连接。换句话说,即使 HTTP 会话中的初始请求需要新的 QUIC 连接,在数据开始流动之前的等候延迟也比使用 TLS 的 TCP 要低。



但为什么不在 QUIC 上使用 HTTP/2,而要创建一个全新的 HTTP 版本呢?毕竟 HTTP/2 还提供了流多路复用功能。事实证明这样做比想象的复杂许多。


确实可以轻松地将某些 HTTP/2 功能映射到 QUIC 上,但并非所有功能都能如此。特别是一种称为HPACK的 HTTP/2 标头压缩方案,在很大程度上取决于将不同的 HTTP 请求和响应传递到端点的顺序。QUIC 强制执行单个流中字节的传递顺序,但不保证不同流之间的顺序。


此行为需要创建一个称为 QPACK 的新 HTTP 标头压缩方案,它可以解决问题,但需要更改 HTTP 映射。另外,QUIC 本身已经提供了 HTTP/2 的某些功能(例如按流区分的流控制),因此我们从 HTTP/3 中删除了这些功能,从而消除了协议中不必要的复杂性。


HTTP/3,由美味的蛋饼(quiche)驱动

QUIC 和 HTTP/3 是非常令人兴奋的标准,有望解决以前标准的诸多缺点,并开创了网络性能的新纪元。那么我们是如何从令人兴奋的标准文档发展出可行的实现的呢?


Cloudflare 的 QUIC 和 HTTP/3 支持由 quiche 提供支持,这是我们自己用 Rust 编写的开源实现



你可以在GitHub上找到它。


我们在几个月前发布了 quiche,此后在已有的 QUIC 支持基础上增加了对 HTTP/3 协议的支持。我们的设计使 quiche 可以用于实现 HTTP/3 客户端和服务器,或仅用于普通的 QUIC 服务器实现。


如何为我的域启用 HTTP/3?

如上所述,我们已经开始为注册了等候名单的客户提供服务。如果你在名单上,并且已经收到邮件通知,表示现在可以为你的网站启用该功能,则只需转到 Cloudflare 仪表板,然后手动从“Network”选项卡启用此开关:



我们希望在不久的将来向所有客户提供 HTTP/3 功能。启用后,你可以通过多种方式尝试 HTTP/3:


使用谷歌 Chrome 作为 HTTP/3 客户端

为了使用 Chrome 浏览器通过 HTTP/3 连接到你的网站,你首先需要下载并安装最新的Canary版本。然后使用“–enable-quic”和“–quic-version=h3-23”命令行参数启动 Chrome Canary。


使用必需的参数启动 Chrome 后,你只需在地址栏中输入你的域,然后查看它是否已通过 HTTP/3 加载(你可以使用 Chrome 开发人员工具中的“Network”选项卡来检查所使用的协议版本)。请注意,由于浏览器和服务器之间协商 HTTP/3 的方式,HTTP/3 可能不会用于到域的前几个连接,因此你应该尝试重新加载几次页面。


如果这看起来太复杂了,但也请放心,因为随着时间的流逝,Chrome 对 HTTP/3 的支持将变得更加稳定,启用 HTTP/3 将会变得更加容易。


这是通过 HTTP/3 浏览此博客时,开发人员工具中的“Network”选项卡显示的内容:



请注意,由于 Chrome 对 HTTP/3 支持的实验性质,该协议在开发人员工具中实际上被标识为“ http2+quic/99”,但请不要误解,它就是 HTTP/3。


使用 curl

curl命令行工具也支持 HTTP/3 实验功能。你需要从 git 下载最新版本,并按照启用 HTTP/3 支持的说明操作。


如果你运行的是 macOS,我们还可以通过 Homebrew 轻松安装带有 HTTP/3 的 curl 版本:


 % brew install --HEAD -s https://raw.githubusercontent.com/cloudflare/homebrew-cloudflare/master/curl.rb
复制代码


为了执行 HTTP/3 请求,你需要做的就是将“–http3”命令行标志添加到普通 curl 命令中:


 % ./curl -I https://blog.cloudflare.com/ --http3HTTP/3 200date: Tue, 17 Sep 2019 12:27:07 GMTcontent-type: text/html; charset=utf-8set-cookie: __cfduid=d3fc7b95edd40bc69c7d894d296564df31568723227; expires=Wed, 16-Sep-20 12:27:07 GMT; path=/; domain=.blog.cloudflare.com; HttpOnly; Securex-powered-by: Expresscache-control: public, max-age=60vary: Accept-Encodingcf-cache-status: HITage: 57expires: Tue, 17 Sep 2019 12:28:07 GMTalt-svc: h3-23=":443"; ma=86400expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"server: cloudflarecf-ray: 517b128df871bfe3-MAN
复制代码


使用 quiche 的 http3-client

最后,我们还提供了一个基于 quiche 构建的 HTTP/3 命令行客户端示例(也有命令行服务器),你可以用它来试用 HTTP/3。


要运行它,请首先克隆 quiche 的 GitHub 存储库:


$ git clone --recursive https://github.com/cloudflare/quiche
复制代码


然后构建它。首先你需要一个正常工作的 Rust 和 Cargo 环境(我们建议使用 rustup 轻松设置一个正常的Rust开发环境


$ cargo build --examples
复制代码


最后你就可以执行 HTTP/3 请求了:


$ RUST_LOG=info target/debug/examples/http3-client https://blog.cloudflare.com/
复制代码


接下来有什么安排?

在接下来的几个月中,我们将致力于改进和优化 QUIC 和 HTTP/3 实现,最终将使所有人都可以启用这一新功能,不用再排队等候。随着标准的发展,我们也将继续更新实现,可能会在草案进化为标准之外引入重大更新


以下是我们路线图上一些特别令人兴奋的功能:


连接迁移

QUIC 带来的一项重要功能是在不同的网络(例如你早上上班时在家中的 WiFi 网络和运营商移动网络)之间进行无缝、透明的连接迁移,而无需创建全新的连接。



此功能需要对我们的基础架构进行一些额外更改,但是我们非常期待将来向客户提供这项改进。


零往返时间恢复

与 TLS 1.3 一样,QUIC 支持一种操作模式,允许客户端在连接握手完成之前开始发送HTTP请求。我们尚未在 QUIC 部署中支持此功能,但就像我们在 TLS 1.3 支持中做到的那样,我们也将努力实现此项改进。


HTTP/3:它面世了!

我们很高兴能够为 HTTP/3 提供支持,并让客户在 QUIC 和 HTTP/3 的标准化推进阶段进行尝试。我们将继续与其他组织(包括谷歌和 Mozilla)合作,以最终确定 QUIC 和 HTTP/3 标准并鼓励业界广泛应用。


HTTP/3 将为所有人提供更快、更可靠并更安全的 Web 体验。


英文原文:


https://blog.cloudflare.com/http3-the-past-present-and-future/


2019 年 10 月 10 日 18:004246

评论 3 条评论

发布
用户头像
真是个软文,一点干货都没有
2020 年 08 月 30 日 14:49
回复
用户头像
谢谢分享!
2020 年 08 月 26 日 23:38
回复
用户头像
复用而且不影响是关键
2019 年 10 月 11 日 09:57
回复
没有更多了
发现更多内容

架构师训练营-学习总结-第一周

ashuai1106

学习 架构师 极客大学架构师训练营

Week1命题作业

星河寒水

部署图 时序图 组件图 用例图

【架构师训练营】1 - 食堂就餐卡系统设计

悬浮

架构 UML 部署图

架构师训练营 No.1 周作业

连增申

【架构】— 一个简单系统的UML模型

不二架构

极客大学架构师训练营 UML 架构总结

食堂就餐卡系统设计

Thrine

为什么建立自己的规则很重要

Neco.W

自我管理 行动派 执行力

食堂就餐卡系统设计

Linkin

架构师训练营第一周总结

Kiroro

架构师成长心得

熊威

食堂就餐卡系统设计

Kiroro

UML作业

王志祥

极客大学架构师训练营

食堂就餐卡系统设计

Young

UML用例图组件图部署图

熊威

低调的网易又要上市了

池建强

创业 网易 慢公司

架构师训练营第一周(总结)

任鉴非

架构建模总结

任鉴非

学习总结--Week1

吴炳华

极客大学架构师训练营

食堂就餐卡系统设计

慢慢来的比较快

第一周学习总结

Young

老当益壮的 Servlet

侯树成

Java Java 25 周年 Servlet

架构师训练营作业一:食堂就餐卡系统设计

sunnywhy

第二章.软件架构设计

西柚

架构师训练营第1周_学习总结

chinsun1

架构总结

一篇文章快速搞懂 Atomic(原子整数/原子引用/原子数组/LongAdder)

学习Java的小姐姐

Java 并发编程 并发 synchronized Atomic

架构师训练营Week1总结

sunnywhy

孤狼王兴 | 互联网大佬往事

刘燕

AI 企业管理 美团

人工智能之机械基

码农神说

人工智能 程序员 加班

week1学习总结

慢慢来的比较快

架构师训练营-作业-第一讲

吕浩

极客大学架构师训练营

架构作业-UML图

铁血杰克

Hummer 轻量级跨端技术框架详解及实战

Hummer 轻量级跨端技术框架详解及实战

HTTP/3的过去、现在和未来-InfoQ