HTTP1.0 到 HTTP3.0 的优化
HTTP 1.0
**请求过程：**每次发起请求都新建连接，一个连接只能传输一个请求和响应，下一个请求需要等上一个请求的响应到达才能发送。
- 每次发起请求都要新建TCP连接
- 无法多路复用： 只能按顺序传输一个请求和响应，无法同时传输多个请求和响应。
- 队头阻塞问题： 如果上一个请求的响应没收到，后续的请求会被阻塞。
HTTP 1.1
请求过程： 新建连接，一个连接可以传输多个请求和响应，可以同时发送多个请求，但是响应是按顺序返回的，响应可以分块返回。
- 长连接： 一个TCP连接传输多个请求和响应。
- 管道传输： 客户端可以同时发送多个请求，但是服务端需要按顺序响应请求，没有实质解决队头阻塞问题。
- 分块传输编码： 服务器不知道数据总大小时可以采用分块传输编码，此时 Content-Length 字段不会被包含在响应头中。可以通过特定的符号标识消息的结束。
- 虚拟主机： 在请求头添加 Host 字段，区分不同的主机。因为一台服务器可以有多个虚拟主机。
- 请求方式： 引入了更多的请求方式，如PUT、DELETE、OPTIONS等。
- 引入了更多的缓存控制选项： 引入了 Cache-Control 头部，它提供了一系列指令来控制缓存的行为，如 no-cache、no-store、max-age、public、private 等。这些指令允许更精细地控制资源是否可以被缓存以及缓存的条件。
HTTP 2.0
默认使用 HTTPS 进行传输
请求过程： 一个连接可以并行传输多个请求和响应，每个请求进行头部压缩，再将传输数据分成二进制帧，独立进行传输，接收端可以根据头部 ID 有序组装成正确信息。
-
多路复用： 允许同时通过一个连接并行传输多个请求和响应，解决了队头阻塞问题。
-
二进制分帧： 将传输的数据分成一个个二进制帧，可以独立传输，每个帧的头部会携带 Stream ID 信息，所以接收端可以通过 Stream ID 有序组装成 HTTP 消息。
-
头部压缩： 使用 HPACK 算法对头部信息进行压缩，减少了头部信息的传输量。
HPACK 算法：
在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，就不用重复发送同样字段了，只发送索引号，减少数据量提高速度 -
服务端推送： 服务端不再是被动地响应，可以主动向客户端发送消息、推送额外的资源，比如客户端请求网页，服务端会将相关的 CSS、JavaScript 或图片文件等。
HTTP 3.0
- 使用基于 UDP 协议的 QUIC 协议进行传输，解决 TCP 队头阻塞和 TCP 握手延迟的问题。
- 将一个连接分成多个数据流，每个数据流都有独立的 ID，可以独立控制和传输数据。