这篇文章一方面会陈述HTTP各个版本的历史，另一方面会对各个版本做一个点评，但不会去分析各个更新的技术细节。笔者作为一名Web从业者，对性能较为敏感，会对各版本在性能方面的变更脉络进行梳理。
HTTP 协议的核心标准化版本主要有 HTTP/0.9、HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3，其中 HTTP/1.1 是长期主流版本，HTTP/2 和 HTTP/3 为现代高性能版本。
一、HTTP/0.9
推出时间：1991 年（非正式标准，原型版本）
核心特点：
- 仅支持 GET 一种请求方法，无请求头、响应头；
- 响应体仅为纯 HTML 文本，无状态、无缓存、无编码；
- 一次请求对应一次 TCP 连接，请求完成即断开（短连接）；
现状：早已退出历史舞台，现代浏览器和服务器均不再支持。仅作为协议演进的起点被提及。
笔者点评：纯纯的"能跑就行"时代，那会还只有静态页，性能、交互还不在设计蓝图里。
二、HTTP/1.0
推出时间：1996 年 5 月
核心特点：
- 新增 POST、HEAD 请求方法；
- 引入请求头、响应头（如 Content-Type、Content-Length），支持非 HTML 内容（图片、文件）；
- 支持状态码（如 200、301、404）；
- 仍为短连接（一次请求一个 TCP 连接），无持久连接机制，性能低下；
- 支持基本的缓存（Expires 头）、字符编码（Content-Encoding）。
现状：虽被 HTTP/1.1 取代多年，但部分老旧系统、嵌入式设备或简易 HTTP 客户端仍可能使用。主流 Web 场景已基本淘汰。
笔者点评：这个思路如果放到现在就是入门开发者的基础操作------把该有的功能补全了，但完全没get到性能痛点。短连接这个硬伤，还是无法满足多资源加载的场景。服务器都累麻了，但页面速度还是拉胯。
三、HTTP/1.1
推出时间：1999 年 6 月
核心特点：
- 默认持久连接（Keep-Alive）：TCP 连接可复用，解决短连接的连接建立开销，是 HTTP/1.1 成为长期主流的核心原因；
- 支持管道化（Pipeline）：允许同一连接中并行发请求（实际浏览器默认关闭，因队头阻塞）；
- 新增 PUT、DELETE、OPTIONS、TRACE、CONNECT 等请求方法，完善 RESTful 基础；
- 引入 Host 头（必选），支持一台服务器对应多个域名（虚拟主机），解决 HTTP/1.0 的多域名部署问题；
- 优化缓存机制：新增 Cache-Control、ETag、Last-Modified，支持强缓存 / 协商缓存，缓存更灵活；
- 支持分块传输（Transfer-Encoding: chunked）：无需提前声明 Content-Length，适合动态生成内容；
- 完善状态码：新增 401、403、500、503 等常用状态码。
现状：仍是兼容性最强的版本，几乎所有客户端和服务端都支持。虽然性能不如 HTTP/2/3，但在不支持 TLS 或旧环境（如内网、IoT）中仍广泛使用。
笔者点评：Keep-Alive 确实救了一命，但"串行排队"这个设定简直反人类。管道化是不错，结果被请求顺序绑死，前一个卡壳全队列瘫痪，纯属花瓶功能。
四、HTTP/2
推出时间：2015 年 5 月
核心特点：
- 二进制帧化传输：替代 HTTP/1.x 的明文文本传输，解析更高效、错误率更低；
- 多路复用：同一 TCP 连接中支持多个并发请求 / 响应，解决 HTTP/1.x 的串行请求队头阻塞；
- HPACK 头压缩：对重复的请求头 / 响应头进行压缩，减少报文体积（HTTP/1.x 头为明文重复传输）；
- 服务端推送：服务器可预判客户端需要的静态资源（如 CSS/JS），提前推送给客户端，减少请求次数；
- 流优先级：可为不同请求设置优先级，服务器优先处理高优先级请求（如首屏资源）；
现状 ：目前最广泛部署的高性能 HTTP 版本，各大浏览器 / 服务器 / CDN 均全面支持。主流浏览器强制要求通过 HTTPS 使用（即 ALPN 协商），几乎所有现代 Web 服务默认启用。服务端推送因实现复杂且盲目推送反而浪费带宽，实际使用较少。
笔者点评：这版本才算把应用层性能优化玩明白了，多路复用+头压缩直接拉满上限。但尴尬的是，HTTP自己实现了拆帧和组装，把TCP的活给干了，TCP层队头阻塞反而成新瓶颈，既然这样，还要你TCP干啥，这个时候HTTP3已经呼之欲出了。
五、HTTP/3
推出时间：2022 年 6 月
核心特点：
- 基于 UDP + QUIC：抛弃 TCP，解决 TCP 层的队头阻塞（HTTP/2 的多路复用仍受 TCP 丢包阻塞影响）；
- 彻底的流级多路复用：每个 QUIC 流独立，一个流丢包仅重传该流，不影响其他流；
- 快速建连：首次建连 1RTT，二次建连 0RTT（融合 TCP 握手、TLS 握手、QUIC 建连）；
- 强制 TLS 1.3 加密：无明文传输，加密范围比 HTTP/2 更广（覆盖整个报文）；
- 连接迁移：基于连接 ID 标识连接，而非 TCP 的 IP + 端口，设备切换网络（WiFi→4G）时连接不中断；
- QPACK 头压缩：优化 HTTP/2 的 HPACK，解决头块阻塞问题。
现状：已在主流浏览器（Chrome、Firefox、Safari、Edge）和大型 CDN（Cloudflare、Fastly、AWS）中默认支持。服务端生态逐步成熟，但受限于 UDP 防火墙策略、运维工具链不完善等因素，尚未全面普及，属于"未来已来，但未全覆盖"的阶段。
笔者点评：终于甩掉 TCP 这个老古董，用 QUIC 自己搞一套更快、更稳、还能无缝切网的传输层------虽然实现和部署都有门槛，但互联网的大趋势，就是越来越复杂。
最后笔者总结
HTTP 版本一直在迭代，始终围绕两大核心：性能与安全。性能是用户能直接感知到的------如今复杂网页能实现"秒开"，HTTP各版本的优化功不可没，从复用连接到多路复用，每一步都在降低传输开销、提升响应速度。而安全性更多是开发者的责任边界，从明文传输到强制加密，协议不断筑牢网络传输的安全防线。
另一方面，HTTP 的迭代速度确实有点"温吞"。站在开发者角度，自己从零写个应用层协议，绝不会耗几十年才到HTTP/3。但现实是，它背负着整个互联网的存量------浏览器、服务器、CDN、中间件......谁都不能掉队。所以慢，不是不想快，而是不敢快。
不过对比TCP那种"千年不更"的老顽固，HTTP已经算快节奏了，毕竟稳定兼容才是基础协议的第一准则。