HTTP1.1、HTTP2、HTTP3
这三个版本分别代表了 Web 传输协议的三个重要演进阶段，核心区别在于性能、连接管理和底层传输机制。
简单总结：HTTP/1.1 是串行单车道，HTTP/2 是多路复用单车道，HTTP/3 是多车道高速路。
核心特性对比
| 特性 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 底层传输 | TCP | TCP | QUIC (基于 UDP) |
| 连接方式 | 串行，队头阻塞 | 多路复用，但仍受 TCP 队头阻塞影响 | 无队头阻塞 |
| 头部压缩 | 无（纯文本） | HPACK（有状态压缩） | QPACK（改进压缩） |
| 服务器推送 | 不支持 | 支持 | 支持 |
| 明文/加密 | 可选（通常明文或 TLS） | 强烈建议 TLS（h2 需 ALPN） | 强制加密（TLS 1.3） |
| 协议协商 | 无 | 通过 ALPN | 通过 Alt-Svc 或 DNS |
HTTP1.1（1999年）
HTTP/1.1 相比 HTTP/1.0 性能上的改进：
- 使用长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
- 支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。
但 HTTP/1.1 还是有性能瓶颈：
- 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩
Body的部分； - 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
- 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；
- 没有请求优先级控制；
- 请求只能从客户端开始，服务器只能被动响应。
HTTP2（2015年）
HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。基于TLSV1.2。
那 HTTP/2 相比 HTTP/1.1 性能上的改进：
- 头部压缩
- 二进制格式
- 并发传输
- 服务器主动推送资源
HTTP3（2022年，全新架构）
根本变化：抛弃 TCP，改用QUIC（Quick UDP Internet Connections）。
QUIC 的优势：
无队头阻塞：QUIC 内部多路复用，一个流丢包只阻塞该流，其他流不受影响。
0-RTT 连接恢复：之前连接过的客户端可立即发送数据，大大减少握手时间。
连接迁移：通过连接 ID 识别，即使 IP 变化（如 Wi-Fi 切 4G）连接仍保持，无需重新握手。
集成加密：强制 TLS 1.3，减少握手往返。
代价：UDP 在某些老旧网络或防火墙可能被限流或丢弃；QUIC 实现比 TCP 复杂。
- HTTP/1.1 中的管道（ pipeline）虽然解决了请求的队头阻塞，但是没有解决响应的队头阻塞，因为服务端需要按顺序响应收到的请求，如果服务端处理某个请求消耗的时间比较长，那么只能等响应完这个请求后， 才能处理下一个请求，这属于 HTTP 层队头阻塞。
- HTTP/2 虽然通过多个请求复用一个 TCP 连接解决了 HTTP 的队头阻塞 ，但是一旦发生丢包，就会阻塞住所有的 HTTP 请求，这属于 TCP 层队头阻塞。
HTTP/2 队头阻塞的问题是因为 TCP，所以HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！基于TLSv1.3+。
Google的一些初步实验证明，QUIC作为Google部分热门服务的底层传输协议，极大地提高了速度和用户体验。部署QUIC作为YouTube视频的底层传输协议，导致YouTube视频流的缓冲率下降了30%，这直接影响了用户的视频观看体验。在显示谷歌搜索结果时，也有类似的改善。
网络条件较差的情况下提升非常明显，这促使谷歌更加积极地完善该协议，并最终向IETF提出标准化。
由于这些早期的试验所带来的所有改进，QUIC已经成为带领万维网走向未来的重要因素。在QUIC的支持下，HTTP从HTTP/2到HTTP/3的改头换面，朝着这个方向合理地迈出了一步。