HTTP/2和HTTP/3有什么区别？网站传输性能与协议特性对比

网站打开慢，很多人第一反应是"带宽不够"。但实际上，页面里塞了几百个请求，真正拖慢加载的往往是协议本身。同一台服务器、同样的带宽，换成 HTTP/2 或 HTTP/3，首屏时间可能明显下降——这不是玄学，而是协议设计差异带来的。

这篇文章讲清三代 HTTP 协议的性能瓶颈：HTTP/1.1 的队头阻塞、HTTP/2 的多路复用怎么解决它、HTTP/3 为什么又推翻 TCP 改用 UDP。给出协议特性对比表、性能差异量级参考和升级建议。读完你能判断自己的站该不该上 HTTP/2，以及 HTTP/3 值不值得开。

一、HTTP/1.1 的队头阻塞

HTTP/1.1 有个根本限制：在一条 TCP 连接上，同一时刻只能处理一个请求-响应。虽然它发明了"管道化"（pipelining），但响应必须按请求顺序返回，服务器处理慢的那个请求会挡住后面的，这叫应用层队头阻塞。

浏览器的应对办法是开多条并行连接（通常每个域名 6 条）。于是诞生了一系列"土办法"：域名分片（把静态资源放多个子域绕开 6 连接限制）、雪碧图（把小图拼成一张减少请求）、内联小文件、合并 JS/CSS。这些优化本质上都是为了绕开 HTTP/1.1 的缺陷。

此外，HTTP/1.1 的头部是纯文本且不压缩，每发一个请求都要重复发送一大堆 Cookie、User-Agent，头部开销在小请求里占比惊人。

二、HTTP/2：一条连接搞定所有

HTTP/2 的核心目标就是消灭队头阻塞、降低开销。它引入了几项关键机制：

二进制分帧。HTTP/2 不再传文本，而是把请求/响应切成一个个"帧"（Frame），帧里有类型、流 ID、标志位。二进制解析更快、更省空间，也让多路复用成为可能。

多路复用。所有请求都跑在一条 TCP 连接上，每个请求是一个"流"（Stream），帧可以交错发送，接收端按流 ID 重组。这样浏览器不用再开 6 条连接，也基本告别了域名分片、雪碧图这些优化。

头部压缩（HPACK）。HTTP/2 维护一张头部的动态表，重复出现的头（如 User-Agent、Cookie）只发索引号，不再重复发全文，大幅降低头部开销。

服务器推送。服务器可以在客户端请求 HTML 时，主动把 CSS、JS 推过去，省去客户端解析后再请求的往返。不过实践中推送容易造成浪费，主流方案后来多改为 preload。

流的优先级与依赖。客户端可以声明哪些流更重要，让服务器优先返回关键资源。

但 HTTP/2 有个致命遗留问题：它仍然跑在 TCP 上。TCP 保证"字节按序到达"，一旦某个 TCP 包丢了，即使它只属于某一个流，所有流都得等这个包重传——这叫 TCP 层队头阻塞。在丢包率高的网络（弱网、移动网络）下，HTTP/2 的多路复用反而会因为共用一个 TCP 连接而集体卡顿。

三、HTTP/3：甩掉 TCP，改用 QUIC

HTTP/3 的思路很彻底：既然 TCP 的按序交付是瓶颈，那就不用 TCP，改用基于 UDP 的 QUIC 协议。QUIC 在 UDP 之上自己实现了可靠传输、拥塞控制、加密，把 TCP 该干的事都用更灵活的方式重做了一遍。

解决队头阻塞。QUIC 的多路复用是在流这一层做到独立的。每个流的数据独立排序、独立重传，一个流丢包只影响它自己，不会拖累其他流。这从根本上消除了 TCP 层的队头阻塞（虽然单个流内部仍有队头阻塞）。

0-RTT 建连。QUIC 把传输握手和 TLS 1.3 握手合并，首次连接 1-RTT，再次连接可以 0-RTT 直接发数据。传统 TCP + TLS 至少需要 2 个往返，QUIC 省掉大半。

连接迁移。TCP 连接用四元组（源 IP、源端口、目的 IP、目的端口）标识，手机从 Wi-Fi 切到 4G 时 IP 变了，连接就断了。QUIC 用不依赖 IP 的 Connection ID 标识连接，网络切换时连接不断，正在下载的文件、正在看的视频可以平滑继续。

强制加密。QUIC 从设计上就要求加密，几乎没有明文可乘之机。

代价是：UDP 在部分企业防火墙、老旧设备上被限制或限速；QUIC 全在用户态实现，CPU 开销比内核态 TCP 大一些；可观测性工具对 QUIC 的支持还不如 TCP 成熟。

四、三代协议对比

五、性能差异的量级参考

下面这些数字是经验范围，实际效果取决于页面结构、网络质量和服务器配置，不能当承诺值：

• HTTP/1.1 → HTTP/2：在请求数多的页面（几十上百个资源）上，首屏时间通常能有可观改善，头部开销大幅下降，弱网下改善更明显。
• HTTP/2 → HTTP/3：在丢包率较高的网络（比如移动网络、跨运营商）改善最明显；在低丢包的有线环境下，两者差距不大，HTTP/3 的优势主要体现为建连更快（0-RTT）。
• 单纯提升带宽对首屏的帮助，往往不如换协议来得直接——因为瓶颈常在延迟和请求数，不在带宽。

六、怎么开启和验证

开启 HTTP/2（在 HTTPS 基础上）：

server {
    listen 443 ssl;
    http2 on;          # nginx 1.25.1+ 写法；旧版本用 listen 443 ssl http2;
    server_name example.com;
    ssl_certificate     /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;
    ssl_protocols TLSv1.2 TLSv1.3;
}

开启 HTTP/3（需要 nginx 编译了 HTTP/3 模块，或使用支持 QUIC 的版本）：

server {
    listen 443 ssl;
    listen 443 quic reuseport;   # HTTP/3
    http2 on;
    http3 on;
    server_name example.com;
    ssl_certificate     /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;
    # 告知浏览器可用 HTTP/3
    add_header Alt-Svc 'h3=":443"; ma=86400';
}

注意 HTTP/3 走 UDP 443，防火墙必须放行 UDP：

# RHEL/CentOS/Rocky 8+（firewalld）
sudo firewall-cmd --permanent --add-port=443/udp
sudo firewall-cmd --reload

# Debian/Ubuntu（ufw）
sudo ufw allow 443/udp
sudo ufw reload

风险提示：改动 nginx 配置前先备份（cp nginx.conf nginx.conf.bak），并用 nginx -t 测试语法再 reload。回滚方式：恢复备份文件后 nginx -s reload。

验证协议版本：

# curl 查看 HTTP 版本（支持 HTTP/2/3 的 curl）
curl -I --http2 https://example.com
curl -I --http3 https://example.com

# 看响应头里的协议信息
curl -sI https://example.com | grep -i -E 'HTTP|alt-svc'

# 用浏览器开发者工具 Network 面板看 Protocol 列

七、升级建议

先上 HTTPS。HTTP/2 和 HTTP/3 在主流浏览器上都要求 TLS，且都在 443 端口，所以第一步是把站点切到 HTTPS。

大多数站点直接上 HTTP/2。它是当下的默认配置，兼容性好，收益稳定。开启后可以去掉域名分片、雪碧图、文件合并这些为 HTTP/1.1 打的补丁——它们对 HTTP/2 不仅无益，还可能有害（合并大文件反而拖慢首屏）。

有大量移动端用户或跨地域访问的站点，再叠加 HTTP/3。通过 Alt-Svc 头让浏览器平滑回退：支持 QUIC 的用 HTTP/3，不支持的自动用 HTTP/2，不需要二选一。

别指望换协议解决所有性能问题。后端响应慢、数据库慢、图片没压缩、没上 CDN，换再新的协议也救不回来。协议优化是"减少等待"，业务优化是"缩短处理"。

常见问题

Q：HTTP/2 是不是一定要 HTTPS？
A：规范上允许 h2c（明文 HTTP/2），但主流浏览器只支持 h2 over TLS。所以对网站来说，HTTP/2 事实上绑定 HTTPS。

Q：开了 HTTP/2 还要做域名分片、雪碧图吗？
A：不需要，甚至应该去掉。HTTP/2 一条连接多路复用，多域名反而增加建连成本，雪碧图会让单个大文件阻塞更久。

Q：HTTP/3 为什么用 UDP，不是很不可靠吗？
A：UDP 只是承载管道，QUIC 在它之上自己实现了可靠传输、重传、拥塞控制。它要的是 UDP 的"无连接、可自定义"特性，然后把可靠性用更适合多路复用的方式重新实现。

Q：怎么知道用户实际用的是哪个版本？
A：看 nginx 访问日志（可自定义格式记录 $server_protocol），或用 CDN 的协议统计面板；本地测试用浏览器开发者工具的 Protocol 列。

Q：HTTP/3 上不去，先查什么？
A：先确认 UDP 443 是否被防火墙或云安全组放行；再确认 nginx 是否编译了 HTTP/3 模块；最后看客户端是否支持（curl 需要 --http3 支持版本）。

总结

• HTTP/1.1 有应用层队头阻塞，靠多连接和域名分片等土办法绕过，头部不压缩开销大。
• HTTP/2 用二进制分帧、多路复用、HPACK 头部压缩解决应用层阻塞，但仍在 TCP 上，丢包时全流等待。
• HTTP/3 基于 QUIC/UDP，流级独立重传消除队头阻塞，支持 0-RTT 和连接迁移，要求强制加密。
• 量级参考：请求多的页面 HTTP/1.1 → HTTP/2 收益明显；高丢包弱网下 HTTP/2 → HTTP/3 收益明显；有线低丢包环境两者差距不大。
• 升级路径：先 HTTPS → 普遍开 HTTP/2 → 移动/跨地域站点叠加 HTTP/3（用 Alt-Svc 平滑回退），并去掉为 HTTP/1.1 设计的旧优化。