HTTP2.0简述
HTTP2.0 ，可以说是SPDY的升级版（其实原本也是基于SPDY设计的），但是，HTTP2.0 跟 SPDY 仍有不同的地方，如下：
- HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS 。
HTTP2.0 消息头的压缩算法采用 HPACK，而非 SPDY 采用的 DEFLATE 。
HTTP2.0 和 HTTP1.X 相比的新特性
1、新的二进制格式（Binary Format）
HTTP1.x 的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认 0 和 1 的组合。基于这种考虑 HTTP2.0 的协议解析决定采用二进制格式，实现方便且健壮。
同 SPDY 对 HTTP1.1 的改进。
- HTTP/2采用二进制格式而非文本格式
- HTTP/2是完全多路复用的，而非有序并阻塞的——只需一个连接即可实现并行
- 使用报头压缩，HTTP/2降低了开销
- HTTP/2让服务器可以将响应主动“推送”到客户端缓存中
Nginx 怎么做 HTTP2.0 的升级改造？
- 1、虽然 HTTP2.0 其实可以支持非 HTTPS 的，但是现在主流的浏览器像 Chrome，Firefox 表示还是只支持基于 TLS 部署的 HTTP2.0协议，所以要想升级成 HTTP2.0 还是先升级 HTTPS 为好。
- 2、当你的网站已经升级 HTTPS 之后，那么升级 HTTP2.0 就简单很多，如果你使用 NGINX ，只要在配置文件中启动相应的协议就可以了，可以参考 NGINX白皮书，NGINX配置HTTP2.0官方指南 。
- 3、使用了 HTTP2.0 那么，原本的 HTTP1.x 怎么办？这个问题其实不用担心，HTTP2.0 完全兼容 HTTP1.x 的语义，对于不支持 HTTP2.0 的浏览器，NGINX 会自动向下兼容的。
在我们内部的微服务 API 接口，也可以做 HTTP2 的改造，可以参考如下文章：
- 《Spring Cloud 使用 HTTP2》
-
HTTP2.0 的多路复用和 HTTP1.X 中的长连接复用区别
HTTP/1.0：一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接。
- HTTP/1.1：Pipeling(流水线) 解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会。一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞。
- ==HTTP/2：多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行。==
HTTP2.0 多路复用优点
HTTP 性能优化的关键并不在于高带宽，而是低延迟。**TCP 连接会随着时间进行自我「调谐」，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。**由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。<br /> HTTP/2 通过让所有数据流共用同一个连接，可以更有效地使用 TCP 连接，让高带宽也能真正的服务于 HTTP 的性能提升。
服务器推送
服务端推送能把客户端所需要的资源伴随着 `index.html` 一起发送到客户端，省去了客户端重复请求的步骤。正因为没有发起请求，建立连接等操作，所以静态资源通过服务端推送的方式可以极大地提升速度。具体如下：
- 普通的客户端请求过程：
-
为什么需要头部(header)压缩？
假定一个页面有 100 个资源需要加载（这个数量对于今天的 Web 而言还是挺保守的），而每一次请求都有 1kb 的消息头（这同样也并不少见，因为 Cookie 和引用等东西的存在），则至少需要多消耗 100kb 来获取这些消息头。==HTTP2.0 可以维护一个字典，差量更新 HTTP 头部，大大降低因头部传输产生的流量==。
具体参考：《HTTP/2 头部压缩技术介绍》 文章。 维护一份相同的静态字典（Static Table），包含常见的头部名称，以及特别常见的头部名称与值的组合。
- 维护一份相同的动态字典（Dynamic Table），可以动态地添加内容。
- 支持基于静态哈夫曼码表的哈夫曼编码（Huffman Coding）。
参考与推荐如下文章：
若有收获，就点个赞吧
0 人点赞
