HTTP2.0详解

HTTP2.0和HTTP1.X相比的新特性

1. 新的二进制格式（Binary Format），HTTP1.x的解析是基于文本。
   与Http1.x（文本协议）不同，Http2是一个二进制协议，所有的消息被http2拆分封装成更小的消息单元帧，并进行二进制编码。其中http1.x的首部信息被封装成HEADER帧和CONTINUATION帧，请求体被封装到DATA帧，如下图所示：
   
   为什么使用二进制协议？

二进制协议
二进制协议一般消息头固定和消息体变长 ，每个字段固定了含义 ，其特点如下：

可读性差，难于调试（缺点）；
扩展性不好 ，如果要扩展字段，旧版协议就不兼容了（缺点）；
解析效率超高，几乎没有解析代价（优点）；
没有冗余字段，体积小（优点）；

文本协议

可读性好，便于调试； 扩展性也好，方便兼容旧协议；
解析效率一般，需要进行字符串比对；
存在冗余字段，体积大；

2. 多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。

在 HTTP 1.1 中，发起一个请求是这样的：

浏览器请求 url -> 解析域名 -> 建立 HTTP 连接 -> 服务器处理文件 -> 返回数据 -> 浏览器解析、渲染文件

这个流程最大的问题是，每次请求都需要建立一次 HTTP
连接，也就是我们常说的3次握手4次挥手，这个过程在一次请求过程中占用了相当长的时间，而且逻辑上是非必需的，因为不间断的请求数据，第一次建立连接是正常的，以后就占用这个通道，下载其他文件，这样效率多高啊！

为了解决这个问题， HTTP 1.1 中提供了 Keep-Alive，允许我们建立一次 HTTP 连接，来返回多次请求数据。
但是这里有两个问题：

HTTP 1.1 基于串行文件传输数据，因此这些请求必须是有序的，所以实际上我们只是节省了建立连接的时间，而获取数据的时间并没有减少

最大并发数问题，假设我们在 Apache 中设置了最大并发数 300，而因为浏览器本身的限制，最大请求数为
6，那么服务器能承载的最高并发数是 50

而 HTTP/2
引入二进制数据帧和流的概念，其中帧对数据进行顺序标识，这样浏览器收到数据之后，就可以按照序列对数据进行合并，而不会出现合并后数据错乱的情况。同样是因为有了序列，服务器就可以并行的传输数据。

HTTP/2
对同一域名下所有请求都是基于流，也就是说同一域名不管访问多少文件，也只建立一路连接。同样Apache的最大连接数为300，因为有了这个新特性，最大的并发就可以提升到300，比原来提升了6倍。

3. header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要

在 HTTP/1 中，HTTP 请求和响应都是由「状态行、请求 / 响应头部、消息主体」三部分组成。一般而言，消息主体都会经过 gzip 压缩，或者本身传输的就是压缩过后的二进制文件（例如图片、音频），但状态行和头部却没有经过任何压缩，直接以纯文本传输。

随着 Web 功能越来越复杂，每个页面产生的请求数也越来越多，根据 HTTP Archive 的统计，当前平均每个页面都会产生上百个请求。越来越多的请求导致消耗在头部的流量越来越多，尤其是每次都要传输 UserAgent、Cookie 这类不会频繁变动的内容，完全是一种浪费。

头部压缩需要在支持 HTTP/2 的浏览器和服务端之间：

• 维护一份相同的静态字典（Static Table），包含常见的头部名称，以及特别常见的头部名称与值的组合；
• 维护一份相同的动态字典（Dynamic Table），可以动态地添加内容；
• 支持基于静态哈夫曼码表的哈夫曼编码（Huffman Coding）；

4. 服务端推送（server push），同SPDY一样，HTTP2.0也具有server push功能，让服务器可以将响应主动“推送”到客户端缓存中

1、在合适的时机，推送合适的资源，Push比NoPush带来的网站时延提升是明显的。在网络带宽足够承载推送资源的前提下，我们预先推送浏览器后续请求需要的资源，网站的整体加载时间得到缩短。但是现实网络环境有不一样的延时和带宽。慢速网络环境影响TCP拥塞窗口增长的速度，除非主页面请求足够小，Push才能看到效果。
2、即使是错误地实施某些推送策略（比如说推送过大文件），带来的最严重后果，也就是改善不明显。所以建议是多做一些推送策略的尝试，直到把合适的资源在合适的时机把资源推送给浏览器。
3、网站往HTTP/2的环境迁移是个趋势。迁往HTTP/2需要将页面的所有请求尽量收归到同一域名，并且剥离出主页面的资源文件成多个独立的请求。假如你的网站已迁移到HTTP/2，而且网站的主请求不大，但是可能会触发很多资源请求。建议push这些资源。另外不要推送存放在浏览器cookie的资源，这只会浪费带宽。
4、目前的ServerPush推送机制没有解决浏览器已经具有资源缓存，而服务器已经推送到网络中，虽然浏览器可以发送RST桢拒绝推送流，但是服务器推送的资源已经在网络中等待浏览器接收。现在已经有一些规范草案（https://tools.ietf.org/html/draft-kazuho-h2-cache-digest-01）尝试用协商缓存摘要来解决问题。
5、CDN中的负载均衡机制可能会将低优先级的推送资源送入到系统缓存区，这会影响高优先级资源的推送效率问题。引入QUIC替代TCP，可以对缓存中推送资源进行分级，高优先级资源先发。
6、未来或将引入AI分析取代固定推送实现智能化推送。

如何配置

/usr/local/nginx/sbin/nginx -V

1. openssl的版本必须在1.0.2e及以上　如版本太低请安装安装新版 并重新编译nginx 增加–with-openssl 如直接使用我的那个安装的则为 --with-openssl=/usr/local/src/openssl-1.1.1a
2. nginx的版本必须在1.9.5以上，需要添加–with-http_v2_module模块
3. 

那些浏览器支持http2.0