概述

http/2 即 http 2.0 版本，是目前当前的 http 1.1 版本的优化版本。http/2 通过报头帧压缩、连接复用以及服务端推送来提高网站性能。

http 协议是应用最广泛、采用最多的一个互联网应用协议，它最初的设计目的就是简单：最初的互联网就是一些文本，既没有图像也没有 css、JavaScript。而到了今天，平均每个网页就包含 100 多个下载资源，大小约为 2,500 KB。总传输大小自 2012 年 5 月以来增长了 250%，这种持续增长没有出现缓和迹象。

http 协议的简单也带来了相应的性能问题：客户端需要使用多个连接才能实现并发和缩短延迟；http/1.x 不会压缩请求和响应标头，从而导致不必要的网络流量；http/1.x 不支持有效的资源优先级，致使底层 TCP 连接的利用率低下等等。

而 http/2 则从以下几个方面来解决这些问题：HTTP/2 通过支持标头字段压缩和在同一连接上进行多个并发交换，让应用更有效地利用网络资源，减少感知的延迟时间。具体来说，它可以对同一连接上的请求和响应消息进行交错发送并为 HTTP 标头字段使用有效编码。 HTTP/2 还允许为请求设置优先级，让更重要的请求更快速地完成，从而进一步提升性能。出台的协议对网络更加友好，因为与 HTTP/1.x 相比，可以使用更少的 TCP 连接。这意味着与其他流的竞争减小，并且连接的持续时间变长，这些特性反过来提高了可用网络容量的利用率。 最后，HTTP/2 还可以通过使用二进制消息分帧对消息进行更高效的处理。

需要注意的是，http/2 仍是对之前 HTTP 标准的扩展而非替代。 http 的应用语义不变，提供的功能不变，http 方法、状态代码、URI 和标头字段等这些核心概念也不变。这些方面的变化都不在 http/2 考虑之列。 虽然高级 API 保持不变，仍有必要了解低级变更如何解决了之前协议的性能限制。

特性介绍

二进制分帧

二进制分帧是 http/2 性能增强的核心，它定义了如何封装 HTTP 消息并在客户端与服务器之间传输。二进制分帧的就是将 http 报文分成 header 和 body 帧，然后用二进制对其进行编码。 二进制分帧

在 http/1.x 版本中，使用换行符作为纯文本的分割符，而 HTTP/2 将所有传输的信息分割为更小的消息和帧，并采用二进制格式对它们编码。这样一来，客户端和服务器为了相互理解，都必须都使用新的二进制编码机制：HTTP/1.x 客户端无法理解只支持 HTTP/2 的服务器，反之亦然。不过不要紧，现有的应用不必担心这些变化，因为客户端和服务器会替我们完成必要的分帧工作。

数据流、消息和帧

新的二进制分帧机制改变了客户端与服务器之间交换数据的方式。 为了说明这个过程，我们需要了解 HTTP/2 的三个概念：

  • 数据流：已建立的连接内的双向字节流，可以承载一条或多条消息。
  • 消息：与逻辑请求或响应消息对应的完整的一系列帧。
  • 帧：HTTP/2 通信的最小单位，每个帧都包含帧头，至少也会标识出当前帧所属的数据流。

这些概念的关系总结如下：

  • 所有通信都在一个 TCP 连接上完成，此连接可以承载任意数量的双向数据流。
  • 每个数据流都有一个唯一的标识符和可选的优先级信息，用于承载双向消息。
  • 每条消息都是一条逻辑 HTTP 消息（例如请求或响应），包含一个或多个帧。
  • 帧是最小的通信单位，承载着特定类型的数据，例如 HTTP 标头、消息负载，等等。 来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装。

流、消息、帧

简而言之，HTTP/2 将 HTTP 协议通信分解为二进制编码帧的交换，这些帧对应着特定数据流中的消息。所有这些都在一个 TCP 连接内复用。这种传输方式与 tcp 传输更类似了，这也是 HTTP/2 协议所有其他功能和性能优化的基础。

请求/响应复用

在 HTTP/1.x 中，如果客户端要想发起多个并行请求以提升性能，则必须使用多个 TCP 连接。因为 HTTP/1.x 中，每个请求/响应都在一条单独的 tcp 连接中传输，该模型可以保证每个连接每次只交付一个响应（响应排队）。更糟糕的是，这种模型也会导致队首阻塞，从而造成底层 TCP 连接的效率低下。

HTTP/2 中新的二进制分帧层突破了这些限制，实现了完整的请求和响应复用：客户端和服务器可以将 HTTP 消息分解为互不依赖的帧，然后交错发送，最后再在另一端把它们重新组装起来。

将 HTTP 消息分解为独立的帧，交错发送，然后在另一端重新组装是 HTTP 2 最重要的一项增强。事实上，这个机制会在整个网络技术栈中引发一系列连锁反应，从而带来巨大的性能提升，让我们可以：

  • 并行交错地发送多个请求，请求之间互不影响。
  • 并行交错地发送多个响应，响应之间互不干扰。
  • 使用一个连接并行发送多个请求和响应。
  • 不必再为绕过 HTTP/1.x 限制而做很多工作（例如级联文件、image sprites 和域名分片等）
  • 消除不必要的延迟和提高现有网络容量的利用率，从而减少页面加载时间。

HTTP/2 中的新二进制分帧层解决了 HTTP/1.x 中存在的队首阻塞问题，也消除了并行处理和发送请求及响应时对多个连接的依赖。结果，应用速度更快、开发更简单、部署成本更低。

数据流优先级

将 HTTP 消息分解为很多独立的帧之后，我们就可以复用多个数据流中的帧，客户端和服务器交错发送和传输这些帧的顺序就成为关键的性能决定因素。为了做到这一点，HTTP/2 标准允许每个数据流都有一个关联的权重和依赖关系：

  • 可以向每个数据流分配一个介于 1 至 256 之间的整数。
  • 每个数据流与其他数据流之间可以存在显式依赖关系。

数据流依赖关系和权重的组合让客户端可以构建和传递“优先级树”，表明它倾向于如何接收响应。反过来，服务器可以使用此信息通过控制 CPU、内存和其他资源的分配设定数据流处理的优先级，在资源数据可用之后，带宽分配可以确保将高优先级响应以最优方式传输至客户端。

HTTP/2 内的数据流依赖关系通过将另一个数据流的唯一标识符作为父项引用进行声明；如果忽略标识符，相应数据流将依赖于“根数据流”。声明数据流依赖关系指出，应尽可能先向父数据流分配资源，然后再向其依赖项分配资源。共享相同父项的数据流（即，同级数据流）应按其权重比例分配资源。 需要注意的是，数据流依赖关系和权重表示传输优先级，而不是要求，因此不能保证特定的处理或传输顺序。即，客户端无法强制服务器通过数据流优先级以特定顺序处理数据流。 尽管这看起来违反直觉，但却是一种必要行为。 我们不希望在优先级较高的资源受到阻止时，还阻止服务器处理优先级较低的资源。

服务器推送

HTTP/2 新增的另一个强大的新功能是，服务器可以对一个客户端请求发送多个响应。 换句话说，除了对最初请求的响应外，服务器还可以向客户端推送额外资源），而无需客户端明确地请求。 服务器推送

注：HTTP/2 打破了严格的请求-响应语义，支持一对多和服务器发起的推送工作流，在浏览器内外开启了全新的互动可能性。这是一项使能功能，对我们思考协议、协议用途和使用方式具有重要的长期影响。

为什么在浏览器中需要一种此类机制呢？一个典型的网络应用包含多种资源，客户端需要检查服务器提供的文档才能逐个找到它们。那为什么不让服务器提前推送这些资源，从而减少额外的延迟时间呢？服务器已经知道客户端下一步要请求什么资源，这时候服务器推送即可派上用场。

事实上，如果您在网页中内联过 CSS、JavaScript，或者通过数据 URI 内联过其他资产，那么您就已经亲身体验过服务器推送了。对于将资源手动内联到文档中的过程，我们实际上是在将资源推送给客户端，而不是等待客户端请求。使用 HTTP/2，我们不仅可以实现相同结果，还会获得其他性能优势。 推送资源可以进行以下处理：

  • 由客户端缓存
  • 在不同页面之间重用
  • 与其他资源一起复用
  • 由服务器设定优先级
  • 被客户端拒绝

PUSH_PROMISE 101

所有服务器推送数据流都由 PUSH_PROMISE 帧发起，表明了服务器向客户端推送所述资源的意图，并且需要先于请求推送资源的响应数据传输。这种传输顺序非常重要：客户端需要了解服务器打算推送哪些资源，以免为这些资源创建重复请求。满足此要求的最简单策略是先于父响应（即，DATA 帧）发送所有 PUSH_PROMISE 帧，其中包含所承诺资源的 HTTP 标头。

在客户端接收到 PUSH_PROMISE 帧后，它可以根据自身情况选择拒绝数据流（通过 RST_STREAM 帧）。 （如果资源已经位于缓存中，可能会发生这种情况。） 这是一个相对于 HTTP/1.x 的重要提升。 相比之下，使用资源内联（一种受欢迎的 HTTP/1.x“优化”）等同于“强制推送”：客户端无法选择拒绝、取消或单独处理内联的资源。

使用 HTTP/2，客户端仍然完全掌控服务器推送的使用方式。客户端可以限制并行推送的数据流数量；调整初始的流控制窗口以控制在数据流首次打开时推送的数据量；或完全停用服务器推送。这些优先级在 HTTP/2 连接开始时通过 SETTINGS 帧传输，可能随时更新。

推送的每个资源都是一个数据流，与内嵌资源不同，客户端可以对推送的资源逐一复用、设定优先级和处理。 浏览器强制执行的唯一安全限制是，推送的资源必须符合原点相同这一政策：服务器对所提供内容必须具有权威性。

标头压缩

每个 HTTP 传输都承载一组标头，这些标头说明了传输的资源及其属性。 在 HTTP/1.x 中，此元数据始终以纯文本形式，通常会给每个传输增加 500–800 字节的开销。如果使用 HTTP Cookie，增加的开销有时会达到上千字节。（请参阅测量和控制协议开销。）为了减少此开销和提升性能，HTTP/2 使用 HPACK 压缩格式压缩请求和响应标头元数据，这种格式采用两种简单但是强大的技术：

  • 这种格式支持通过静态 Huffman 代码对传输的标头字段进行编码，从而减小了各个传输的大小。
  • 这种格式要求客户端和服务器同时维护和更新一个包含之前见过的标头字段的索引列表（换句话说，它可以建立一个共享的压缩上下文），此列表随后会用作参考，对之前传输的值进行有效编码。

利用 Huffman 编码，可以在传输时对各个值进行压缩，而利用之前传输值的索引列表，我们可以通过传输索引值的方式对重复值进行编码，索引值可用于有效查询和重构完整的标头键值对。 表头压缩

作为一种进一步优化方式，HPACK 压缩上下文包含一个静态表和一个动态表：静态表在规范中定义，并提供了一个包含所有连接都可能使用的常用 HTTP 标头字段（例如，有效标头名称）的列表；动态表最初为空，将根据在特定连接内交换的值进行更新。 因此，为之前未见过的值采用静态 Huffman 编码，并替换每一侧静态表或动态表中已存在值的索引，可以减小每个请求的大小。

注：在 HTTP/2 中，请求和响应标头字段的定义保持不变，仅有一些微小的差异：所有标头字段名称均为小写，请求行现在拆分成各个 :method、:scheme、:authority 和 :path 伪标头字段。

HPACK 的安全性和性能

早期版本的 HTTP/2 和 SPDY 使用 zlib（带有一个自定义字典）压缩所有 HTTP 标头。 这种方式可以将所传输标头数据的大小减小 85% - 88%，显著减少了页面加载时间延迟：

在带宽较低的 DSL 链路中，上行链路速度仅有 375 Kbps，仅压缩请求标头就显著减少了特定网站（即，发出大量资源请求的网站）的页面加载时间。 我们发现，仅仅由于标头压缩，页面加载时间就减少了 45 - 1142 毫秒。（SPDY 白皮书，chromium.org）

然而，2012 年夏天，出现了针对 TLS 和 SPDY 压缩算法的“犯罪”安全攻击，此攻击会导致会话被劫持。 于是，zlib 压缩算法被 HPACK 替代，后者经过专门设计，可以解决发现的安全问题、实现起来也更高效和简单，当然，可以对 HTTP 标头元数据进行良好压缩。