HTTP 1.0 和 2.0 有什么区别？
- 标签：网络
🏛 业务架构师
HTTP 1.0 → 2.0 的关键升级，我按省下的成本讲：
- 长连接（1.1 keep-alive 的延续与强化）：1.0 默认一次请求一个连接，握手开销摊不下来。2.0 连接复用成为基础；
- 多路复用（核心）：1.1 同一连接上请求必须排队（队头阻塞——一个慢响应挡住后面所有），并发只能靠开多条 TCP 连接（浏览器对同域名限 6 条）；2.0 把请求响应拆成二进制帧，帧可交错传输、按流组装——一条连接上数百个请求并行，互不阻塞。连接数骤减 = 握手成本、内存占用、TIME_WAIT 全线下降——对高并发 Web 服务（每秒数万连接）是实打实的机器成本节约；
- 头部压缩（HPACK）：HTTP 头部重复率高（cookie 动辄几 KB），索引化压缩后体积降 80%+，移动端弱网场景的首屏时间直接受益；
- 服务端推送（实践少见，2.0 后来也被弃用倾向）。
业务视角的两点观察：
- RPC 框架早就用这套思想（Dubbo 的长连接多路复用、序列化），HTTP/2 等于把 RPC 的连接效率带给 Web 协议——协议演进就是把私有优化公共化；
- 落地注意：TCP 层队头阻塞仍在（丢包时整条连接所有流受影响），这是 HTTP/3 换 UDP 的动因；国内环境中间设备对 2.0 的兼容性问题让 HTTPS（TLS）成为事实前置条件。
一句话：HTTP/2 的商业逻辑是用更少的连接承载更多的请求——对用户是快，对平台是省。
🏗 系统架构师
按 HTTP 演进的三大痛点与解法讲：
HTTP/1.0：每请求一个 TCP 连接，用完即断——高延迟场景（每请求一次握手 + 慢启动）代价巨大。
HTTP/1.1 的缓解：keep-alive 长连接复用、管道化（因队头阻塞基本没人用）、缓存增强（ETag/Cache-Control）、Host 头支持虚拟主机。但遗留队头阻塞（HOL）：同连接请求必须串行响应，前一响应慢，后面全排队；并发只能靠浏览器开 6 个域名连接缓解。
HTTP/2 的三大升级：
- 二进制分帧：报文拆成帧，解析高效健壮；
- 多路复用：一条 TCP 连接上多个流并行交错传输，彻底解决 HTTP 层队头阻塞（但 TCP 层仍在：丢一个包，所有流都得等重传）；
- 头部压缩 HPACK：头部索引化 + 哈夫曼编码，重复 header 开销降 85%+；服务器推送（实际很少用，Chrome 已移除）。
架构视角：1.1 → 2 的收益曲线取决于页面请求数与头部重复度；高并发 API 网关开 HTTP/2（h2c/gRPC 都基于它）吞吐显著提升。但 TCP 层队头阻塞无解，催生 HTTP/3 换 QUIC。工程上注意：2.0 单连接多路复用在后端长连接场景下要调大拥塞窗口与流控窗口，否则吞吐反而上不去。
💻 全栈开发专家
核心差异：1.0 每请求一个连接，2.0 一连接多路复用 + 二进制分帧。
| 维度 | HTTP/1.0 | HTTP/2 |
|---|---|---|
| 连接 | 一请求一连接（默认短连接） | 单连接多路复用 |
| 格式 | 文本 | 二进制分帧（解析快、省体积） |
| 队头阻塞 | 连接级（请求串行） | HTTP 层解决（并行流），TCP 层仍在 |
| 头部 | 明文重复传 | HPACK 压缩 |
| 服务端推送 | 无 | 有（实际被浏览器放弃） |
1.1 的补丁史（顺带体现脉络）：keep-alive 长连接缓解建连开销；管线化（没人用）；浏览器开 6 个并发连接绕开串行——域名分片就是那个时代的优化。
2.0 怎么工作：一个 TCP 连接上拆出多个流（stream），每个请求/响应是独立流，帧交错传输、按流重组——并行请求不再互相等待。
工程实操提醒：
- HTTP/2 实际部署基本都是 over TLS（h2，ALPN 协商），先保证 HTTPS；
- 迁移到 h2 后关闭域名分片、减少雪碧图/合并文件这类 1.x 时代的 hack——多路复用下反而添乱；
- TCP 队头阻塞仍在：丢一个包，所有流都被卡（内核按序交付），这是 HTTP/3 上 QUIC 的动机；
- Nginx
listen 443 ssl http2;一行开启，升级前抓chrome://net-export对比 waterfall 验证收益。