从HTTP到HTTP/3的发展简史

虽然 HTTP/3 规范仍处于起草阶段，但最新版本的 Chrome 浏览器已经默认支持它了。Chrome 拥有约 70％的浏览器市场份额，因此，能够说 HTTP/3 已经进入主流世界。

这一基础协议的最新修订版旨在让 Web 更加高效、安全并缩短内容交付延迟。从某些角度来讲，它是 HTTP2 的完善：经过使用新的专用协议 QUIC 替换基础 TCP 协议来解决和以前相似的目标。

想要弄明白 QUIC 的优势，最好的办法是讲清楚 TCP 做为 HTTP 请求的传输方式有哪些不足之处。

为此，咱们将从头开始细细道来。

1. HTTP：起源

1991 年，当蒂姆·伯纳斯·李爵士设计出一个简单的单行超文本交换协议时，TCP 已是一个古老而可靠的协议了。前者的原始定义文档（也就是后人熟知的 HTTP 0.9）特别提到 TCP 是首选的（尽管并不是惟一的）传输协议：

注意：HTTP 当前运行在 TCP 上，但也能够运行在任何面向链接的服务上。

固然，HTTP 的这个概念验证版本与咱们如今所知道和喜欢的 HTTP 几乎没有类似之处。没有标头，也没有状态码。典型的请求只有GET/path而已。响应仅包含 HTML，且 TCP 链接关闭就会结束。

因为浏览器还没有流行，所以用户须要直接阅读 HTML。能够用它连接到其余资源，可是在这个 HTML 早期版本中存在的全部标签都不会异步请求其余资源。一个 HTTP 请求就传递了一个完整的、自给自足的页面。

2. HTTP/1.0 出现

在随后几年中，互联网迎来爆炸式的发展，尽管传输 HTML 仍然是 HTTP 的主要特点，但它逐渐发展成一种可扩展且灵活的通用协议。HTTP 的三大重要更新奠基了这一演变的基础：

• 方法的引入使客户能肯定其想要执行操做的类型。例如，引入 POST 是为了容许客户端将数据发送到服务器以处理和存储；

• 状态码为客户端提供了一种确认服务器已成功处理请求的方法——若是处理失败，则能够用它了解发生了哪一种错误；

• 标头增长了将结构化文本元数据附加到能够修改客户端或服务器行为的请求和响应上的功能。例如，编码和内容类型头使 HTTP 不只能够传输 HTML，还能够传输任何类型的负载。“压缩”标头容许客户端和服务器协商支持的压缩格式，从而减小了经过链接传输的数据量。

同时，HTML 也不断进化，支持了图像、样式和其余连接资源。

如今，浏览器须要执行多个请求来显示一个网页，而原始的“按请求链接”架构是作不到的。创建和终止 TCP 链接涉及大量的数据包来回交换，所以在延迟开销方面相对昂贵。网页不见得必定由单个文本文件组成，可是随着每页请求数量的增长，延迟也随之增长。

下图说明了每创建一个新的 TCP 链接涉及多少请求开销。

TCP 链接须要三个请求才能创建链接，四个请求能够彻底关闭。

人们建立了一个“链接”标头来解决这个问题。客户端发送带有“connection:keep-alive”标头的请求，以代表意图为后续请求保持 TCP 链接的打开状态。若是服务器理解此标头并赞成遵照该标头，则其响应还将包含“connection:keep-alive”标头。

这样，双方都保持 TCP 通道打开并使用它进行后续通讯，直到任何一方决定关闭它为止。随着 SSL/TLS 加密技术的发展，这一点变得更加剧要，由于协商加密算法和交换加密密钥须要在每一个链接上增长一个请求 / 响应周期。

单个 TCP 链接能够经过“connection:keep-alive”标头。

重用于多个请求当时，许多 HTTP 改进都是自发出现的。当流行的浏览器或服务器应用程序须要新的 HTTP 功能时，它们会本身实现该功能，并但愿其余各方也能效仿。具备讽刺意味的是，去中心化的 Web 须要一个中心化的管理机构来避免碎片化形成的不兼容问题。

该协议的最初建立者蒂姆·伯纳斯·李（TimBerners-Lee）意识到了这种危险，并于 1994 年成立了万维网联盟（W3C），该联盟与互联网工程任务组（IETF）一块儿致力于规范互联网的技术栈。做为为已有环境带来更多规范的第一步，他们记录了当时 HTTP 中最经常使用的一些功能，并将其命名为 HTTP/1.0 协议。

可是，因为这种“规范”描述的是多种多样的，一般在“实践”中用法不一致的技术，所以它从未得到过标准地位。相比之下，关于 HTTP 协议新版本的工做已经开始了。

3. HTTP/1.1 的标准化

HTTP/1.1 修复了 HTTP/1.0 的不一致之处，并调整了协议，使其在新的 Web 生态系统中具有更好的性能表现。新版引入的两个最关键的更改是默认使用持久 TCP 链接（保持活动状态）和 HTTP 管线化。

HTTP 管线化的意思就是客户端无需在发送后续 HTTP 请求以前等待服务器响应请求。此功能能够更有效地利用带宽并减小延迟，但它的改进空间甚至更大。HTTP 管线化仍要求服务器按照接收到的请求顺序进行响应，所以，若是管线化中的单个请求执行得很慢，则对客户端的全部后续响应都将相应地延迟下去。这个问题被称为线头阻塞。

因为首先请求了 large-picture.jpg，所以阻止了 style.css 的发布

在这个时候，Web 正在得到愈来愈多的交互功能。Web 2.0 指日可待，一些网页包含数十个甚至数百个外部资源。为解决线头阻塞，并下降页面加载速度，客户端会在每一个主机上创建多个 TCP 链接。固然，链接开销并无消失不见。实际上状况变得更糟了，由于愈来愈多的应用程序开始使用 SSL/TLS 加密 HTTP 通讯。所以，大多数浏览器都设置了最大可能同时链接数的限制，以寻求微妙的平衡。

许多较大的 Web 服务已经意识到，现有的限制对于其交互极为繁重的 Web 应用程序来讲太过严格，所以它们会经过多个域名分发其应用程序来“玩弄系统”。这种办法好歹起效了，可是解决方案根本谈不上优雅。

尽管存在一些缺点，可是 HTTP/1.0 和 HTTP/1.1 的简单性使它们得到了普遍的成功，而且十多年来，没有人认真地尝试过改变它们。

4. SPDY 和 HTTP/2

谷歌在 2008 年发布了 Chrome 浏览器，这种浏览器因其快速和创新而迅速流行。它使谷歌在互联网技术问题上得到了强大的话语权。在 2010 年代初期，谷歌在 Chrome 中增长了对其 Web 协议 SPDY 的支持。

HTTP/2 标准基于 SPDY，并进行了一些改进。HTTP/2 经过在单个打开的 TCP 链接上多路复用 HTTP 请求，解决了线头阻塞问题。这容许服务器以任何顺序响应请求，而后客户端能够在接收到响应时从新组合响应，从而在单个链接中加快整个交换的速度。

因为 HTTP/2 能够多路传输，所以在 large-picture.jpg 以前返回了 style.css

实际上，使用 HTTP/2 服务器甚至能够在请求以前就将资源提供给客户端！举个例子，若是服务器知道客户端极可能须要样式表来显示 HTML 页面，它能够将 CSS“推”到客户端，而无需等待相应的请求。虽然这从理论上讲是有益的，但此功能在实践中不多见，由于它须要服务器了解其服务的 HTML 结构，但这种状况不多发生。

除了请求正文之外，HTTP/2 还容许压缩请求标头，这进一步减小了经过网络传输的数据量。

HTTP/2 解决了 Web 上的许多问题，但不是所有。在 TCP 协议级别上仍然存在相似类型的线头问题，而 TCP 仍然是 Web 的基础构建块。当 TCP 数据包在传输过程当中丢失时，在服务器从新发送丢失的数据包以前，接收方没法确认传入的数据包。因为 TCP 在设计上不遵循 HTTP 之类的高级协议，所以单个丢失的数据包将阻塞全部进行中的 HTTP 请求的流，直到从新发送丢失的数据为止。这个问题在不可靠的链接上尤其突出，这在无处不在的移动设备时代并不罕见。

5. HTTP/3 革命

因为 HTTP/2 的问题不能仅靠应用程序层来解决，所以协议的新迭代必须更新传输层。可是，建立新的传输层协议并不是易事。传输协议须要硬件供应商的支持，而且须要大多数网络运营商的部署才能普及。因为此事涉及的成本和工做量，运营商们不肯进行更新。以 IPv6 为例：它是 24 年前推出的，但现在距离得到广泛支持还有很远的距离。

幸运的是还有另外一种选择。UDP 协议与 TCP 同样获得普遍支持，但前者足够简单，能够做为在其之上运行的自定义协议的基础。UDP 数据包是一劳永逸的：没有握手、持久链接或错误校订。HTTP3 背后的主要思想是放弃 TCP，转而使用基于 UDP 的 QUIC 协议。QUIC 以对 Web 环境有意义的方式添加了许多必要的功能（包括之前由 TCP 提供的功能，以及更多功能）。

与 HTTP2 在技术上容许未加密的通讯不一样，QUIC 严格要求加密后才能创建链接。此外，加密不只适用于 HTTP 负载，还适用于流经链接的全部数据，从而避免了一大堆安全问题。创建持久链接、协商加密协议，甚至发送第一批数据都被合并到 QUIC 中的单个请求 / 响应周期中，从而大大减小了链接等待时间。若是客户端具备本地缓存的密码参数，则能够经过简化的握手（0-RTT）从新创建与已知主机的链接。

为了解决传输级别的线头阻塞问题，经过 QUIC 链接传输的数据被分为一些流。流是持久性 QUIC 链接中短暂、独立的“子链接”。每一个流都处理本身的错误纠正和传递保证，但使用链接全局压缩和加密属性。每一个客户端发起的 HTTP 请求都在单独的流上运行，所以丢失数据包不会影响其余流/请求的数据传输。

HTTP/3 将链接分为单独的流UDP 是一种无状态协议（持久链接只是其之上的抽象），使 QUIC 可以支持一些很大程度上忽略了数据包传递复杂性的功能。例如，从理论上讲，客户端更改其 IP 地址中间链接（例如智能手机从移动网络跳转到家庭 wifi）时不该中断链接，由于该协议容许在不一样 IP 地址之间迁移而无需从新链接。

QUIC 协议的全部现有实现当前都在用户空间，而不是 OS 内核中运行。因为客户端（例如浏览器）和服务器的更新一般比操做系统内核更新的频率更高，所以人们但愿能够藉此更快地采用新功能。

6. HTTP/3 存在的问题

我认为 HTTP/3 标准虽然是向更快、更安全的互联网迈出的一大步，但它并不完美。它的某些问题是由其新颖性引发的，而其余一些问题彷佛是该协议固有的。

TCP 协议已经存在了很长时间，对于路由器来讲很容易理解。它具备清晰的未加密标记（用于创建和关闭链接），可用于跟踪和控制现有会话。在网络硬件学会了解新协议以前，它将把 QUIC 流量简单地看做独立的 UDP 数据包流，这将使网络配置更加棘手。

从客户端缓存“恢复”链接的能力使该协议很容易遭受重播***：在某些状况下，恶意***者能够从新发送之前捕获的数据包，这些数据包将被服务器解释为有效的，来自受害者的。像那些提供静态内容的 Web 服务器同样，许多 Web 服务器不会受到此类***的伤害。对于身处易受***环境的应用程序来讲，必需要记住禁用 0-RTT 功能。

这就是 HTTP 到今天为止的故事。我认为 HTTP/3 是向前迈出的一大步，而且固然但愿 HTTP/3 在不久的未来会被普遍采用。

原文连接：https://scorpil.com/post/the-long-road-to-http3/

做者 | Scorpil译者 | 王强策划 | 万佳 | 文章转自：InfoQ