一、 HTTP/0.9 & 1.0：协议的诞生与雏形

1. HTTP/0.9 (1991年)

• 设计初衷：极简的数据传输协议。
• 特征：
  • 单行协议：请求只有一行，例如 GET /index.html。
  • 无 Header：没有请求头和响应头。
  • 仅限 HTML：服务器只能返回 HTML 格式的字符串。
  • 连接模型：短连接。每次请求都需要建立 TCP 连接，响应结束后立即断开。

2. HTTP/1.0 (1996年)

随着互联网的发展，仅传输文字已无法满足需求。

• 核心改进：
  • 引入 Header：允许传输元数据（Metadata）。
  • 状态码 (Status Code)：如 200, 404, 500，明确告知请求结果。
  • 多媒体支持 (Content-Type)：可以传输图片、音频、视频等二进制文件。
  • 基础缓存：引入 Expires 和 Last-Modified。
• 致命痛点：
  • 连接无法复用：依然沿用短连接模型。加载一个包含 10 张图片的网页，需要建立 11 次 TCP 连接（1 次 HTML + 10 次图片）。
  • 性能损耗：TCP 三次握手和慢启动（Slow Start）机制导致严重的延迟。

二、 HTTP/1.1：标准确立与性能优化 (1997年)

HTTP/1.1 是目前互联网上使用最广泛的协议版本，它主要解决了连接复用问题。

1. 核心特性

• 持久连接 (Keep-Alive)：
  • 引入 Connection: keep-alive（默认开启）。
  • 允许在一个 TCP 连接上发送多个 HTTP 请求，大幅减少了 TCP 握手的开销。
• 管道化 (Pipelining)：
  • 试图允许客户端同时发送多个请求，而无需等待响应。
  • 失败告终：由于服务器必须按顺序返回响应，且实现复杂，现代浏览器默认均未开启此功能。
• 高级缓存控制：
  • 引入 Cache-Control (如 max-age, no-cache)，提供了比 HTTP/1.0 更精准的缓存策略。
  • 引入 ETag (实体标签)，通过内容哈希校验资源是否变更，比时间戳更可靠。
• Host 头：
  • 强制要求请求包含 Host 头。这使得虚拟主机 (Virtual Hosting) 成为可能，即一台物理服务器可以托管多个域名。
• 丰富的方法 (Methods)：
  • 规范了 PUT, DELETE, OPTIONS, PATCH 等方法，为后来的 RESTful API 奠定了基础。
• 断点续传：
  • 引入 Range 头，允许请求资源的特定部分（如视频拖拽播放）。

2. 遗留痛点：HTTP 队头阻塞 (Head-of-Line Blocking)

虽然 Keep-Alive 复用了连接，但 HTTP/1.1 的请求处理依然是串行的。

• 现象：在一个 TCP 连接中，如果第一个请求处理很慢（例如数据库查询耗时 2秒），后续的请求（哪怕只是一个 1KB 的 CSS 文件）都必须排队等待。
• 临时方案：浏览器为了缓解这个问题，通常会针对同一个域名同时建立 6 个 TCP 连接（并发限制）。但这大大增加了服务器的资源消耗。

三、 HTTP/2：二进制分帧与多路复用 (2015年)

HTTP/2 是对 HTTP 传输层的彻底重构，旨在应用层解决性能瓶颈。

1. 二进制分帧 (Binary Framing)

• 改变：HTTP/1.x 是文本协议（可读性好，但解析低效），HTTP/2 是二进制协议。
• 机制：将传输信息分割为更小的帧 (Frame)，并进行二进制编码。

2. 多路复用 (Multiplexing) —— 最核心变革

• 机制：在单一 TCP 连接上，可以并行交错发送无数个请求和响应。
• 优势：彻底解决了 HTTP 1.1 的队头阻塞问题。
• 效果：浏览器不再需要建立 6 个连接，通常一个域名只需要一个 TCP 连接。

3. 头部压缩 (HPACK)

• 背景：HTTP 请求头通常包含大量重复信息（如 Cookie, User-Agent），且每次请求都要重复发送，浪费带宽。
• 机制：客户端和服务器共同维护静态字典和动态字典，使用索引号代替重复的 Header 字段，大幅减少传输体积。

4. 服务端推送 (Server Push)

• 机制：服务器可以预测客户端需要的资源（如请求 index.html 时主动推送 style.css）。
• 现状：由于缓存一致性难以处理，该特性在实践中并未广泛流行，Chrome 已计划移除，推荐使用 103 Early Hints。

5. 新的痛点：TCP 队头阻塞

HTTP/2 虽然解决了应用层的队头阻塞，但将所有数据都压在一个 TCP 连接上，导致了TCP 层面的队头阻塞。

• 现象：TCP 保证数据按序到达。一旦发生丢包，操作系统内核会暂停将后续数据包交付给应用层，直到丢失的包重传成功。
• 结果：在弱网环境下（高丢包率），HTTP/2 的性能表现可能反而不如 HTTP/1.1（因为 HTTP/1.1 有多个连接，一个断了不影响其他）。

四、 HTTP/3：基于 UDP 的革新 (2022年 RFC 标准化)

为了解决 TCP 的固有缺陷，HTTP/3 抛弃了 TCP，改用基于 UDP 的 QUIC 协议。

1. QUIC 协议 (Quick UDP Internet Connections)

HTTP/3 将传输层从 TCP 换成了 UDP，并在应用层（用户态）实现了可靠传输机制。

2. 真正的独立流 (Independent Streams)

• 机制：每个流（Stream）在逻辑上是独立的。
• 优势：彻底解决 TCP 队头阻塞。如果 Stream A 的数据包丢失，只会阻塞 Stream A，Stream B 和 C 依然可以正常传输。

3. 0-RTT 极速握手

• 机制：QUIC 将传输握手和 TLS 加密握手合并。
• 效果：
  • 首次连接：1 RTT。
  • 再次连接：0 RTT（直接发送加密数据）。

4. 连接迁移 (Connection Migration)

• 背景：TCP 连接由四元组（源IP、源端口、目标IP、目标端口）标识。切换网络（如 Wi-Fi 切 4G）会导致 IP 变化，连接断开。
• 机制：QUIC 使用 Connection ID (CID) 标识连接。
• 优势：只要 CID 不变，即使用户 IP 发生变化，连接依然保持，无需重连。这对移动端应用极其重要。

五、 实战指南：Go 语言实现 (Gin / Echo)

在 Go 语言中，启用 HTTP/2 非常简单，因为标准库 net/http 原生支持。启用 HTTP/3 则需要引入 quic-go。

1. Gin 框架 (HTTP/2)

只要开启 TLS (HTTPS)，Go 会自动协商升级到 HTTP/2。

2. Echo 框架 (HTTP/2)

同理，使用 StartTLS 即可。

3. 启用 HTTP/3 (QUIC)

需要使用 github.com/quic-go/quic-go/http3 包。

六、 协议选型建议

总结：对于绝大多数公网 Web 应用，HTTP/2 + HTTPS 是标准配置。如果你专注于移动端体验优化，应该开始尝试 HTTP/3。