72-HTTP2 简介
- 维基百科关于 HTTP/2 的介绍:https://zh.wikipedia.org/wiki/HTTP/2
- RFC 7540 定义了 HTTP/2 的协议规范和细节:https://httpwg.org/specs/rfc7540.html 、https://httpwg.org/specs/rfc7541.html
HTTP/2 简介
HTTP/2 可以让我们的应用更快、更简单、更稳定 - 这几词凑到一块是很罕见的！HTTP/2 将很多以前我们在应用中针对 HTTP/1.1 想出来的“歪招儿”一笔勾销，把解决那些问题的方案内置在了传输层中。不仅如此，它还为我们进一步优化应用和提升性能提供了全新的机会！
HTTP/2 的主要目标是通过支持完整的请求与响应复用来减少延迟，通过有效压缩 HTTP 标头字段将协议开销降至最低，同时增加对请求优先级和服务器推送的支持。 为达成这些目标，HTTP/2 还给我们带来了大量其他协议层面的辅助实现，例如新的流控制、错误处理和升级机制。上述几种机制虽然不是全部，但却是最重要的，每一位网络开发者都应该理解并在自己的应用中加以利用。
HTTP/2 没有改动 HTTP 的应用语义。HTTP 方法、状态代码、URI 和标头字段等核心概念一如往常。不过，HTTP/2 修改了数据格式化（分帧）以及在客户端与服务器间传输的方式。这两点统帅全局，通过新的分帧层向我们的应用隐藏了所有复杂性。 因此，所有现有的应用都可以不必修改而在新协议下运行。
为什么不是 HTTP/1.2？
为了实现 HTTP 工作组设定的性能目标，HTTP/2 引入了一个新的二进制分帧层，该层无法与之前的 HTTP/1.x 服务器和客户端向后兼容，因此协议的主版本提升到 HTTP/2。
即便如此，除非您在实现网络服务器（或自定义客户端），需要使用原始的 TCP 套接字，否则您很可能注意不到任何区别：所有新的低级分帧由客户端和服务器为您执行。可观察到的唯一区别将是性能的提升和请求优先级、流控制与服务器推送等新功能的出现。
总结：HTTP/2 的最显著的改进主要体现在多路复用、允许设置请求优先级、压缩算法、二进制传输等等，这些特性能够让使用HTTP/2的应用获得更快、更简单、更稳定的效果。目前流行的 RPC 框架 gRPC 也采用了 HTTP/2 作为传输方式。
SPDY 与 HTTP/2 简史
SPDY 是 Google 开发的一个实验性协议，于 2009 年年中发布，其主要目标是通过解决 HTTP/1.1 中广为人知的一些性能限制来减少网页的加载延迟。具体来说，这个项目设定的目标如下：
- 页面加载时间 (PLT) 减少 50%。
- 无需网站作者修改任何内容。
- 将部署复杂性降至最低，无需变更网络基础设施。
- 与开源社区合作开发此新协议。
- 收集真实性能数据，验证实验性协议是否有效。
注：为了达到减少 50% 页面加载时间的目标，SPDY 引入一个新的二进制分帧层，以实现请求和响应复用、优先级和标头压缩，目的是更有效地利用底层 TCP 连接；请参阅延迟是性能瓶颈。
首次发布后不久，Google 的两位软件工程师 Mike Belshe 和 Roberto Peon 就分享了他们对这个新实验性 SPDY 协议的实现结果、文档和源代码：
目前为止，我们只在实验室条件下测试过 SPDY。最初的成果 很激动人心：通过模拟的家庭网络 连接下载了 25 个最流行的网站之后，我们发现性能的提升特别明显，页面 加载速度最高加快了 55%。 （Chromium 博客）
到了 2012 年，这个新的实验性协议得到 Chrome、Firefox 和 Opera 的支持，而且越来越多的大型网站（如 Google、Twitter、Facebook）和小型网站开始在其基础设施内部署 SPDY。事实上，在被行业越来越多的采用之后，SPDY 已经具备了成为一个标准的条件。
观察到这一趋势后，HTTP 工作组 (HTTP-WG) 将这一工作提上议事日程，吸取 SPDY 的经验教训，并在此基础上制定了官方“HTTP/2”标准。在拟定宣言草案、向社会征集 HTTP/2 建议并经过内部讨论之后，HTTP-WG 决定将 SPDY 规范作为新 HTTP/2 协议的基础。
在接下来几年中，SPDY 和 HTTP/2 继续共同演化，其中 SPDY 作为实验性分支，用于为 HTTP/2 标准测试新功能和建议。理论不一定适合实践（反之亦然），SPDY 提供一个测试和评估路线，可以对要纳入 HTTP/2 标准中的每条建议进行测试和评估。最终，这个过程持续了三年，期间产生了十余个中间草案：
- 2012 年 3 月：征集 HTTP/2 建议
- 2012 年 11 月：第一个 HTTP/2 草案（基于 SPDY）
- 2014 年 8 月：HTTP/2 草案 17 和 HPACK 草案 12 发布
- 2014 年 8 月：工作组最后一次征集 HTTP/2 建议
- 2015 年 2 月：IESG 批准 HTTP/2 和 HPACK 草案
- 2015 年 5 月：RFC 7540 (HTTP/2) 和 RFC 7541 (HPACK) 发布
2015 年初，IESG 审阅了新的 HTTP/2 标准并批准发布。 之后不久，Google Chrome 团队公布了他们为 TLS 弃用 SPDY 和 NPN 扩展的时间表：
与 HTTP/1.1 相比，HTTP/2 的主要变化在于性能提升。
一些主要功能（例如复用、标头压缩、优先级和协议协商）演化自之前开放但不标准的协议 (SPDY)。 Chrome 自 Chrome 6 开始就支持 SPDY，但由于大部分优点都集中在 HTTP/2 中，是时候向 SPDY 说再见了。 我们计划于 2016 年初停止对 SPDY 的支持，还会停止对 TLS 的 NPN 扩展的支持，转而在 Chrome 中使用 ALPN。
强烈建议服务器开发者迁移到 HTTP/2 和 ALPN。 我们很高兴参与到最终催生了 HTTP/2 的开放式标准的制定过程，并且考虑到整个行业在标准化和实现过程中的参与热情，我们希望对这一标准的采纳越来越多。 （Chromium> 博客）
SPDY 与 HTTP/2 的共同演化让服务器、浏览器和网站开发者可以在新协议制定过程中获得真实体验。 因此，HTTP/2 标准自诞生之日起就成为最好并经过大量测试的标准之一。 到 HTTP/2 被 IESG 批准时，已经有很多经过完全测试并且可以立即投入生产的客户端与服务器。 事实上，在最终协议被批准的几周后，由于多款热门浏览器（和许多网站）都部署了完整的 HTTP/2 支持，大量用户都体会到了新协议的好处。
设计和技术目标
早期版本的 HTTP 协议的设计初衷主要是实现要简单： HTTP/0.9 只用一行协议就启动了万维网；HTTP/1.0 则是对流行的 HTTP/0.9 扩展的一个正式说明；HTTP 1.1 则是 IETF 的一份官方标准；请参阅 HTTP 简史。 因此，HTTP/0.9-1.x 实现了其目的：HTTP 是应用最广泛、采用最多的一个互联网应用协议。
然而，实现简单是以牺牲应用性能为代价的： HTTP/1.x 客户端需要使用多个连接才能实现并发和缩短延迟；HTTP/1.x 不会压缩请求和响应标头，从而导致不必要的网络流量；HTTP/1.x 不支持有效的资源优先级，致使底层 TCP 连接的利用率低下；等等。
这些限制并不是致命的，但是随着网络应用的范围、复杂性以及在我们日常生活中的重要性不断增大，它们对网络开发者和用户都造成了巨大负担，而这正是 HTTP/2 要致力于解决的：
HTTP/2 通过支持标头字段压缩和在同一连接上 进行多个并发交换，让应用更有效地利用网络资源，减少 感知的延迟时间。具体来说，它可以对同一连接上的请求和响应消息进行交错 发送并为 HTTP 标头字段使用 有效编码。
HTTP/2 还允许为请求设置优先级，让更重要的请求更快速地完成，从而进一步 提升性能。
出台的协议更有利于网络，因为与 HTTP/1.x 相比，可以使用更少的 TCP 连接。 这意味着与其他流的竞争减小，并且连接的持续时间变长，这些特性反过来提高 了可用网络容量的利用率。 最后，HTTP/2 还可以通过使用二进制消息分帧对消息进行更高效 的处理。 （超文本传输协议版本 2，草案 17）
需要注意的是，HTTP/2 仍是对之前 HTTP 标准的扩展，而非替代。 HTTP 的应用语义不变，提供的功能不变，HTTP 方法、状态代码、URI 和标头字段等这些核心概念也不变。 这些方面的变化都不在 HTTP/2 考虑之列。 虽然高级 API 保持不变，仍有必要了解低级变更如何解决了之前协议的性能限制。