初探 HTTP 2.0
HTTP 2.0 也被写作 HTTP/2 ，它是超文本传输协议的 2.0 版本，因为 SPDY 的流行让 IETF 看到了优化后的效果，以及可以通过修改协议层来优化 HTTP，所以 IETF 开始决定正式考虑制定 HTTP 2.0 的计划，而且，SPDY的部分设计人员也被邀请参与了 HTTP 2.0 的设计。
HTTP2.0 在设计之初就与 SPDY 的设计目的和出发点不同，SPDY 更像是 Google 自家的一个产品，相当于自家的一个玩具，你怎么玩儿都行，而 HTTP 2.0 在设计之初就是为了普适性的这个目的，所以，一开始任何的设计都会关系到以后的维护问题，如果有什么瑕疵或者不足的地方可能会影响巨大，所以考虑的问题角度要非常严谨和慎重。
HTTP 2.0 在设计之初就有一些重要的前提：
- 客户端向服务器发送请求的这种基本模型不会改变。
- 原有的协议头不会改变，使用 http:// 和 https:// 的服务和应用不会做任何修改，不会有 http2://。
- 使用 HTTP 1.x 的客户端和服务器可以平滑升级到 HTTP 2.0 上。
- 不识别 HTTP 2.0 的代理服务器可以将请求降级到 HTTP 1.x。
客户端在和服务器确定是使用 HTTP1.x 还是 HTTP 2.0 之前，需要先确定对方是否支持 HTTP 2.0，所以这里必须要先进行协商，也就是客户端询问服务器，这样一来一回就多了一个 RTT 的延迟。我们对 HTTP 1.x 的修改就是为了降低延迟，现在又多了一个 RTT，这样显然是无法接受的。Google 制定 SPDY 协议的时候也遇到了这个问题，他们采取的做法是强制协商在 SSL 层完成，还因此制定了一个 TLS 的拓展，叫做 NPN(Next Protocol Negotiation)。虽然 HTTP 2.0 也采用了相同的方式，不过经过讨论后，最终 HTTP 2.0 没有强制要走 SSL 层，HTTP 2.0 没有使用 NPN，却制定了一个 TLS 的拓展叫做 ALPN(Application Layer Protocol Negotiation)，现在，SPDY 也打算迁移到 ALPN 了。
HTTP 2.0 的主要变化
HTTP 2.0 自从设计到诞生以来，发生了很多变化，不过对于开发人员和厂商来说，影响比较大的就几点：
二进制格式
HTTP 1.x 的诞生使用的是明文协议，它的格式主要由三部分构成：请求行(request line) 、请求头(header) 和报文体(body)，要识别这三部分必须要做协议解析，而协议解析是基于文本的，基于文本的解析存在多样性的缺陷，而二进制格式只能识别 0 和 1 ，比较固定，基于这种考量，HTTP 2.0 决定采用二进制格式，实现方便而且健壮性强。
下面这幅图很好的诠释了 HTTP1.x 和 HTTP 2.0 使用的不同报文格式。
在 HTTP 2.0 报文中，length 定义了整个 frame 的开始到结束，type 定了 frame 的类型，一种有十种，flags 定义了一些重要的参数，stream id 用作流控制，剩下的 payload 就是 request 的正文。
虽然 HTTP 2.0 报文格式看上去和 HTTP 1.x 的完全不同，但是实际上 HTTP 2.0 并没有改变 HTTP 1.x 的语义，它只是在 HTTP 1.x 的基础上封装了一层，如下图所示
从上图可以看到，HTTP 1.x 中的请求行、请求头被 HTTP 2.0 封装成为了 HEADERS Frame，而 HTTP 1.x 中的报文体被 HTTP 2.0 封装成为了 Data Frame。调试的时候浏览器会把 HTTP 2.0 的 frame 自动还原成 HTTP 1.x的格式。
连接共享
我们上面聊到，HTTP 1.x 并没有真正意义上的解决连接复用问题，所以 HTTP 2.0 要解决的一大难题就是连接共享(MultiPlexing)，连接共享意味着客户端与服务器之间也只需要一个连接即可，这样即使来自很多流的数据包也能够混合在一起通过同样连接传输，再根据不同帧首部的 stream id 标识符重新连接将不同的数据流进行组装。
什么是 stream？
stream 是连接中的一个虚拟信道，可以承载双向消息传输。每个流有唯一整数标识符。为了防止两端 streaam id 冲突，客户端发起的流具有奇数 id，服务器端发起的流具有偶数 id。
我们上面提到 HTTP 1.x 没有真正解决连接共享还有一个主要的因素就是无法对不同的请求设置优先级，这样会导致关键请求被阻塞。而 HTTP 2.0 你可以对不同的 stream 设置不同的优先级，stream 之间也可以设置依赖，依赖和优先级都可以动态调整，这样就会解决关键请求被阻塞的问题。
头部压缩
上面还聊到了 HTTP1.x 中的 header 由于 cookie 和 user agent 不存在记忆性，这样导致每次都要带着这些头重新发送请求，HTTP 2.0 使用 encoder 来减少传输的 header 大小，通信双方会各自缓存一份 header 字段表，这样能够避免重复传输 header ，也能够减小传输的大小。HTTP 2.0 采用的是 HPACK 压缩算法。
这种压缩算法的主要思想可以参考官方文档 https://httpwg.org/specs/rfc7541.html
服务端推送
服务端推送(Server Push) 我们上面也已经聊过，HTTP 2.0 能够以推的方式将客户端的内容预先发送出去，正因为没有发起请求，建立连接等操作，所以静态资源通过服务端推送的方式可以极大地提升速度。服务端推送还有一个更大的优势：缓存，缓存也能够在不同页面之间共享缓存资源。
需要注意下面几个点：
1、推送遵循同源策略；
2、这种服务端的推送是基于客户端的请求响应来确定的。
当服务端需要主动推送某个资源时，便会发送一个 Frame Type 为 PUSH_PROMISE 的 frame ，里面带了 PUSH 需要新建的 stream id。意思是告诉客户端：接下来我要用这个 id 向你发送东西，客户端准备好接着。客户端解析 frame 时，发现它是一个 PUSH_PROMISE 类型，便会准备接收服务端要推送的流。
HTTP 2.0 的缺陷
HTTP 2.0 带给我们最惊艳的莫过于多路复用了，虽然多路复用有种种好处，但是大家可以想一下，多路复用虽然好，但是它是建立在 TCP 连接的基础上，在连接频繁的情况下，是不是会对 TCP 连接造成压力，这个角度来讲，TCP 很容易成为性能瓶颈。
还有一点，使用 HTTP 2.0 会增加一次 TLS 握手过程，增加 RTT，这个我们上面也说到了。
在 HTTP 2.0 中，多个请求是在同一个 TCP 管道中，这样当 HTTP 2.0 出现丢包时，整个 TCP 都要开始等待重传，那么就会阻塞该 TCP。连接中的所有请求。
总结
这篇文章我们主要聊了一下 HTTP从1.x 到 SPDY，再到 HTTP 2.0 的协议变迁以及 HTTP 1.0、1.1 的痛点和弊端，SPDY 的出现背景以及发现情况，然后 HTTP 2.0 的主要特征、HTTP 2.0 相对于 HTTP 1.x 有了哪些改变，它的缺点有哪些。
