HTTP 3 发展历史和早期采用者

大家好，如果您还对HTTP 3 发展历史和早期采用者不太了解，没有关系，今天就由本站为大家分享HTTP 3 发展历史和早期采用者的知识，包括的问题都会给大家分析到，还望可以解决大家的问题，下面我们就开始吧！

首先我们先介绍一下HTTP这些年的发展，以便更好的理解HTTP/3。

HTTP/1.0

HTTP协议起源于1996年，这一年发布了HTTP/1.0规范（0.x版本忽略），它定义了我们今天常见的基本HTTP文本规范定义。在HTTP/1.0中，定义客户端和服务器之间的每次请求/响应交换都必须创建一个新的TCP连接，因此每次请求都需要众所周知的“三向握手、四向挥手”过程。因此请求将不可避免地被延迟。例如，一个典型的HTTP/TLS流程如下所示：

此外，为了避免未处理的数据包淹没网络，TCP协议对已建立的连接使用称为“慢启动”的预热暂停期，以确定TCP拥塞控制算法可以传输的数据。量，而不是在连接建立后尽快发送所有未完成的数据。由于每个新连接都必须经历这个缓慢的启动过程，因此它也成为网络性能的瓶颈。

HTTP/1.1 保持活动状态

随后的HTTP/1.1版本引入了“keep-alive”连接方法来解决这些问题。通过keep-alive技术，客户端可以复用TCP连接，而不必每次都重新建立TCP连接，从而解决了初次建立连接和连接速度慢的问题。但这并不能从本质上解决问题，虽然多个请求可以共享同一个连接，但它们仍然必须一个接一个地序列化，因此客户端和服务器在任何给定时间只能对每个连接执行一个请求/响应交换。

随着网络和Web技术的发展，每个网站所需的资源（CSS、JS脚本、图片、视频等）增加，浏览器在获取和渲染网页时对并发的需求越来越迫切。然而，由于HTTP/1.1 只允许客户端一次只能进行一次HTTP 请求/响应交换，因此在网络层获得并发的唯一方法是并行使用多个TCP 连接，这样就无法享受保持-活生生的技术优势。

HTTP/2 SPDY

十多年后，SPDY出现，然后是HTTP/2规范。它首先引入了HTTP流的概念。通过抽象HTTP 实现以同时将不同的HTTP 交换复用到同一个TCP 连接上，浏览器可以更有效地重用TCP 连接。

HTTP/2解决了单个TCP连接使用效率低下的问题，可以通过同一个连接同时传输多个请求/响应。但如果传输过程中出现数据丢包，即使丢失的数据只涉及单个请求，所有的请求和响应都会受到丢包的影响，需要重传。因为虽然HTTP/2 可以隔离不同流上的不同HTTP 交换，但底层TCP 无法区分它们。 TCP 所能看到的只是一个没有任何标志的字节流。

TCP 的作用是将整个字节流以正确的顺序从一个端点传送到另一端点。当携带某些字节的TCP 数据包在网络路径上丢失时，会在流中产生间隙，并且TCP 需要在检测到丢失时通过重新发送受影响的数据包来填充该间隙。这样，即使丢包后没有丢包，是一个完全独立的HTTP请求，该数据包之后成功传输的数据包也无法传递到应用层。因此，这最终也会导致他们经历不必要的延误。这个问题称为TCP 队头阻塞。

为了解决队头阻塞问题，HTTP/2中还引入了复用技术，将TCP流可以传输的数据分成若干个消息，每个消息又分为最小的二进制帧，这样即使一个请求被阻塞，也不会影响其他请求，如上图中的第四种情况。

HTTP/3 QUIC

当然，这些改进TCP的方案只能部分解决问题，才能从根本上彻底解决问题。那么底层的TCP协议就需要彻底更换。这是Google探索多年的基于UDP的QUIC协议，也是HTTP/3的基础。 QUIC协议使用数据流作为基本传输层。 QUIC 流共享相同的QUIC 连接，并且需要额外的握手和慢速启动来创建新的QUIC 流。底层采用UDP协议，QUIC数据包封装在UDP数据报中。在顶部，实现了QUIC流的独立交付。因此在大多数情况下，影响一个流的丢包不会影响其他流。

使用UDP 比TCP 提供更大的灵活性，并允许QUIC 实现完全存在于用户空间中。协议实现的更新不再依赖于操作系统的更新。使用QUIC，HTTP 级流可以简单地映射到QUIC 流的标头，继承HTTP/2 的所有优点，而不会出现队头阻塞问题。

QUIC 还将典型的3 路TCP 握手与TLS 1.3 握手相结合。这默认提供加密和身份验证，并加快连接建立速度。尽管HTTP 会话中的初始请求需要新的QUIC 连接，但数据开始流动之前的等待时间很短。

HTTP/3 的使用

乳蛋饼框架

为了支持HTTP/3 的推广，Cloudflare 使用Rust 开发并开源了一个HTTP/3 和QUI 应用框架，并且还为该应用使用了一个非常好吃的名字quiche（乳蛋饼）和logo，想必是为了尽快吸引人尽可能品尝用HTTP/3 制作的美味食物。

quiche 的源代码托管在github (github:/cloudflare/quiche) 上。克隆源代码后，可以通过cargo进行编译（注意需要rust 1.38及更高版本，BoringSSL及其windows版本NASM）：

货物构建示例

Quiche还提供了基于docker的实验环境，包括http3-client、http3-server、客户端和服务器。使用方法如下：

码头编译：

docker build -t cloudflare-quiche 。

发出HTTP/3 请求

docker run -it cloudflare-quiche http3-客户端URL

网站激活

目前，Cloudflare 的选择性开放客户可以通过简单的手动设置，通过手动打开Cloudflare 仪表板上“网络”选项卡中的开关来启用HTTP/3 功能：

客户使用

目前，知名浏览器Google Chrome和Firefox已经实验性地提供了对HTTP/3的支持。 Chrome 已在Canary 中使用，Firefox 将在Nightly 中得到正式支持。

Chrome浏览器：首先您需要下载并安装最新的Canary版本。然后，通过设置以下命令行参数来启动Chrome Canary：

'--enable-quic' 和'--quic-version=h3-23'

然后将支持HTTP/3，并且可以通过Chrome 开发者工具中的“网络”选项卡检查所使用的协议版本：

请注意，协议类型为“http2+quic/99”，即Http3。

使用卷曲

最新版本的curl 7.66 还添加了对HTTP/3 的实验性支持。我们可以下载编译试用一下，这个在之前的冲冲文章中已经介绍过。

要使用HTTP/3，您需要使用新添加的“--http3”标志发出请求：

卷曲-I URL --http3