HTTP1.1 与 HTTP2.0
HTTP/1.1
改进持久连接
不成熟的HTTP管线化
提供虚拟主机的支持
HTTP1.1请求头中增加了host字段，用来表示当前的域名地址，这样的服务器就可以根据不同的host值做不同的处理
持久连接虽然能减少TCP的建立和断开次数，但是它需要等到前面的请求返回之后，才能进行下一次请求，如果TCP通道中的某个请求因为某些原因没有及时返回，那么就会阻塞后面的所有请求，这就是著名的对头阻塞问题。
HTTP1.1试图通过管线化的技术来解决对头阻塞问题。管线化是指将多个HTTP请求整批提交给服务器的技术，虽然可以整批发送请求，不过服务器依然需要根据请求顺序来回复浏览器的请求，但是最终是放弃了这种方式
特点是再一个TCP连接上可以传输多个HTTP请求，只要浏览器或者服务器没有明确断开连接，那么TCP连接会一直保持
HTTP/2
一旦一个TCP建立连接之后，就进入了发送数据状态，刚开始TCP协议会采用一个非常慢的速度去发送数据，然后慢慢加快发送数据的速度，直到发送数据的速度达到一个理想状态，我们把这个过程称为慢启动
慢启动是TCP为了减少网络拥塞的一种策略 ，我们是没有办法改变的
而之所以说慢启动会带来性能问题，是因为页面中常用的一些关键资源文件本来就不大，如HTML文件，CSS文件，和js文件，通常这些文件在TCP连接建立好之后就要发起请求的，但这个过程是个慢启动，所以耗费的时间比正常的时间要多很多，这样就推迟了宝贵的首次渲染页面的时长了。
如果同时开启了多条TCP连接，那么这些连接会有竞争固定的宽带
比如系统同时建立了多条TCP连接，当宽带充足时，每条连接发送或者接受速度会慢慢向上增加，而一旦宽带不足时，这些TCP连接又会减慢发送或者接受速度，比如一个页面有200个文件，使用了3个CDN,那么加载网页的时候就需要建立6*3, 也就是18个TCP连接来下载资源，在下载过程中，各个TCP连接就需要动态减慢接受数据的速度，
这样会出现一个问题，因为有的TCP连接下载的时一些关键资源，而有的连接下载的时图片视频等普通资源，但是多条TCP连接又不能协商哪些关键资源优先下载，这样就可能影响到关键资源的下载速度。
在HTTP/1中使用持久连接时，虽然能公用一个TCP管道，但是在一个管道中同一时刻只能处理一次请求，在当前的请求没有结束之前，其他的请求只能处于阻塞状态，这意味着我们不能随意在一个管道中发送请求和接收内容。
这是一个很严重的问题，因为阻塞请求的因素有很多，并且都是一些不确定的因素，如果有的请求被阻塞了5秒，那么后续排队的请求都要延迟等待5秒，在这个等待的过程中，宽带，cpu都被白白浪费
前面我们可以知道HTTP/1.1存在的问题是：慢启动和TCP连接之间相互竞争带宽是由于ＴＣＰ本身的机制导致的，而队头阻塞时由于HTTP/1.1的机制导致的
基于此，HTTP/2的思路就是一个域名只使用了一个TCP长连接来传输数据，这样整个页面资源的下载过程只需要一次慢启动，同时也避免了多个TCP连接竞争带宽所带来的问题
另外，就是队头阻塞的问题，等待请求完成后才能去请求下一个资源，这种方式无疑时最慢的，所以HTTP/2需要实现资源的并行请求 ，也就是任何时候都可以将请求发送给服务器，而并不需要等待其他请求的完成，然后服务器也可以随时返回处理好的请求资源给服务器
HTTP1对于宽带利用率并不理想，这也是HTTP1得到一个核心问题，是由下面的三个原因导致的
HTTP/2 的多路复用
TCP的慢启动
TCP竞争
队头阻塞问题
HTTP/2的解决方案可以总结为：
一个域名只使用一个TCP长连接
消除队头阻塞问题
上图就是HTTP/2 最核心，最重要且最具颠覆性的多路复用机制。
图中会发现每个请求都有一个对于的ID, 如stream1表示index.html的请求，stream2藐视foo.css的请求，这样在浏览器端，就可以随时将请求发送给服务器了。
服务器端接收到这些请求后，会根据自己的喜好来决定优先返回哪些内容，比如服务器可能早就缓存好index.html和bar.js的响应头信息，那么当接收到请求的时候就可以立即把index.html和bar.js的响应头信息返回给浏览器，然后再将index.html和bar.js的响应体数据返回给浏览器。之所以可以随意发送，是因为美分数据都有对应的ID，浏览器接收到之后，会筛选出相同ID的内容，将其拼接为完整的HTTP响应数据
HTTP/2使用了多路复用技术，可以将请求分成一帧一帧的数据去传输，这样带来一个额外的好处，就是当收到一个优先级高的请求时，比如接收到js或者css关键资源的请求，服务器可以暂停之前的请求来优先处理关键资源的请求
多路复用的实现
首先，浏览器准备好请求数据，包括了请求行，请求头等信息，如果是post方法，那么还要有请求体。
这些数据经过二进制分帧层处理之后，会被转换为一个个带有请求ID编号的帧，通过协议栈将这些帧发送给服务器
服务器接收到所有请求帧之后，会将所有相同ID的帧合并为一条完整的请求信息。
然后服务器处理该条请求，并将处理的响应行，响应头，和响应体分别发送至二进制协分帧层。
同样，二进制分帧层会将响应数据转换为一个个带有请求ID编号的帧，经过协议栈发送给浏览器。
浏览器接收到响应帧之后，会根据ID编号将帧的数据提交给对应的请求
从上面的流程可以看出，通过引入二进制分帧层，就实现了HTTP的多路复用技术。
HTTP是浏览器和服务器通信的语言，在这里虽然HTTP/2引入了分帧层技术，不过HTTP/2的语义和HTTP/1.1依然是一样的，也就是说它们通信的语言并没有改变，比如开发者依然可以通过accept请求头告诉服务器希望接收到什么类型的文件， 依然可以使用Cookie来保持登录状态，依然可以使用Cache来缓存本地文件，这些都没有改变，改变的只是传输方式，这点对于开发者来说非常重要，这意味着我们不需要为HTTP/2去重建生态
HTTP/1和HTTP/2
HTTP/2
HTTP/2的一个核心特性时使用了多路复用技术，因此它可以通过一个TCP连接来发送多个URL请求，多路复用技术能充分利用带宽，最大限度规避了TCP的慢启动所带来的问题，同时还实现了头部压缩，服务器推送等功能，使得页面资源的传输速度得到了大幅提升。
在HTTP/1.1时代，为了提升并行下载效率，浏览器为每个域名维护了6个TCP连接，而采用HTTP/2之后，浏览器只需要为每个域名维护1个TCP持久连接，同时还解决了HTTP/1.1队头阻塞的问题。
虽然HTTP/2解决了应用层面的队头阻塞问题，不过了HTTP/1.1一样，HTTP/2依然是基于TCP协议的，而TCP最初就是为了单连接而设计的，你可以把TCP连接看成是两台计算机之前的一个虚拟管道，计算机的一端将要传输的数据按照顺序放入管道，最终数据会以相同的顺序出现在管道的另外一头
在TCP传输过程中，由于单个数据包的丢失而造成的阻塞成为TCP上的队头阻塞。
我们知道在HTTP/2中，多个请求是跑在一个TCP管道中的，如果其中任意一路数据流中出现了丢包的情况，那么就会阻塞该TCP连接中的所有请求。
这不同与HTTP/1.1, 使用HTTP/1.1时，浏览器为每个域名开启了6个TCP连接，如果其中的1个TCP连接发生了队头阻塞，那么其他的5个连接依然可以继续传输数据，所以随着丢包率的增加，HTTP/2的传输效率也会越来越差，有测试数据表明，当系统达到了2%的丢包率时，HTTP/1.1的传输效率反而比HTTP/2高。
作者：编写人生
链接：https://juejin.cn/post/7028783888033906701