认识 HTTP 2.0

HTTP 2.0 来了，从1.1到2.0，递增了一个大版本号，那么 HTTP 2.0 会给我们带来怎么样的技术革新呢？今天我们一起学习了解一下 HTTP 2.0 。

即超文本传输协议2.0版本，虽然协议的名字已经不是那么符合实际了（HTTP 1.0 开始即可传输二进制流等非文本内容）。

我们来看看它的宣言草稿：

HTTP 2.0 应该满足如下条件：

• 相对于使用 TCP 的 HTTP 1.1，用户在大多数情况下的感知延迟要有实质上、可度量的改进；
• 解决 HTTP 中的“队首阻塞”问题；
• 并行操作无需与服务器建立多个连接，从而改进 TCP 的利用率，特别是拥塞控制方面；
• 保持 HTTP 1.1 的语义，利用现有文档，包括（但不限于）HTTP 方法、状态码、URI，以及首部字段；
• 明确规定 HTTP 2.0 如何与 HTTP 1.x 互操作，特别是在中间介质上；
• 明确指出所有新的可扩展机制以及适当的扩展策略。

对现有的 HTTP 部署——特别是 Web 浏览器（桌面及移动）、非浏览器（“HTTP API”）、Web 服务（各种规模），以及中间介质（代理、公司防火墙、“反向”代理及 CDN）而言，最终规范应该满足上述这些目标。类似地，当前和未来对 HTTP/1.x 的语义扩展（如首部、方法、状态码、缓存指令）也应该得到新协议的支持。

—— HTTPbis WG 宣言 HTTP 2.0

从宣言看，2.0协议的范围和主要设计要求是改善 HTTP 传输中的性能瓶颈并对现有 HTTP 版本进行扩展而非替代。

目前 HTTP 2.0 的第一个可实现草案已经由 HTTPbis 工作组在今年的7月8日发布。

我们来看看2.0版本带来了哪些性能优化，这些优化又会带来怎样的技术变革。

二进制分帧层的工作就是将传输内容分割成小块的消息和帧，并以二进制格式对其进行编码。这样，客户端与服务端都必须互相了解对方的编码机制。

一个 HTTP 2.0 通信都在一个 TCP 连接上完成，这个连接可以承载任意数量的双向数据流。每个数据流再以消息的形式发送，每个消息由一或多个帧组成。这些帧可以乱序发送，然后再根据每个帧首部的流标识符重新组装。

我们可以将流理解为连接中的虚拟信道，可以承载双向的数据，每个流都有一个唯一的整数标识符。消息则代表一个请求或响应，可以由一或多个帧组成。帧是最小通信单位，承载特定类型的数据，如 HTTP 首部、负荷等等。

图中仅说明了数据流、消息与帧之间的关系，而非他们实际传输中的编码结果

把 HTTP 消息分解为很多独立的帧之后，就可以通过优化这些帧的交错和传输顺序，进一步提升性能。为了做到这一点，每个流都可以带一个31比特的优先值:

• 0 表示最高优先级；
• 2^31 - 1 表示最低优先级。

有了优先级，客户端和服务器就可以在处理不同流时采取不同的策略，以最优方式发送数据。

现代浏览器为了加快页面加载速度，都会根据资源的类型以及在页面中的位置排定请求的优先次序，甚至通过访问学习，即之前渲染如果被某些资源阻塞，那么同样的资源在下一次访问时可能会被赋予更高的优先级。

以前并行需要开启多个 TCP 连接，HTTP 2.0 仅需要一个连接就可以支持多个流的并行。

实验表明，客户端使用更少的连接肯定可以降低延迟时间。HTTP 2.0 发送的
总分组数量比 HTTP 差不多要少40%。而服务器处理大量并发连接的情况也
变成了可伸缩性问题，因为 HTTP 2.0 减轻了这个负担。
—— HT.TP/2.0
Draft 2

每个来源一个连接显著减少了相关的资源占用：连接路径上的套接字管理工作量少了，内存占用少了，连接吞吐量大了。此外，从上到下所有层面上也都获得了相应的好处：

• 所有数据流的优先次序始终如一；
• 压缩上下文单一使得压缩效果更好；
• 由于 TCP 连接减少而使网络拥塞状况得以改观；
• 慢启动时间减少，拥塞和丢包恢复速度更快。

虽然能指定流的优先级，但是如何分配带宽等资源问题，HTTP 2.0 提供了一个简单的机制：

• 流量控制基于每一跳进行，而非端到端的控制；
• 流量控制基于窗口更新帧进行，即接收方广播自己准备接收某个数据流的多少字节，以及对整个连接要接收多少字节；
• 流量控制窗口大小通过 WINDOW_UPDATE 帧更新，这个字段指定了流ID和窗口大小递增值；
• 流量控制有方向性，即接收方可能根据自己的情况为每个流乃至整个连接设置任意窗口大小；
• 流量控制可以由接收方禁用，包括针对个别的流和针对整个连接。

HTTP 2.0 对于传输中的 HTTP 首部会进行差异化压缩。具体的规则如下：

• HTTP 2.0 在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键－值对， 对于相同的数据，不再通过每次请求和响应发送；
• 首部表在 HTTP 2.0 的连接存续期内始终存在，由客户端和服务器共同渐进地更新；
• 每个新的首部键－值对要么被追加到当前表的末尾，要么替换表中之前的值。

通常的 Web 应用都由几十个资源组成，客户端需要分析服务器提供的文档才能逐个找到它们。那为什么不让服务器提前就把这些资源推送给客户端，从而减少额外的时间延迟呢？服务器已经知道客户端下一步要请求什么资源了，这时候服务器推送即可派上用场。

相比以前服务器将资源嵌入 HTML 返回的方式，HTTP 2.0 中会将这个过程放在 HTTP 协议本身来实现。这样可以带来几个好处：

• 客户端可以缓存推送过来的资源；
• 客户端可以拒绝推送过来的资源；
• 推送资源可以由不同的页面共享；
• 服务器可以按照优先级推送资源。

“嵌入资源”是针对 HTTP 1.x 的一种流行“优化技巧”，实际上无异于“强制推送”，并且无法对嵌入资源做单独缓存。HTTP 2.0 的推送只能在服务器的响应之前进行，即无法随意发起推送流，并且能避免客户端出现竞态条件，比如下一个请求的资源恰好是服务器打算推送的资源。客户端自身可以拒绝推送的资源，比如已经缓存了该资源。

HTTP 2.0 时代下，哪些技术优化，我们可能不再需要呢？

• 资源文件合并；
• 图片精灵；
• 域名分区；
• 资源内嵌。

上面所列可能不全，但只要是关于减少 HTTP 请求，增加并行下载的优化，都将在 HTTP 2.0 普及之后消失。

延伸阅读

SPDY 与 HTTP 2.0

SPDY 是谷歌开发的一个实验性协议，于2009年年中发布，其主要目标是通过解决 HTTP 1.1 中广为人知的一些性能限制，来减少网页的加载延迟。大致上，这个项目设定的目标如下：

• 页面加载时间（PLT，Page Load Time）降低50%；
• 无需网站作者修改任何内容；
• 把部署复杂性降至最低，无需变更网络基础设施；
• 与开源社区合作开发这个新协议；
• 收集真实性能数据，验证这个实验性协议是否有效。

首次发布后不久，谷歌的两位软件工程师 Mike Belshe 和 Roberto Peon 就分享了他们对这个新实验性 SPDY 协议的实现结果、文档和源代码：

目前为止，我们只在实验室条件下测试过 SPDY。最初的成果很激动人心：通过模拟的家庭上网线路下载了25个最流行的网站之后，我们发现性能的改进特别明显，页面加载速度最多快了55%。

—— A 2x Faster Web Chromium Blog

几年后的2012年，这个新的实验性协议得到了 Chrome、Firefox 和 Opera 的支持，很多大型网站（如谷歌、Twitter、Facebook）都对兼容客户端提供 SPDY 会话。换句话说，SPDY 在被行业采用并证明能够大幅提升性能之后，已经具备了成为一个标准的条件。最终，HTTP-WG（HTTP Working Group）在2012年初把 HTTP 2.0 提到了议事日程，吸取 SPDY 的经验教训，并在此基础上制定官方标准。

最后

这篇文章基本就是照搬书中内容为大家介绍了一下 HTTP 2.0。这里也狠狠推荐一下这本好书——《High Performance Browser Networking 》。中文版由李松峰老师翻译，书名是《Web性能权威指南》，大家可以去各大网站

这本书将Web性能的瓶颈，具体的优化方案，未来的技术演进等都做了非常精彩的讲解，是一本前端开发进阶良书。