HTTP 协议的演进本质是追求传输效率与资源利用率的平衡。本文剖析从 1.0 到 2.0 的技术迭代逻辑。
第一部分：HTTP 1.0 —— 基础与瓶颈
HTTP 1.0 确立了请求-响应模型，但其设计初衷仅为传输简单的超文本内容。
核心机制
- 短连接（Short Connection） ：默认采用“一求一连”模式。浏览器每次请求资源，都需要与服务器建立一个 TCP 连接，传输完成后立即断开。
- 无状态（Stateless） ：服务器不跟踪客户端状态，每次请求都是独立的。
致命缺陷
- TCP 连接成本极高：
每个请求都需要经历 三次握手 和 四次挥手。在加载包含数十个资源（图片、CSS、JS）的现代网页时，连接建立的耗时甚至超过数据传输本身。 - 严重的队头阻塞（Head-of-Line Blocking） ：
由于无法复用连接，前一个请求未处理完成前，后续请求无法发送（虽然可以通过浏览器开启多个并行连接缓解，但数量有限）。 - 缓存控制简陋：
主要依赖 Expires 和 Last-Modified，缺乏精细的控制策略。
第二部分：HTTP 1.1 —— 性能优化标准
HTTP 1.1 旨在解决 1.0 的连接效率问题，是当前互联网使用最广泛的协议版本。
核心改进
-
持久连接（Persistent Connection） ：
- 引入 Keep-Alive 机制，且默认开启。
- 允许多个 HTTP 请求复用同一个 TCP 连接，显著减少了 TCP 握手开销和慢启动（Slow Start）的影响。
-
管道化（Pipelining） ：
- 允许客户端在收到上一个响应前发送下一个请求。
- 痛点现状：服务器必须按请求顺序返回响应。若第一个请求处理阻塞，后续响应都会被拖延。因此，主流浏览器默认禁用此功能。
-
虚拟主机（Virtual Host） ：
- 引入 Host 头部字段。
- 允许在同一台物理服务器（同一 IP）上托管多个域名，是现代云主机和负载均衡的基础。
-
功能增强：
- 断点续传：引入 Range 头，支持只请求资源的某一部分（如 206 Partial Content）。
- 缓存增强：引入 Cache-Control、ETag 等机制，提供更复杂的缓存策略。
遗留问题
- 应用层队头阻塞：虽然 TCP 连接复用了，但 HTTP 请求依然是串行的。一旦某个请求发生阻塞，整个管道停滞。
- 头部冗余：Cookie 和 User-Agent 等头部信息在每次请求中重复传输，且未经压缩，浪费带宽。
- 文本协议解析低效：基于文本的解析容易出错且效率低于二进制解析。
第三部分：HTTP 2.0 —— 架构级变革
HTTP 2.0 并非简单的功能修补，而是对传输层的重新设计，旨在突破 HTTP 1.x 的性能天花板。
核心技术
-
二进制分帧（Binary Framing） ：
- 机制：抛弃 ASCII 文本，将所有传输信息分割为更小的消息和帧，并采用二进制编码。
- 价值：计算机解析二进制数据的效率远高于文本，且容错率更高。
-
多路复用（Multiplexing） ：
- 机制：基于二进制分帧，允许在同一个 TCP 连接中同时发送多个请求和响应。数据流（Stream）被打散为帧（Frame）乱序发送，接收端根据帧首部的流标识（Stream ID）进行重组。
- 价值：彻底解决了 应用层的队头阻塞 问题，实现了真正的并发传输。
-
头部压缩（HPACK） ：
- 机制：通信双方维护一张静态字典和动态字典。
- 价值：传输时仅发送索引号或差异数据，极大减少了 Header 的传输体积（尤其是 Cookie 较大的场景）。
-
服务端推送（Server Push） ：
- 服务器可在客户端请求 HTML 时，主动推送后续可能需要的 CSS 或 JS 资源，减少往返延迟（RTT）。
第四部分：总结对比
| 维度 | HTTP 1.0 | HTTP 1.1 | HTTP 2.0 |
|---|---|---|---|
| 连接管理 | 短连接（每请求新建 TCP） | 长连接（Keep-Alive 复用） | 多路复用（单 TCP 连接并发） |
| 数据格式 | 文本 | 文本 | 二进制（帧） |
| 并发机制 | 无 | 管道化（常被禁用，存在阻塞） | 多路复用（真正并发） |
| 头部处理 | 原文传输 | 原文传输 | HPACK 算法压缩 |
| 主机支持 | 单一主机 | 虚拟主机（Host 头） | 虚拟主机 |
| 内容获取 | 完整获取 | 断点续传（Range） | 断点续传 |
