在引出http2之前，首先要知道目前互联网上大多数请求都是http1.1 。在互联网快速发展的今天，http1.1 已经不能适应，尽管h2的普及率仅仅只有37.2 %（截止2019年5月份）。http1.1 还是主流，但是h2的潮流必然势不可挡。
目前我们的站点也在推进http2的进程。所以写一篇文章对h2的调研
HTTP 1.1 的问题
问题：传输串行化，效率低
- 高延迟带来的页面加载速度降低。尽管带宽增大，但是受制于路由器硬件，最后一公里等问题，其延迟还是大。
- 并发连接有限。
-
线头阻塞，一个HTTP（请求/响应）完成之后，才能进行下一个。
上图1可以看到，随着带宽的增大，延迟变化是有限的，尤其是4Mbps之后就没有啥变化了，这受制于网络设备等，也不完全因为传输距离。
上图2又可以看到，rtt（延迟）越小，页面加载时间越小。
那怎么解决呢？？
这就要提到长肥管道(高延迟，高带宽) 场景，以前是（http1.1）串行的发送，如果能做到源源不断的发和源源不断的收，就能解决问题了。(对付长肥管道，最好的方法就是贴近其极限去发包，注意不是将带宽完全打满，是贴近其极限，这个详细请看 长肥管道传输之痛与解决之道)
http1.1 做出的努力
为了解决上述问题，其实http1.1 也做出了很多的事情。
- 比如chrome浏览器只允许一个域发起6个TCP链接。那么如果将资源分散到不通的域名，就能尽可能多发起一些请求。
- 为了减少请求次数，将一些小图片拼成大图片，一次性发送，这种叫做雪碧图。
- 为了减少请求次数，还做内联，将图片内容做base64编码嵌入到css或js中。
雪碧图
|
内联
|
|---|
但是尽管如此，http1.1 还是没有完美解决其痛点。
HTTP2 横空出世
http2 为了能更好的推广。其更好的发掘TCP的协议性能，尽量对现有的HTTP协议不做改动，提供无缝的将http1.1 升级到 http2 的能力，如果客户端不支持h2,那么可以再降级到http1.1 。十分的友好。
访问网站 https://http2.akamai.com/demo 可以看到一个 http1.1 和 http2 的对比。其实这张地球的图片是由非常多的小图片组成的。所以会大量对后端进行请求。
http1.1
http1.1
- 左上角 加载时间为5.2 s
- 中间 并发了 6个连接，看样子，每个连接也很耗时呢。
- 用的HTTP1.1 右下脚的waterfall ，越到后面的请求，Stalled越大（灰色部分）注意 size那列全是1.3kB
http2
http2
- 左上角 加载时间为5.2 s
- 中间 只有一条连接，也很迅速。
- 用的HTTP2 右下角的waterfall，其实也有 stalled，但是和http1比起来，小多了。注意 size那列全是1.1kB
为什么会有如此的差距呢
原因一：多路复用
其实上面也说了，这张地图的照片是由很多小图片组成的，也就是访问的时候会由十分多的小图片传输 。而h2是多路复用，所以当然就效率高了。
http1.1 和 http2 的传输对比
原因二：标头压缩
在这里，http2 会将http报头中的内容进行二进制压缩，其原理是利用的霍夫曼编码（就是利用贪心算法）将数据二进制化传输。另利用静态字典和动态字典，如果传输过的内容，不再重复传输，如一些请求都是GET请求，则Method：Get 不会重复传输。
原因三：服务端推送
服务端将数据提前推送给客户端。
浏览器如何和服务端建立一个http2连接呢
h2 不一定必须要tls，但是从浏览器发起的就必须要求是 tls 的。基于tls的是 h2 ，基于 tcp 的是h2c 。所以这里主要介绍 h2 ，而不是h2c。
那么客户端在tls握手阶段会发起一个tls握手，client hello。在client hello 中由一个 ALPN (Application Layer Protocol Negotiation)应用层协议的协商，带上表示客户端是支持 h2 的，服务端不支持h2的化，可以退化到h1.1 。
client hello
|
server hello
|
|---|
接下来协商好 h2 之后，就可以开始h2 的数据发送了。
http2 的 数据流
参考： 极客时间的 陶辉老师。
网友评论