迹忆客 专注技术分享

在正式进入 HTTP/2 的功能介绍之前，我们先转个弯了解一下 HTTP/2 的前世今生。

复用流

通过服务器和客户机之间交换的HTTP/2协议发送的文本格式帧的双向序列称为“流”。HTTP协议的早期迭代一次只能传输一个流，每个流传输之间有一定的时间延迟。

通过逐个发送的单个流接收成吨的媒体内容既低效又消耗资源。HTTP/2的变化帮助建立了一个新的二进制帧层来解决这些问题。

这一层允许客户机和服务器将HTTP负载分解成小的、独立的和可管理的交织帧序列。然后在另一端重新组装这些信息。

二进制帧格式允许在连续流之间无延迟地交换多个同时打开的独立双向序列。这种方法展示了 HTTP/2 的一系列好处。

• 并行复用的请求和响应不会相互阻塞。
• 尽管传输多个数据流，但使用单个 TCP 连接来确保有效的网络资源利用。
• 无需应用不必要的 优化技巧 ——例如图像精灵、串联和域分片等——会损害网络性能的其他领域。
• 减少延迟，更快的网络性能，更好的搜索引擎排名。
• 降低运行网络和 IT 资源的运营支出和资本支出。

使用此功能，来自多个流的数据包基本上混合并通过单个 TCP 连接传输。然后这些包在接收端被拆分并作为单独的数据流呈现。使用 HTTP 1.1 或更早版本同时传输多个并行请求需要多个 TCP 连接，尽管以更快的速率传输更多数据流，但它本质上会限制整体网络性能。

查看 HTTP1.1 的不足 一文，了解HTTP1.1 的局限，看一下为什么要开发HTTP/2

二进制分帧层

HTTP/2 所有性能增强的核心在于新的二进制分帧层，它定义了如何封装 HTTP 消息并在客户端与服务器之间传输。

这里所谓的“层”，指的是位于套接字接口与应用可见的高级 HTTP API 之间一个经过优化的新编码机制: HTTP 的语义（包括各种动词、方法、标头）都不受影响，不同的是传输期间对它们的编码方式变了。 HTTP/1.x 协议以换行符作为纯文本的分隔符，而 HTTP/2 将所有传输的信息分割为更小的消息和帧，并采用二进制格式对它们编码。

这样一来，客户端和服务器为了相互理解，都必须使用新的二进制编码机制: HTTP/1.x 客户端无法理解只支持 HTTP/2 的服务器，反之亦然。 不过不要紧，现有的应用不必担心这些变化，因为客户端和服务器会替我们完成必要的分帧工作。

数据流优先级

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

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

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

然而，在现实世界中，服务器很少能够控制 CPU 和数据库连接等资源。实现复杂性本身会阻止服务器适应流优先级请求。该领域的研究和开发对于 HTTP/2 的长期成功尤为重要，因为该协议能够通过单个 TCP 连接处理多个数据流。

此功能可导致服务器请求的同时到达，从最终用户的角度来看，这些请求实际上在优先级方面有所不同。随机拖延数据流处理请求会破坏 HTTP/2 更改所承诺的效率和最终用户体验。同时，智能且广泛采用的流优先级机制展示了 HTTP/2 的好处。

• 有效的网络资源利用。
• 减少交付主要内容请求的时间。
• 改进了页面加载速度和最终用户体验。
• 优化客户端和服务器之间的数据通信。
• 减少网络延迟问题的负面影响。

服务器推送

此功能允许服务器向客户端发送额外的可缓存信息，这些信息未被请求但在未来的请求中预计会出现。例如，如果客户端请求资源 X 并且知道资源 Y 被请求的文件引用，则服务器可以选择将 Y 与 X 一起推送，而不是等待适当的客户端请求。

客户端将推送的资源 Y 放入其缓存中以备将来使用。这种机制节省了请求-响应往返并减少了网络延迟。服务器推送最初是在 Google 的 SPDY 协议中引入的。包含伪标头（例如：path）的流标识符允许服务器启动必须可缓存的信息的推送。客户端必须明确允许服务器使用 HTTP/2 推送可缓存资源或终止具有特定流标识符的推送流。

其他 HTTP/2 更改（例如服务器推送）会主动更新或使客户端的缓存失效，也称为“缓存推送”。长期后果集中在服务器识别客户端实际上不想要的可能的可推送资源的能力上。

HTTP/2 实现为推送资源提供了显着的性能。

• 客户端将推送的资源保存在缓存中。
• 客户端可以跨不同页面重用这些缓存资源。
• 服务器可以在同一 TCP 连接内复用推送的资源以及最初请求的信息。
• 服务器可以优先推送资源——这是 HTTP/2 与 HTTP1 的关键性能区别。
• 客户端可以拒绝推送资源以维护缓存资源的有效存储库或完全禁用服务器推送。
• 客户端还可以限制并发复用的推送流的数量。

类似的推送功能已经可以通过诸如内联推送服务器响应之类的次优技术获得，而服务器推送提供了一种协议级解决方案，以避免与应用程序协议本身的基线功能次要的优化技巧带来的复杂性。

HTTP/2 对推送的数据流进行多路复用和优先级排序，以确保与其他请求-响应数据流一样具有更好的传输性能。作为一种内置的安全机制，必须事先授权服务器才能推送资源。

标头压缩

提供高端 Web 用户体验需要内容和图形丰富的网站。HTTP 应用程序协议是无状态的，这意味着每个客户端请求必须包含服务器执行所需操作所需的尽可能多的信息。这种机制导致数据流携带多个重复的信息帧，这样服务器本身就不必存储来自先前客户端请求的信息。

在网站提供富媒体内容的情况下，客户端推送多个几乎相同的标头帧，从而导致延迟和对有限网络资源的不必要消耗。如果不优化此机制，则数据流的优先混合无法实现所需的并行性能标准。

HTTP/2 通过压缩大量冗余标头帧的能力解决了这些问题。它使用 HPACK 规范作为头压缩的一种简单而安全的方法。客户端和服务器都维护一个在之前的客户端-服务器请求中使用的标头列表。

HPACK 在传输到服务器之前压缩每个标头的单个值，然后在先前传输的标头值列表中查找编码信息以重建完整的标头信息。用于 HTTP/2 实现的 HPACK 标头压缩具有巨大的性能优势，包括下面解释的 HTTP/2 的一些优势：

• 有效的流优先级。
• 有效利用多路复用机制。
• 减少资源开销——这是 HTTP/2 与 HTTP1 和 HTTP/2 与 SPDY 讨论中最早关注的领域之一。
• 编码大标头以及常用标头，无需发送整个标头帧本身。每个数据流的单独传输大小迅速缩小。
• 不易受到安全攻击，例如 CRIME 利用压缩标头的数据流。

参考文章： https://hpbn.co/http2