目录
- [1. 引言](#1. 引言)
- [2. HTTP/0.9 ------ 极简起源](#2. HTTP/0.9 —— 极简起源)
- [2.1 特点与局限](#2.1 特点与局限)
- [3. HTTP/1.0 ------ 网页的诞生](#3. HTTP/1.0 —— 网页的诞生)
- [3.1 新增特性](#3.1 新增特性)
- [4. HTTP/1.1 ------ 现代 Web 的基石](#4. HTTP/1.1 —— 现代 Web 的基石)
- [4.1 持久连接（Keep‑Alive）](#4.1 持久连接（Keep‑Alive）)
- [4.2 管线化（Pipelining）](#4.2 管线化（Pipelining）)
- [4.3 分块传输编码](#4.3 分块传输编码)
- [4.4 缓存增强](#4.4 缓存增强)
- [4.5 虚拟主机](#4.5 虚拟主机)
- [5. HTTP/2 ------ 性能革命](#5. HTTP/2 —— 性能革命)
- [5.1 二进制分帧](#5.1 二进制分帧)
- [5.2 多路复用（Multiplexing）](#5.2 多路复用（Multiplexing）)
- [5.3 首部压缩（HPACK）](#5.3 首部压缩（HPACK）)
- [5.4 服务器推送（Server Push）](#5.4 服务器推送（Server Push）)
- [5.5 流优先级与流控](#5.5 流优先级与流控)
- [6. HTTP/3 ------ 面向未来的 QUIC 协议](#6. HTTP/3 —— 面向未来的 QUIC 协议)
- [6.1 QUIC 与 UDP 的选择](#6.1 QUIC 与 UDP 的选择)
- [6.2 HTTP/3 的改进](#6.2 HTTP/3 的改进)
- [6.3 生态现状与挑战](#6.3 生态现状与挑战)
- [7. 总结与展望](#7. 总结与展望)- [HTTP 各版本核心特性对比](#HTTP 各版本核心特性对比)
1. 引言
当你打开一个网页、点击一个链接，背后都有一种协议在默默工作------这就是 HTTP（HyperText Transfer Protocol，超文本传输协议）。它几乎定义了整个万维网的数据交互方式。然而，我们今天所熟悉的 HTTP 并不是一蹴而就的，从 1991 年诞生的第一个版本开始，它经历了多次重大升级才演进到今天的高效形态。
对于刚开始学习计算机网络的朋友来说，理解 HTTP 的进化过程，不仅能掌握协议本身的知识，更能看懂性能问题背后的根本原因。本文将从 HTTP/0.9 开始，一步步带你了解它是如何演变成现代 Web 支柱的。
本教程假定你已经了解一些基础的网络概念（比如 IP 地址、TCP 连接），如果没有也不用担心，文中会适当补充必要的背景。
2. HTTP/0.9 ------ 极简起源
HTTP 的第一个文档化版本诞生于 1991 年，如今被称为 HTTP/0.9。它简单到只有一种请求方法：GET，并且不包含任何请求头或响应头。
一个典型的 HTTP/0.9 请求就像下面这样直接在 TCP 连接上发送的一行文本：
GET /index.html服务器收到后，会直接返回该文件的内容（通常是 HTML 文本），然后立即关闭 TCP 连接。这意味着每个请求都需要重新建立 TCP 连接，用完即丢。
2.1 特点与局限
- 无状态：服务器不会记住任何客户端信息。
- 只能传输 HTML：不能传图片、样式或其他资源。
- 无错误处理：如果文件不存在，服务器不会返回任何状态码，只是关闭连接，浏览器只能凭经验猜测。
- 连接即请求：一个 TCP 连接只能承载一个请求，每次都要完成三次握手和四次挥手，开销极大。
虽然极其简陋，但它奠定了"客户端请求-服务器响应"的基本交互模型，并证明了通过 TCP 传输超文本的可行性。这也是所有后来版本的起点。
3. HTTP/1.0 ------ 网页的诞生
1996 年发布的 HTTP/1.0（RFC 1945）对协议进行了大量扩充，使其真正成为一个"通用"的超文本传输协议。它的核心改进是引入了请求头 和响应头，让客户端和服务器能够交换更丰富的元信息。
一个典型的 HTTP/1.0 请求可能如下：
GET /index.html HTTP/1.0
Host: www.example.com
User-Agent: Mozilla/4.0
Accept: text/html服务器回复则包含状态行、头部和正文：
HTTP/1.0 200 OK
Content-Type: text/html
Content-Length: 1234
<html>...</html>3.1 新增特性
- 请求方法扩展：除了 GET，还新增了 POST、HEAD，使得浏览器可以向服务器提交表单。
- 状态码：标准化了响应状态码（200 OK，404 Not Found 等），让客户端能明确知道请求结果。
- 内容协商：通过 Accept、Content-Type 等头部，服务器可以返回多种格式，比如 HTML、图片、纯文本。
- 缓存控制：Expires 和 Last-Modified 头部让浏览器可以缓存资源，减少重复请求。
- 连接仍然短命：HTTP/1.0 默认依然每次请求都新建一个 TCP 连接，这带来了严重的性能问题。虽然可以通过 Connection: keep-alive 头部要求保持连接，但并非默认，也没有标准化。
随着网页内容越来越丰富（图片、CSS、JS），一个页面往往需要几十甚至上百个请求，重复建立和销毁 TCP 连接成为性能瓶颈。于是，HTTP/1.1 应运而生。
4. HTTP/1.1 ------ 现代 Web 的基石
1997 年发布的 HTTP/1.1（RFC 2068，后来被 RFC 2616 取代）是第一个真正意义上稳定并广泛部署的版本，至今仍是互联网的基础。它引入了多项关键优化。
4.1 持久连接（Keep‑Alive）
HTTP/1.1 默认开启持久连接（Connection: keep-alive），即一个 TCP 连接可以传输多个 HTTP 请求和响应，直到客户端或服务器主动关闭。这极大地减少了 TCP 握手和慢启动开销，对多个连续请求的页面尤其有益。
4.2 管线化（Pipelining）
在持久连接的基础上，HTTP/1.1 允许客户端在收到上一个响应之前就连续发送多个请求。理想情况下，这可以减少往返延迟。不过，管线化要求服务端严格按请求顺序返回响应，一旦中间某个请求处理较慢，后续响应就会被阻塞（队头阻塞，Head-of-line blocking）。因此，实际中很多浏览器和代理禁用了管线化，转而使用多个并发连接来弥补。
4.3 分块传输编码
对于动态生成的内容或未知大小的内容，HTTP/1.1 支持分块传输（Transfer-Encoding: chunked）。服务器可以一边生成数据一边发送，而不必事先知道总大小，这对于流式响应非常有用。
4.4 缓存增强
新增了 ETag、Cache-Control 等更精细的缓存控制机制，使得浏览器和中间代理能够更智能地利用缓存，减少数据传输。
4.5 虚拟主机
HTTP/1.1 强制要求请求头中包含 Host 头，使得同一 IP 可以托管多个域名（虚拟主机），这是现代 Web 大规模部署的基础。
尽管 HTTP/1.1 做了这么多改进，但受限于文本协议和单一连接的串行本质，它在高延迟、高带宽的网络环境下仍然存在性能天花板。浏览器通常通过开启 6-8 个并行 TCP 连接来加速，但这也带来了连接管理的复杂性和额外的内存、CPU 开销。
5. HTTP/2 ------ 性能革命
随着 Web 页面日益复杂（平均一个页面包含上百个资源），HTTP/1.1 的并行连接局限愈发明显。2015 年，HTTP/2（基于 Google 的 SPDY 协议，RFC 7540）正式发布，它不是对 HTTP/1.1 的补充，而是从传输层改变了数据交互方式。
5.1 二进制分帧
HTTP/2 将数据改为二进制编码，将请求和响应拆分成更小的帧（frame），并在同一个 TCP 连接上进行多路复用。这样一来，一个连接上可以同时存在多个并发的流，帧的收发完全交错，真正解决了 HTTP/1.x 的队头阻塞问题。
5.2 多路复用（Multiplexing）
借助二进制分帧，一个 TCP 连接内可以同时打开多个双向流，每个流承载一个请求-响应对。客户端可以一次性发送所有资源请求，服务器可以并行处理，并将资源帧交错返回，大大提高了连接利用率，也消除了浏览器排队的时延。
5.3 首部压缩（HPACK）
HTTP/1.x 每次请求都会携带大量冗余的首部信息（如 Cookie、User-Agent）。HTTP/2 使用 HPACK 压缩算法，对首部进行索引和压缩，显著减少了重复传输的开销。
5.4 服务器推送（Server Push）
服务器可以主动向客户端推送资源，而不需要客户端逐个发起请求。例如在返回 HTML 时，服务器可以同时推送必要的 CSS、JavaScript 文件，减少一轮往返。不过该功能在实践中使用比较谨慎，容易造成冗余推送。
5.5 流优先级与流控
HTTP/2 允许客户端设置流的优先级，使服务器可以优先传输关键资源（如 CSS 先于图片）。同时，基于流的流量控制防止速度快的发送方压垮接收方。
HTTP/2 在单个 TCP 连接上大幅提升了性能，降低了延迟。但它仍然运行在 TCP 之上，而 TCP 本身存在队头阻塞：一旦发生丢包，整个连接中所有流都会被迫等待重传，直到丢失的包被恢复。这在弱网环境下会影响体验。于是，下一代协议将目光转向了 UDP。
6. HTTP/3 ------ 面向未来的 QUIC 协议
为了彻底摆脱 TCP 队头阻塞的影响，互联网工程任务组（IETF）在 2022 年正式发布了 HTTP/3（RFC 9114）。它基于 Google 开发的 QUIC 协议，将传输层从 TCP 替换为 UDP，并在其上层实现了类似 TCP 的可靠性和拥塞控制。
6.1 QUIC 与 UDP 的选择
很多人奇怪为什么选择 UDP 而不是优化 TCP。原因在于，TCP 已经深深嵌入操作系统内核，如果想要大幅修改传输层的特性（比如支持多路复用而不受丢包影响），必须在操作系统层面进行，部署极为缓慢。而 UDP 只是一个简单庞大的报文协议，无需 OS 内核修改，QUIC 可以在用户空间实现，快速迭代。
QUIC 在 UDP 之上提供了：
- 连接迁移：使用 Connection ID 而非 IP+端口来标识连接，即使网络切换（Wi-Fi 到 4G），连接也不会中断。
- 0‑RTT 握手：对于已经建立过连接的客户端，可以在第一个包就携带应用数据，大幅降低建立连接的延迟。
- 内置 TLS 1.3：QUIC 强制加密，安全与传输合二为一，减少了协商开销。
- 真正无队头阻塞：QUIC 层面实现了多流并发，每个流独立处理重传。即使某条流的数据包丢失，也只会影响该流，其他流继续传输，不会被阻塞。
6.2 HTTP/3 的改进
HTTP/3 继承了 HTTP/2 的大部分优秀特性（多路复用、首部压缩、服务器推送等），只是将传输层换成 QUIC。除此之外，还做了一些适配：
- QPACK 压缩：替代 HTTP/2 的 HPACK，解决了 HTTP/2 首部流可能因 TCP 队头阻塞而卡顿的问题，支持独立流传输首部。
- 更快的连接建立：借助 QUIC 的 0‑RTT，首次连接甚至能节省大量往返时间。
如今，主流浏览器（Chrome、Firefox、Edge）和大型网站（YouTube、Facebook、Google 搜索等）均已支持 HTTP/3，普通用户可能在不知不觉中就已经享受到了它的性能红利。
6.3 生态现状与挑战
尽管 HTTP/3 带来了诸多提升，但它的普及仍需时间。一些企业防火墙、中间件可能还不支持 UDP 或 QUIC，导致连接回退到 HTTP/2；同时，QUIC 的加密机制也会增加一定的 CPU 开销，对低端设备有性能压力。不过，随着网络环境的进步，HTTP/3 正在逐步成为默认协议。
HTTP 各版本核心特性对比
| 版本 | 发布时间 / RFC | 核心特性 | 主要优势 | 主要局限 |
|---|---|---|---|---|
| HTTP/0.9 | 1991 年 | 仅支持 GET 方法；请求就是一行 GET /path 纯文本；无请求头、响应头、状态码；服务器返回 HTML 后立即关闭 TCP 连接 |
极简设计，实现成本极低；奠定了客户端-服务器交互模型；证明了通过 TCP 传输超文本的技术可行性 | 无状态、无错误处理（文件不存在只关连接）；只能传输 HTML，不支持图片/CSS/JS；每个请求都要经历完整 TCP 握手和挥手，吞吐量极低 |
| HTTP/1.0 | 1996 年，RFC 1945 | 引入 请求头/响应头；新增 POST、HEAD 方法；标准化状态码（200/404/500 等）；内容协商（Accept / Content-Type）；初步缓存（Expires / Last-Modified） | 支持传输多种 MIME 类型（HTML、图片、文本等）；状态码让客户端能精准判断结果并据此处理；表单提交成为可能；浏览器可缓存静态资源减少重复请求 | 默认短连接，每个请求新建 TCP；一个页面加载几十个资源时，TCP 握手开销极大；keep-alive 头部虽有实现但各家实现互不相同、未标准化 |
| HTTP/1.1 | 1997 年，RFC 2068 → RFC 2616 → RFC 7230--7235 | 持久连接 默认开启（Connection: keep-alive）；管线化（Pipelining）；Host 头强制，支持虚拟主机；分块传输编码（Transfer-Encoding: chunked）；缓存增强（ETag / Cache-Control）；新增 PUT、DELETE、OPTIONS 等方法；范围请求（Range） | 大幅减少 TCP 握手次数，显著降低延迟；一台物理服务器可托管多个域名网站，节省 IP 资源；支持流式响应，可边生成边发送；缓存策略更精细，配合 CDN 效果更好 | 文本协议串行处理，管线化易出现队头阻塞------浏览器大多禁用它仅靠并发连接（通常 6--8 个）弥补；多个连接各自维护，内存和连接开销增大；高 RTT 网络下表现不佳 |
| HTTP/2 | 2015 年，RFC 7540（基于 Google SPDY） | 二进制分帧层 ，数据拆分到帧和流；多路复用 （一个 TCP 连接上并发多个双向流）；HPACK 首部压缩；服务器推送（Server Push）；流优先级与流量控制 | 单 TCP 连接承载所有请求，消除应用层队头阻塞；二进制协议解析高效，帧交错传输真正并行；首部压缩让冗余 Cookie/UA 几乎零成本；可优先传输关键资源（CSS 先于图片） | 基于 TCP，一旦丢包触发重传，整个连接所有流都被阻塞（TCP 层队头阻塞）；弱网/移动网络体验受限；服务器推送用不好反而浪费带宽，实践中逐渐被废弃 |
| HTTP/3 | 2022 年，RFC 9114（基于 QUIC） | 传输层由 TCP 换为 QUIC（UDP） ；内置 TLS 1.3（加密必选）；0‑RTT 握手 ，连接建立极快；连接迁移 （Connection ID），Wi-Fi ↔ 4G 不断连；QPACK 首部压缩；真正无队头阻塞（每条流独立重传） | 根除 TCP 队头阻塞------单流丢包不影响其他流；连接建立延迟极低，首次连接 1‑RTT，重复连接可 0‑RTT；网络切换无感，移动场景体验大幅提升；加密默认集成，安全与传输一体 | UDP 在企业防火墙/中间件中可能被阻断，需回退到 HTTP/2；QUIC 的用户态加解密对 CPU 消耗较高，低端设备压力大；Nginx/Apache 等服务器支持仍在完善中，生态普及尚需时间 |
7. 总结与展望
回顾 HTTP 的进化：
- HTTP/0.9：只有 GET，极简只传 HTML。
- HTTP/1.0：引入请求头/响应头和状态码，但不保证持久连接。
- HTTP/1.1：持久连接、管线化、虚拟主机、缓存增强。
- HTTP/2：二进制分帧、多路复用、首部压缩、服务器推送，大幅提升单连接的利用率。
- HTTP/3：基于 QUIC，使用 UDP，内置加密，解决 TCP 队头阻塞，支持连接迁移和 0‑RTT。
这一进化史并不是简单的版本迭代，而是随着应用场景的复杂化和网络技术的发展，不断对"更快、更安全、更高效"的目标进行重构。如今，许多网站已经开启了 HTTP/3，而我们日常上网体验的提升，正是这些协议工程师们在底层的不断努力。
对于学习计算机网络的朋友，深入理解 HTTP 的演变，不仅有助于应对面试和考试，更能让你在设计 Web 服务、排查网络问题时拥有更清晰的思路。不妨打开浏览器的开发者工具，查看 Network 面板中的 Protocol 列，看看你正在访问的网站使用的是 HTTP/2 还是 HTTP/3，或许能让你对今天的文章有更直观的感受。
未来，随着 5G、边缘计算和更多实时应用的兴起，HTTP 协议很可能还会继续演化，或者出现新的替代协议。让我们一起期待 Web 的下一个十年。