HTTP协议从1.0到3.0的发展历程
HTTP协议从1.0到3.0的发展历程
HTTP协议从1.0到3.0的发展历程中，经历了多次重大改进。从最初的短连接到长连接，从文本协议到二进制协议，从TCP到QUIC，每一次升级都带来了性能和效率的显著提升。本文将详细介绍HTTP各版本的主要特点和存在的问题。
HTTP 1.1
引入长连接：在HTTP 1.0中，每次请求都需要建立新的TCP连接，处理完毕后立即断开。这导致在处理大量图片、链接等资源时，需要频繁地建立和断开连接，造成资源浪费和时间延迟。而长连接允许在一个TCP连接上发起多次请求，减少了连接建立和断开的开销，提高了网络资源的利用率。
引入请求管道化：允许客户端同时发起多个请求，服务端根据接受到的请求依次处理回应，减少了等待时长。需要注意的是，请求管道化可以并发发送请求，但服务器仍依次回应。
引入更多的状态码：提供更加丰富的错误信息，方便开发人员定位问题，调试。
引入缓存机制：允许服务器发送“ETag”和“Last-Modified”等响应头字段，便于客户端进行条件性请求，避免不必要的资源传输，提高网络利用率。
存在的问题：
- 请求/响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩Body的部分；
- 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
- 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；
- 没有请求优先级控制；
- 请求只能从客户端开始，服务器只能被动响应
HTTP 2.0
二进制协议：使用二进制协议而不是文本格式来传输数据，解析更加高效。头信息和数据体都是二进制，称为帧。帧里面还有个流标识符，就可以按照顺序组合，不用按帧顺序抵达对方那里，而且帧类型里面还可以设置优先级，这样来标注流的权重。
多路复用：一个TCP连接上可以同时进行多个HTTP请求和响应，解决了HTTP 1.x的队头阻塞问题。（请求管道化，仅请求加快）
头部压缩：使用HPACK算法对头部进行压缩，减少了头部的大小，提高了传输效率，利用静态字典和动态字典来编码常见的头部值
服务器推送：服务器可以主动向客户端推送资源，而不需要客户端明确请求
存在的问题：
- TCP 层队头阻塞问题依然存在：虽然 HTTP/2.0 解决了自身协议层面在同一个连接内的队头阻塞，但它仍然基于 TCP 协议传输，当 TCP 层面出现丢包等情况导致某个帧重传时，整个 TCP 连接上的其他帧都可能受到影响，仍会出现一定程度的队头阻塞，影响传输效率。
HTTP 3.0
基于QUIC协议实现，而QUIC是基于UDP的传输协议，具有更低的延迟和更高的性能。
支持连接迁移，当客户端的网络环境发生变化，可以更加平滑的切换新网络，无需重新建立连接
在某些情况下，可以在第一个往返时间（RTT）内建立连接，减少了连接建立的延迟。
存在的问题：
QUIC 是一个在 UDP 之上的伪TCP + TLS + HTTP/2 的多路复用的协议。QUIC 是新协议，对于很多网络设备，根本不知道什么是 QUIC，只会当做 UDP，这样会出现新的问题，因为有的网络设备是会丢掉 UDP 包的，而 QUIC 是基于 UDP 实现的，那么如果网络设备无法识别这个是 QUIC 包，那么就会当作 UDP包，然后被丢弃。
HTTP/3 现在普及的进度非常的缓慢