2020 Google开发者大会重磅开幕 了解详情

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/ --http3
HTTP/3 200
date: Tue, 17 Sep 2019 12:27:07 GMT
content-type: text/html; charset=utf-8
set-cookie: __cfduid=d3fc7b95edd40bc69c7d894d296564df31568723227; expires=Wed, 16-Sep-20 12:27:07 GMT; path=/; domain=.blog.cloudflare.com; HttpOnly; Secure
x-powered-by: Express
cache-control: public, max-age=60
vary: Accept-Encoding
cf-cache-status: HIT
age: 57
expires: Tue, 17 Sep 2019 12:28:07 GMT
alt-svc: h3-23=":443"; ma=86400
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-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:00 3957

评论 3 条评论

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

架构师第二周作业

悠哉

架构师训练营第 1 期

开放的是金融服务 必须确保持牌经营

CECBC区块链专委会

金融 银行

数据结构与算法:递归

Java架构师迁哥

Java 编程 程序员 算法

小白也能看懂的REDIS教学基础篇——REDIS基础数据结构

云流

数据库 redis Java web

linux虚拟摄像头vivid配置

良知犹存

Linux 虚拟摄像

架构1期-第二周作业一

道长

架构师训练营第 1 期

第二周作业二-学习总结

道长

架构师训练营第 1 期

第二周学习总结

饭桶

2020年高频Java面试题集锦(含答案),让你的面试之路畅通无阻!

Geek_71bb95

Java 程序员 面试 编程语言

专升本啦!!!

迷羊

UML练习2

何毅曦

食堂就餐卡系统设计

谭明华

架构师训练营第 1 期

第二周 作业二:框架设计学习总结【未陌】

a d e

设计模式 架构设计

听说有人不了解柔性数组

C语言与CPP编程

程序员 数组 编程语言 C语言

架构师训练营 - week1 - 个人学习心得总结

谭明华

最新整理国内知名大厂7篇Java岗面试真题,奥利给!

Java架构师迁哥

极客时间架构师培训 1 期 - 第 2 周作业

Kaven

腾讯某Java程序员为了肝出《300页图解网络知识》+《计算机底层操作系统》超全教程差点猝死!

Geek_71bb95

Java 程序员 面试 编程语言 操作系统

周总结二

何毅曦

框架设计-第二周作业

睁眼看世界

软件设计原则 架构师训练营第一期

架构师训练营 1 期 -- 第二周

小河

架构师训练营第 1 期

第二周作业

华美而火锅

const关键字应用总结

C语言与CPP编程

程序员 编程语言 C语言

C语言/C++基本语句编程风格

C语言与CPP编程

程序员 编程语言 C语言

区块链+跨境贸易:让跨境数据高效共享可信

CECBC区块链专委会

区块链 跨境贸易 跨境电子商务

超全算法笔试模拟题精解合集,这份《程序员面试宝典》简直太牛了

Geek_71bb95

Java 数据结构 面试 算法 编程语言

第二周 作业一【未陌】

a d e

设计模式 架构设计原则 基本原则

架构师第二周总结

悠哉

原来我写的软件里面都是臭味 - 架构师训练营第 1 期 - 第二周总结

Todd-Lee

架构师训练营第一期

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

Gosling

架构师训练营第 1 期

架构师训练营 - week2 - 个人学习心得总结

谭明华

架构师训练营第 1 期 架构师训练营第一期

2020中国技术力量年度榜单盛典

2020中国技术力量年度榜单盛典

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