表格汇总
| 对比维度 | HTTP/1.0 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|---|
| 传输协议 | TCP | TCP | TCP/TLS（默认加密） | UDP （基于 QUIC 协议） |
| 连接方式 | 短连接（每次请求/响应后断开） | 引入持久连接（Persistent Connection），默认长连接 | 多路复用（同一连接处理多个请求） | 多路复用（基于 UDP ，减少 连接建立延迟） |
| 头部处理 | 纯文本，无压缩 | 纯文本，部分缓存优化（如条件请求） | 二进制分帧 ，HPACK 算法压缩头部 | 二进制格式 ，QPACK 算法进一步压缩头部 |
| 性能问题 | 线头阻塞严重；连接频繁创建销毁开销大 | 缓解 线头阻塞（管道化技术 ，但未完全 解决）；同一域名并发连接数有限（6-8 个） | 解决线头阻塞 ；单连接 承载所有请求，减少连接开销 | 更低延迟 ；减少 TCP 握手和 TLS 协商时间 |
| 安全特性 | 无内置加密 | 无内置加密，需依赖 SSL/TLS | 强制 TLS 加密，安全性高 | 基于 TLS 1.3，安全性进一步提升 |
| 特性汇总 | 简单请求/响应模式 ，每次 请求需建立新连接，性能低、安全性差 | 支持长连接 ，减少连接开销；引入缓存控制 、断点续传 等优化，但仍存在线头阻塞 | 基于二进制分帧 和多路复用 ，解决 线头阻塞；默认加密，性能与安全性显著提升 | 基于 UDP 和 QUIC ，进一步降低延迟 ，抗网络拥塞能力强，安全性更高 |
一句话版本，及常见追问分析
- HTTP/1.0 ：采用短连接 ，每次请求都需重新建立和断开 TCP 连接，纯文本头部无压缩 ，性能较低且存在严重线头阻塞问题。
HTTP/1.0
追问：HTTP/1.0 的短连接机制 ，具体会带来哪些性能损耗 ？
回答：短连接每次请求都需经历 TCP 的三次握手 建立连接，请求完成后通过四次挥手断开 连接。这个过程涉及多次网络往返（RTT） ，会消耗额外的时间和资源。特别是对于包含大量资源请求的网页，频繁创建和销毁 连接会导致明显的延迟 ，同时增加 服务器的连接管理开销 ，降低 整体传输效率。
- HTTP/1.1 ：默认使用持久连接 减少连接开销，支持管道化 部分缓解线头阻塞，引入缓存控制和断点续传，但纯文本头部 和有限的并发连接仍制约性能。
HTTP/1.1
追问：HTTP/1.1 的管道化技术为什么没有彻底解决线头阻塞 问题？
回答：管道化允许客户端在一个 TCP 连接上 连续发送多个请求 而无需等待 响应，但服务器 仍需按顺序处理 和返回响应 。如果前面 的请求 因处理复杂或网络问题耗时较长 ，后续请求 的响应就会被阻塞 ，依然存在线头阻塞 。并且，由于不同浏览器对管道化的支持程度不一 ，实际应用中很多浏览器 出于兼容性和稳定性考虑，默认关闭该功能。
- HTTP/2 ：基于 TCP，通过二进制分帧 、多路复用 彻底解决线头阻塞，利用 HPACK 算法压缩头部 ，支持服务器推送，默认强制 TLS 加密，显著提升性能与安全性 。
HTTP/2
追问：HTTP/2 的二进制分帧和多路复用 如何配合解决线头阻塞 ？
回答：二进制分帧 将数据分割为更小 的二进制帧 ，每个帧带有唯一标识 ，可在连接中独立传输 ；多路复用则允许这些帧在同一 TCP 连接上混合交错传输 。这样一来，多个请求和响应 的帧能同时 在连接中流动 ，服务器 可以并行处理 请求，按任意顺序返回 帧，客户端再根据帧标识 重新组装 数据。即使某个请求的处理耗时较长，也不会影响其他请求帧的传输和响应，从而彻底解决线头阻塞问题。
- HTTP/3 ：基于 UDP 的 QUIC 协议 ，进一步降低连接建立延迟，减少 TCP 握手和 TLS 协商时间，具备更强的抗网络拥塞能力 ，结合 QPACK 头部压缩 和 TLS 1.3，实现低延迟与高安全性。
HTTP/3
追问：HTTP/3 选择 UDP 替代 TCP 作为传输层协议，主要解决了哪些 TCP 的固有问题 ？
回答：TCP 存在握手延迟 （至少 1 个 RTT 完成三次握手）、队头阻塞 （单个数据包丢 失会阻塞 整个连接 ）以及拥塞控制策略复杂 (慢开始、拥塞避免、快速重传、快速恢复 )等问题拥塞控制四大算法精简总结可看我的这篇文章【计算机网络】高频计网面试总结。HTTP/3 基于 UDP 的 QUIC 协议，通过 0-RTT （零往返时间）连接恢复减少握手延迟 ，利用流级别的多路复用，避免单个流阻塞影响其他流 ，同时集成了更高效 的拥塞控制算法和加密 机制，在弱网环境下能显著降低延迟 ，提升 传输性能 和抗网络抖动能力。