HTTP/1.0、1.1、2、3 有什么区别？

详细解析#

HTTP/1.0#

默认短连接：每个请求都要新建 TCP 连接，响应完就关闭，每次都要付出握手和慢启动的代价。部分实现用 Connection: keep-alive 扩展来保持连接，但它不是 1.0 规范的一部分。

HTTP/1.1#

• 默认持久连接：一个 TCP 连接可以发送多个请求，不想保持时用 Connection: close 声明（见 keep-alive）
• Host 请求头：必须携带，让一台服务器（一个 IP）可以托管多个站点
• 分块传输编码：Transfer-Encoding: chunked，不知道响应总长度时也能边生成边发送
• 更完善的缓存控制：Cache-Control、ETag 等（见 HTTP 缓存）
• 范围请求：Range 请求头和 206 状态码，支持断点续传
• 管道化（pipelining）：规范允许不等响应就连续发送多个请求，但响应必须按请求的顺序返回，加上很多代理处理不好，浏览器基本都没有启用

HTTP/1.1 的问题：同一个连接上，后一个请求要等前一个响应返回（HTTP 层的队头阻塞）；浏览器对同一域名通常只开约 6 个连接，资源一多就要排队；头部是文本、不压缩，每个请求都重复发送 Cookie、User-Agent 等。于是出现了域名分片、雪碧图、合并文件等优化手段。

HTTP/2#

• 二进制分帧：请求和响应被拆成更小的帧（如 HEADERS 帧、DATA 帧），每个帧都标明自己属于哪个流
• 多路复用：一个 TCP 连接上可以同时存在多个流，不同流的帧交错发送，接收方按流 ID 重新组装，解决了 HTTP 层的队头阻塞
• 头部压缩 HPACK：双方维护静态表和动态表，重复的头部只需发送索引，再配合哈夫曼编码
• 流优先级：客户端可以告诉服务器哪些资源更重要。最初的方案（依赖树加权重）过于复杂、各家实现不一，RFC 9113 已经把它弃用，现在推荐用 RFC 9218 定义的 Priority 头部等更简单的信号
• 服务器推送：服务器可以主动推送浏览器还没请求的资源。实际效果不理想（容易推送浏览器已经缓存的资源），Chrome 等主流浏览器已经移除了对它的支持，替代方案是 103 Early Hints 和 preload（见 资源提示）
• 浏览器只支持基于 TLS 的 HTTP/2

HTTP/2 的问题：所有请求共用一个 TCP 连接，而 TCP 要求按序交付，一个数据包丢失，后面所有流的数据都要等它重传，这是 TCP 层的队头阻塞（见 TCP 可靠传输）。丢包越多，影响越明显。

HTTP/3#

• 基于 QUIC：QUIC 运行在 UDP 之上，自己实现了可靠传输和拥塞控制。它知道连接里有哪些流，每个流独立按序交付，一个流丢包只影响这个流
• 建立连接更快：QUIC 集成了 TLS 1.3，把传输握手和加密握手合在一起，首次连接只需 1 个 RTT，恢复之前的连接时可以 0-RTT（见 HTTPS）。作为对比，TCP + TLS 1.3 需要 2 个 RTT
• 连接迁移：TCP 用四元组（源 IP、源端口、目的 IP、目的端口）标识连接，手机从 Wi-Fi 切到移动网络，IP 一变连接就断了；QUIC 用 Connection ID 标识连接，切换网络后可以继续使用原来的连接
• 头部压缩 QPACK：HPACK 要求按顺序处理头部，放到 QUIC 互相独立的流上会重新引入队头阻塞，所以改用 QPACK

对比#

优化手段的变化#

HTTP/1.1 时代的一些优化，在 HTTP/2 下反而可能有害：域名分片会建立多个连接，失去多路复用和头部压缩的好处，还多了 DNS 解析和握手；过度合并文件会让缓存粒度变粗，改一行代码，整个大文件的缓存就失效了。

面试官可能追问#

易错点#

• HTTP/2 解决的是 HTTP 层的队头阻塞，TCP 层的队头阻塞要到 HTTP/3 才解决
• 管道化不等于多路复用：管道化的响应仍然必须按请求顺序返回
• HTTP/3 跑在 UDP 上不代表不可靠，QUIC 自己实现了确认、重传和拥塞控制