HTTP协议发展史

最近在搞WebSocket、QUIC等协议，发现都和HTTP协议有关，遂整理一篇。

1、概述

HTTP至今已经5个版本了，详细信息如下表所示。

版本	正式发布年份	最新RFC文档
HTTP 0.9	1991	无正式文档
HTTP 1.0	1996	RFC 1945
HTTP 1.1	1997	RFC 7230–7235
HTTP 2.0	2015	RFC 9113
HTTP 3.0	2022	RFC 9114

不同HTTP版本占比可见Cloudflare调研文档。

2、HTTP 0.9

这是最早的HTTP版本，只提供了简单的GET方法，请求纯文本，且只有请求行（Request-Line），无请求头（Header），请求体（Message-Body）。如

GET /index.html

响应也没有状态行（Status-Line），响应头（Header），只有响应体（Message-Body），如

<html><body>Hello World</body></html>

3、HTTP 1.0

相较于HTTP 0.9，该版本的HTTP添加了请求头，请求体，状态行，响应头。且添加了POST、HEAD等方法。
请求示例如下：

#请求行
GET /index.html HTTP/1.0
#请求头
Host: www.example.com
User-Agent: MyBrowser/1.0
Accept: text/html

#请求体
#一般在POST方法中存在。

响应示例如下：

#状态行
HTTP/1.0 200 OK
#响应头
Date: Tue, 28 Oct 2025 10:00:00 GMT
Server: ExampleServer/1.0
Content-Type: text/html
Content-Length: 44
Connection: close

#响应体
<html>
  <body>Hello World</body>
</html>

4、HTTP 1.1

HTTP 1.1 是在1.0的基础上增加了连接复用、请求方法、缓存控制等内容。
在1.0版本时，客户端请求并受到服务端响应后，会断开TCP连接。而1.1版本添加了Connection请求头，默认为keep-alive，即会复用TCP连接，直到超时或关闭连接。一个网站最多会同时建立6个TCP连接，当然这是浏览器决定的。这也是常说的短连接（Short-lived Connection）和长连接（Persistent Connection）[1]。具体差异如下图所示。

这里的流水线（Pipelining）传输方式最终并没有流行开来，而是被HTTP 2.0中的多路复用（Multiplexing）所替代，因为Pipelining还是串行传输，前者会影响后者，而多路复用则是任意顺序传输，且前者的使用受多种因素影响，如请求方法等。

这里能明显看到，HTTP 1.1存在应用层的队头阻塞（Head-of-line blocking），即前一个HTTP Response没到达，客户端是不会发送下一个Request的。

此外，知名的WebSocket协议就是在HTTP 1.1的基础上扩展而来的。

5、HTTP 2.0

HTTP 2.0在1.1的基础上，在保持HTTP语义不变的前提下，通过二进制分帧、多路复用、头部压缩和服务器推送，大幅提升性能和传输效率，直观展示请看[2]。Burpsuite也支持抓HTTP 2.0的包，现浏览器也大多支持了HTTP 2.0，具体也体现在JA4指纹中。

HTTP 2.0与1.1的流水线传输方式类似，只不过其是乱序传输的，例如在HTTP 1.1中，客户端发送1.png, 2.png, 3.png三个图片的Request，其是顺序进行的，当然，浏览器可以开3个TCP连接，分别请求这3个图片，从应用层整体来看，也勉强能称得上乱序，但在单个TCP连接中，依旧是顺序的，且这个并行乱序是浏览器带来的，不是协议本身的特性。而HTTP 2.0中，其只建立1个TCP连接，3个图片的request被封装成多个Frame，每个Frame平等，随意混合，不存在文件先后顺序。每个文件都看作一个Stream，Stream由多个Frame组成，最后服务端通过Frame上带的Stream ID重组收到的Frame，最终获取完整Request，随后返回Response过程同理。具体关系如下图：

由此，能看到HTTP 2.0解决了应用层上的队头堵塞，但传输层，也就是TCP层仍然存在队头阻塞，即TCP连接中，前一个字节没到达，就会阻塞后一个字节的传输。

虽然在HTTP 2.0中，支持了服务器推送（Server Push），但其本质语义上还是request-response的形式，只不过当客户端请求index.html时，服务端能够顺带将相关的css和js文件一同推送给客户端，但由于一些兼容性问题，主流浏览器已经不再支持，基本处于弃用状态。而HTTP 1.1中的WebSocket协议，真正实现了应用层上的全双工通信，即使客户端不发送任何消息，服务端也能主动给客户端发送消息。

此外，APNs和FCM等消息推送（Push Notification）协议，开发者与推送服务器的通信协议，也都从HTTP 1.1迁移到了HTTP 2.0，但推送服务器与设备之间的通信均为私有协议，其通信流程图如下。

6、HTTP 3.0

HTTP 3.0是由QUIC协议催生的，因为QUIC协议是一个四不像的协议，属于传输层和应用层各占一部分，对标的是更好的TCP，于是也就不能适用于HTTP 2.0，所以才推出了HTTP 3.0，详见RFC 8999-9002，其网络层次如下图。

HTTP 3.0有着0/1 RTT快速连接，默认启用TLS 1.3加密等特点，目前主流浏览器均已支持HTTP 3.0，可在该网站进行测试（建议取消代理，清除浏览器缓存或无痕模式下测试），但是如今主流的抓包均不支持HTTP 3.0，此外大多数代理工具也会选择禁用QUIC提速（大多数会直接禁用UDP的443端口）。有关HTTP版本使用情况，请见CloudFlare的调研报告[3]。

HTTP 3.0同HTTP 2.0一样，都是将文件看作Stream然后分成Frame传输，但HTTP 3.0彻底解决了队头阻塞问题，传输层由TCP变为UDP。具体差异如下表。

版本	传输方式	乱序传输	队头阻塞	连接个数
HTTP 1.1	串行	不支持	应用层堵塞	6
HTTP 2.0	多路复用	支持	传输层堵塞	1
HTTP 3.0	多路复用	支持	无堵塞	1

References

[1] https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Guides/Connection_management_in_HTTP_1.x
[2] https://www.tunetheweb.com/performance-test-360/
[3] https://blog.cloudflare.com/zh-cn/http3-usage-one-year-on/