HTTP 2.0 和 3.0 有什么区别？
- 标签：网络
🏛 业务架构师
HTTP/3 的核心变化：传输层从 TCP 换成 QUIC（基于 UDP）。动因是 TCP 的两个先天问题：
- 队头阻塞：HTTP/2 多路复用后，应用层不阻塞了，但 TCP 层仍有序：一个包丢失，整条连接上所有流都得等重传——流越多，这个问题越疼。QUIC 在 UDP 上自己实现可靠传输，流之间独立恢复，丢包只影响所在的流；
- 握手开销：TCP 握手 + TLS 握手串行多次 RTT。QUIC 把传输握手与 TLS 1.3 握手合并成 1-RTT，会话恢复可 0-RTT——弱网移动端首屏时间显著缩短；
- 附带收益：连接迁移（Connection ID 标识连接，手机从 WiFi 切 4G 不断线——对 IM、支付中的长请求是体验升级）。
业务视角的两个观察：
- 谁在推动、为什么：Google（YouTube、搜索）是急先锋——页面每慢 100ms 转化率掉 1%，QUIC 对弱网移动用户的首屏改善直接换成广告与交易收入。协议演进从来由商业疼痛驱动，不是学术审美；
- 落地的现实成本：内核 TCP 摸不着，QUIC 跑用户态（服务端要改造或用负载均衡/CDN 代理——多数公司靠云厂商 CDN 边缘启用）；中间设备对 UDP 的 QoS 歧视（限速、拦截）让QUIC 需要 fallback 到 TCP 的双栈兼容。国内 App 大厂自研接入层已普遍支持，普通 Web 业务走 CDN 打开即可获得收益。
一句话：HTTP/3 用"换底盘"解决 TCP 的历史包袱，弱网移动场景的体验与转化是它的商业理由——评估是否跟进时，先看你的流量里弱网移动占比有多高。
🏗 系统架构师
两者都在解决 HTTP/2 的遗留问题，路线是一次底层传输更替：
HTTP/2 的未竟之事：多路复用解决了 HTTP 层队头阻塞，但TCP 层队头阻塞仍在——所有流共享一条 TCP 连接，丢一个包，TCP 的有序交付保证让所有流一起等重传；弱网/高丢包场景（移动网络）HTTP/2 甚至可能不如开多条 HTTP/1.1 连接。另外 TCP + TLS 两次握手串行，建连慢；连接迁移不可能（四元组变了连接就断，WiFi 切 4G 断线重连）。
HTTP/3 的答案——换 QUIC（UDP 上重建传输层）：
- 流级独立：QUIC 的流彼此独立交付，一个流丢包只阻塞自己——根治队头阻塞；
- 0/1-RTT 建连：传输握手与 TLS 1.3 握手合并，首次 1-RTT、复用连接 0-RTT；
- 连接迁移：用 Connection ID 标识连接而非四元组，网络切换不断线——移动端体验质变；
- 用户态实现，迭代不受内核与中间盒（老旧 TCP 设备）拖累；内置加密，明文传输不复存在。
工程影响：Google/Cloudflare 大规模启用后 P99 明显改善；服务端支持需要新栈（nginx/quiche、Envoy）且 UDP 在部分企业防火墙/负载均衡被限速，落地有兼容成本；客户端 HTTP/3 需要 Alt-Svc 协商与回退机制。我的判断：QUIC 是弱网时代的必然选择，新架构设计（尤其移动 PaaS、实时业务）应预留支持。
💻 全栈开发专家
本质区别：HTTP/3 把传输层从 TCP 换成了 QUIC（基于 UDP），为了解决 HTTP/2 遗留的 TCP 队头阻塞和握手延迟。
2.0 的痛点：HTTP 层多路复用了，但内核 TCP 保证按序交付——一个包丢失，所有流都要等重传（TCP 队头阻塞），弱网下 HTTP/2 甚至可能比 1.1 多连接更慢。
3.0 的关键改进：
- 传输层无队头阻塞：QUIC 的流相互独立，丢包只影响所在流；
- 连接建立更快：1-RTT 甚至 0-RTT（复用之前的会话密钥，首包就带数据），对比 TCP+TLS1.3 的 2~3 RTT；
- 连接迁移：连接标识不再绑定四元组，WiFi 切 4G 连接不断（手机用户感知明显）；
- 用户态实现：QUIC 在应用层做拥塞控制，迭代不用等内核升级；内置 TLS 1.3；
- 头压缩从 HPACK 换 QPACK（适配乱序到达）。
工程落地现状与实操：
- Nginx 1.25+：
listen 443 quic reuseport;+add_header Alt-Svc 'h3=":443"';（先用 Alt-Svc 告知客户端可用 h3，浏览器自动升级）； - 前提：UDP 443 要放行——不少公司防火墙/CDN 默认只通 TCP，这是上线 h3 最常见的拦截点；
- 验证：Chrome 里查看协议列是否显示 h3，
curl --http3测试连通性。移动端弱网场景收益最大。