http2.0 解决了什么问题呢？
首先看看采用http2的两个效果，
https://http2.golang.org/gophertiles
对头阻塞
浏览器，比如chrome，默认建立6个连接。现在打开一个网页，经常见到上百个请求。那么http1.1时，就依赖着这6个连接，获取着上100个资源。然而6个连接，并没有根本上解决http的对头阻塞，因为http基于tcp，tcp的数据传输是由seq的，必须按照顺序接受。只是现在打饭的窗口，增加到6个而已。
为了优化打开速度，于是出现了采用多个域名来分担连接数的方式。比如打开demo.com, 那么静态资源通过域名static.demo.com 与动态资源 api.demo.com，分开处理，这样就有12个连接了。当然有甚至着用了更多的静态资源站点。
还有一种叫雪碧图 /CSS Sprite 的优化方式，简单描述就是小图，拼成大图。减少了请求文件的数量，不过现在这种也越来越少被用到了。
http2.0，引入了数据帧以及流式的处理方式。在应用层将数据拆封为帧，每个消息都被拆分成若干个帧进行传输，每个帧都分配一个序号。（在http1.1时，应用层的请求并没有被编号哦，而是发送后，等回应，再接着发）每个帧在传输是属于一个数据流，而一个连接上可以存在多个流，各个帧在流和连接上独立传输，到达之后在组装成消息，这样就避免了请求/响应阻塞。当然如果http2.0是基于tcp的话，还是会有对头阻塞的情况，毕竟tcp必须按序号接受消息。
- 头部压缩
- 用数字来代替请求头的值，比如2代表method：get
- 并且一个连接中， 不再需要重复传输header，比如user-agent的safari…… ，只传输一次，这样也可以大大的节省带宽。
主动推送
当用户访问index.html时，在http1.1的时代，浏览器解析后，还要再向服务器请求关联的静态资源，然而http2.0，从服务器端，就主动推送过去了
撸起袖子开干
从运维角度看待，我们也应该主动的推动http2，尤其在大规模并发的情况下，http的每一个小优化，都会被大规模的流量而放大。比如我们常用的前端服务组件nginx也早已支持http2.0，客户端的主流浏览器也早已支持。
我们采用的aws cloudfront ，也支持http2.0，那何不采取主动权呢。另一点，在http2.0主动推送的场景下，websocket，是否会被取代呢？拭目以待。技术的发展真的永无止境呢。