HTTP/2
首先看看HTTP/2的一些新特性：
l 二进制分帧
l 首部压缩
l 流量控制
l 多路复用
l 请求优先级
l 服务器推送
二进制分帧
二进制分帧层，是HTTP2.0性能增强的核心。
HTTP 1.x在应用层以纯文本的形式进行通信，HTTP2.0在不改变HTTP1.x的语义、方法、状态码、URL以及首部字段的情况下，为了突破原有性能限制，在应用层(HTTP)和传输层(TCP)之间增加了一个二进制分帧层。HTTP2.0将所有的传输信息分割为更小的消息和帧，并对它们采用二进制格式编码，如下图所示。
这里引入一个新的通信单位：帧。
帧是HTTP 2.0通信的最小单位，包括帧首部、流标识符、优先值和帧净荷等。
其中，帧类型可以分为：
l DATA：用于传输HTTP消息体
l HEADERS：用于传输首部字段
l SETTINGS：用于约定客户端和服务端的配置数据。比如设置初识的双向流量控制窗口大小
l WINDOW_UPDATE：用于调整个别流或个别连接的流量
l PRIORITY：用于指定或重新指定引用资源的优先级
l RST_STREAM：用于通知流的非正常终止
l PUSH_ PROMISE：服务端推送许可
l PING：用于计算往返时间，执行“ 活性” 检活
l GOAWAY：用于通知对端停止在当前连接中创建流
标志位，用于不同的帧类型定义特定的消息标志。比如DATA帧就可以使用End Stream: true表示该条消息通信完毕；流标识位表示帧所属的流ID；优先值用于HEADERS帧，表示请求优先级；R表示保留。
下面是抓包的一个HEADERS帧：
另外一个两个要说一下的概念：消息和流。
消息是指逻辑上的HTTP消息(请求/响应)，一系列数据帧组成一个完整的消息，比如一系列DATA帧和一个HEADERS帧组成了请求消息。
流是链接中的一个虚拟信道，可以承载双向消息传输，每个流有唯一证书标识符，为了防止两端流ID冲突，客户端发起的流具有奇数ID，服务端发起的流具有偶数ID。
所有HTTP 2.0通信都在一个TCP链接上完成，这个链接可以承载任意数量的双向数据流Stream。相应地，每个数据流以消息的形式发送，而消息由一个或多个帧组成，这些帧可以乱序发送，然后根据每个帧首部的流标识符重新组装。
二进制分帧主要是为HTTP2.0其他特性提供基础。它能把一个数据划分封装为更小更便捷的数据。首先是在单链多资源方式中，减少服务端的链接压力，内存占用更少，链接吞吐量更大；另一方面，由于TCP链接的减少而使网络拥塞状态得以改善，同时慢启动时间减少，使拥塞和丢包恢复的速度更快。
首部压缩
HTTP1.x每次通信(请求或响应)都会携带首部信息用于描述资源属性。而HTTP2.0在客户端和服务端之间使用首部表来跟踪和存储之前发送的键值对，首部表在连接过程中始终存在，新增的键值对会更新到表尾，因此不需要每次通信都携带首部，请求与响应首部的定义在HTTP2.0中基本没有变。
另外HTTP2.0使用了首部压缩技术，压缩算法采用HPACK，让报头更紧凑、更快速传输，有利于移动网络环境。需要注意的是，HTTP2.0的首部压缩，与我们常用的gzip等报文内容压缩不冲突。
流量控制
HTTP/2.0 “流”的流量控制的目标是：在不改变协议的情况下允许使用多种流量控制算法
l 流量控制是特定于一个连接的。每种类型的流量控制都是在单独的一跳的两个端点之间的，并不是在整个端到端的路径上的。（这里的一跳指的是HTTP连接的一跳，而不是IP路由的一跳）
l 流量控制是基于WINDOW_UPDATE帧的。接收方公布自己打算在每个流以及整个连接上分别接收多少字节。这是一个以信用为基础的方案。
l 流量控制是有方向的，由接收者全面控制。接收方可以为每个流和整个连接设置任意的窗口大小。发送方必须尊重接收方设置的流量控制限制。客户方、服务端和中间代理作为接收方时都独立地公布各自的流量控制窗口，作为发送方时都遵守对端的流量控制设置。
l 无论是新流还是整个连接，流量控制窗口的初始值是65535字节。
l 帧的类型决定了流量控制是否适用于帧。目前，只有DATA帧服从流量控制，所有其它类型的帧并不消耗流量控制窗口的空间。这保证了重要的控制帧不会被流量控制阻塞。
l 流量控制不能被禁用。
l HTTP/2只定义了WINDOW_UPDATE帧的格式和语义，并没有规定接收方如何决定何时发送帧、发送什么样的值，也没有规定发送方如何选择发送包。具体实现可以选择任何满足需求的算法。
多路复用
在HTTP1.1中，浏览器客户端在同一时间，针对同一域名下的请求有一定数量的限制。超过限制数目的请求会被阻塞，而HTTP2.0中的多路复用优化了这一性能。
基于二进制分帧层，HTTP2.0可以在共享TCP连接的基础上，同时发送请求和响应。HTTP消息被分解为独立的帧，而不破坏消息本身的语义，交错发送出去，最后在另一端根据流ID和首部将他们重新组合。对比看一下HTTP1.x和HTTP2.0，这里不考虑HTTP1.x的pipeline机制。
HTTP2.0成功解决了HTTP1.x的队首阻塞问题(TCP层的阻塞仍无法解决)，同时，也不需要通过pipeline机制多条TCP连接来实现并行请求与响应。减少了TCP连接数对服务器性能有很大提升，同时也消除不必要的延迟，从而减少页面加载的时间。
请求优先级
把HTTP消息分为很多独立帧之后，就可以通过优化这些帧的交错和传输顺序进一步优化性能。
每个流都可以带有一个31bit的优先值：0表示最高优先级；2的31次方-1表示最低优先级。
客户端明确指定优先级，服务端可以根据这个优先级作为交互数据的依据，比如客户端优先设置为.css>.js>.jpg。服务端按此顺序返回结果更加有利于高效利用底层连接，提高用户体验。然而，在使用请求优先级时应注意服务端是否支持请求优先级，是否会引起队首阻塞问题，比如高优先级的 慢响应请求会阻塞其他资源的交互。
服务器推送
HTTP2.0增加了服务端推送功能，服务端可以根据客户端的请求，提前返回多个响应，推送额外的资源给客户端
如下图，客户端请求stream 1(/page.html)。服务器在返回stream 1的消息的同时推送了stream 2(/script.js)和stream4(/style.css)
l PUSH_PROMISE帧是服务端向客户端有意推送资源的信号。
l PUSH_PROMISE帧中只包含预推送资源的首部。如果客户端对PUSH_PROMISE帧没有意见，服务端在PUSH_PROMISE帧后发送响应的DATA帧。如果客户端已经缓存了该资源，不需要推送，可以拒绝PUSH_PROMISE帧。
l PUSH-PROMISE必须遵循请求-响应原则，只能借着对请求的响应推送资源。
l PUSH_PROMISE帧必须在返回响应之前发送，以免客户端出现竞态条件（竞态条件是指在多线程的情况下不同的执行顺序会导致计算机执行出不同的结果正确性不同）
l HTTP2.0连接后，客户端与服务端交换SETTINGS帧，借此限定双向并发的最大数量。因此，客户端可以限定推送流的数量，或者通过把这个只设置为0来完全禁止服务器推送。
l 所有推送的资源都必须遵守同源策略。换句话说，服务器不能随便将第三方资源推送给客户端，而必须是经过双方的确认才行。
HTTP/2现在已经获得绝大多数浏览器的支持，不过在使用过程中HTTP/2需要使用1.0.1e之后的openssl版本，通过nginx -V，可以查看nginx的openssl版本，如果版本低，重新编译nginx即可。
那么在nginx中如何配置支持HTTP/2？很简单，只需要在server中的listen部分添加http2即可。
怎么测试http2是否已开启，方法很多，这里介绍三种方法：
1、浏览器开发者工具
2、Chrome扩展HTTP/2 and SPDY indicator
3、命令行客户端nghttp
另外HTTP/2的服务器推送，需要nginx配置才能有效利用。
通过http2_push指令配置
这种情况下，demo.html需要用到的资源style.css、image1.jpg和image2.jpg被推送到客户端。资源少的情况下，我们可以这么使用，但是资源多的情况下这种方式就不太现实。
自动将资源推送给客户端
nginx支持拦截link预加载头的约定，推送这写头中标识的资源，需要在配置中启动预加载，配置http2_push_preload on
这里也有一个问题，一般的静态资源，我们都会设置缓存有效期。当客户端资源在缓存有效期内的时候，我们强制推送静态资源，只会增加服务器带宽的压力，所以我们需要指定客户端是否需要这些资源，并且不太可能已经缓存过，可能的方法，就是客户端在首次访问时服务端推送，并在随后的访问请求中包含cookie，服务端通过cookie去判断是否进行推送，就是有选择的向客户端推送资源，配置方法如下：
测试如下：