HTTP2有哪些升级-CSDN博客

本文链接：https://blog.csdn.net/xiaoyuer_2020/article/details/145625814

HTTP2有哪些升级

● 二进制分帧（多路复用、优先级、流式传输、HTTP队头阻塞）
● 头部压缩
● 服务器推

HTTP1.0

无法复用连接

HTTP1.0为每一个请求单独新开一个TCP连接。
由于每个请求都是独立的连接，因此会带来下面的问题：

连接的建立和销毁都会占用服务器和客户端的资源，造成内存资源的浪费；
连接的建立和销毁都会消耗时间，造成响应时间的浪费；
无法充分利用带宽，造成带宽资源的浪费；

TCP协议的特点是慢启动，即一开始传输的数据量少，一段时间后达到传输的峰值，而上面这种做法，会导致大量的请求在TCP达到传输峰值前就被销毁了。

HTTP1.1

长连接

为解决HTTP1.0的问题，HTTP1.1默认开启长连接，即让同一个TCP连接服务于多个请求响应。
在这种情况下，多次请求响应可以共享同一个TCP连接，这不仅减少了TCP的握手和挥手时间，同时可以充分利用TCP慢启动的特点，有效的利用带宽。

实际上，在HTTP1.0后期，虽然没有官方标准，但开发者慢慢形成了一种共识：
只要请求头中包含 Connection: keep-alive，就表示客户端希望开启长连接，希望服务器响应后不要关闭TCP连接，如果服务器认可这一行为，即可保持TCP连接。

当需要的时候，任何一方都可以关闭TCP连接

扩展知识：
连接关闭的情况主要有三种：
1.客户端在某一次请求中设置了 Connection: close，服务器收到此请求后，响应结束立即关闭TCP。
2.在没有请求时，客户端会不断对服务器进行心跳检测（一般每隔一秒），一旦心跳检测停止，服务器立即关闭TCP。
3.当客户端长时间没有新的请求到达服务器，服务器会主动关闭TCP，运维人员可以设置该时间。

由于一个TCP连接可以承载多次请求响应，并在一段时间内不会断开，因此这种连接称之为长连接。

管道化和队头阻塞

HTTP1.1允许在响应到达之前发送下一个请求，这样可以大幅缩减带宽限制时间
但这样做会存在队头阻塞的问题。

由于多个请求使用的是同一个TCP连接，服务器必须按照请求到达的顺序进行响应。

想一想为什么？

于是，导致了一些后发出的请求，无法在处理完成后响应，产生了等待的时间，而这段时间的带宽可能是空闲的，这就造成了带宽的浪费。
队头阻塞虽然发生在服务器，但这个问题的根源是客户端无法知晓服务器的响应是针对哪个请求的。
正是由于存在队头阻塞，我们常常使用下面的手段进行优化：
● 通过减少文件数量，从而减少队头阻塞的几率
● 通过开辟多个TCP连接，实现真正的、有缺陷的并行传输

浏览器会根据情况，为打开的页面自动开启TCP连接，对于同一个域名的连接最多6个
如果想要突破这个限制，就需要把资源放到不同的域名。（域名拆分、精灵图）

然而，管道化并非一个成功的模型，它带来的队头阻塞造成非常多的问题，所以现代浏览器默认是关闭这种模式的

HTTP2.0

二进制分帧；

每个帧都带了一个头部，记录了流的ID，这样做就可以准确的知道这一帧数据是属于哪个流的。
这样就真正解决了共享TCP连接时的队头阻塞问题，实现了真正的多路复用。
不仅如此，由于传输时是以帧为单元传输的，无论是响应还是请求，都可以实现并发处理，即不同的传输可以交替进行。
由于进行了分帧，还可以设置传输优先级。