HTTP的前世今生

这篇文章我们来聊一下 HTTP的前世今生，也就是 HTTP的发展历程。通过整个发展过程来分析不同版本的优缺点，希望能给到大家在优化方面的一些启发。

HTTP/0.9

在 20 世纪 90 年代初期的时候互联网还是很简陋的，当时的硬件条件相比与现在来说很差，比如说：计算机 CPU的计算能力很差，存储容量有限，网速也很慢。当时网络上的大多数资源都是纯文本形式的，很多通信协议都使用纯文本，HTTP初期的设计也是受到了这方面的影响。

这一期的 HTTP协议被定义为 0.9版。受限于当时的硬件条件以及当时的应用场景，这个版本的 HTTP协议结构比较简单。它采用了纯文本的格式，并且只支持 GET方法，在响应请求返回之后立即关闭。HTTP这一时期的功能非常有限，不过正是因为它的“简单”，蕴含了进化和扩展的的可能性。

HTTP/1.0

随着计算机多媒体技术的发展，例如 JEPG图像格式、MP3音频格式的推出，用户们对这些新技术拥有极大的热情，从用户需求角度促进了 HTTP的发展。HTTP/1.0在 1996 年正式发布。

HTTP/1.0主要添加了下面几个特性：

• 增加了 HEAD、POST等新方法。
• 增加了响应状态码来标识。
• 增加了协议版本号的概念。
• 引入了 HTTP HEAD 也就是请求头的概念。
• 传输的数据不再局限于文本。

但是 HTTP/1.0并不是一个标准，只是记录已有实践和模式的一份参考文档，不具有实际的约束力，相当于一个“备忘录”。

随着用户量以及 WEB应用的发展，HTTP/1.0存在以下几个缺点：

• 默认为短连接，连接无法复用，网页的每个资源请求都会发起新的 TCP连接。
• 队列头部请求阻塞 (head of line blocking), 一个 HTTP 请求响应结束之后，才能发起下一个 HTTP 请求。
• 不支持范围数据请求，即使只是需要某个资源的一部分内容 ，也会将整个资源发送过来。

HTTP/1.1

1995 年，网景的 Netscape Navigator 和微软的 Internet Explorer 开始了著名的“浏览器大战”，都希望在互联网上占据主导地位。最终微软的 IE 取得了决定性的胜利。“浏览器大战”大地推动了 Web 的发展，HTTP/1.0 也在这个过程中经受了实践检验。于是在“浏览器大战”结束之后的 1999 年，HTTP/1.1 发布了 RFC 文档，编号为 2616。大地推动了9 年，HTTP/1.1 发布了 RFC 文档，编号为 2616

HTTP/1.1主要变更点有下面几个：

• 增加了 PUT、DELETE等新方法。
• 增加了缓存管理和控制。
• 明确了连接管理，允许长连接。
• 允许响应分块（chunked），方便大文件传输。
• 强制要求 Host头。

当然随着HTTP/1.1的各种实践，也发现了它拥有很多不足之处：

• 虽然 TCP 连接可以复用，但是服务端响应只能按照客户端请求顺序返回，队列头部请求阻塞并没有完全解决。
• 客户端需要使用多个连接才能实现并发和缩短延迟。
• 无法压缩请求和响应头部，导致不必要的数据传输流量。
• 不支持有效的资源优先级，导致 TCP 连接的利用率低。

HTTP/2

HTTP/1.1发布之后，互联网世界迎来了爆发式的增长。同时HTTP/1.1的缺点也逐渐暴露出来，主要就是连接慢。但是HTTP/1.1标准一直不变，人们只能用一些“奇技淫巧”来缓解这些问题，比如之前常见的切图等网页优化手段。

Google 首先开发了自己的浏览器 Chrome，然后推出了新的 SPDY 协议，并在 Chrome 里应用于自家的服务器。由于 Chrome 在全球的用户占有率超过了 60%，顺势把 SPDY协议推上了 HTTP/2标准的宝座，颇有“挟天子以令诸侯”的意味。互联网标准化组织以 SPDY为基础开始制定新版本的 HTTP协议，最终在 2015 年发布了 HTTP/2。

HTTP/2的设计充分考虑到现在互联网的现状：带宽、移动、不安全，在高度兼容 HTTP/1.1的同时在性能上做了很大的改善。主要有下面几个方面：

• 二进制协议，不再是纯文本。
• 可以发起多个请求。
• 使用专用的算法来压缩头部，减少数据量的传输。
• 允许服务器主动向客户端推送数据。
• 增强了安全性，要求加密通信。

HTTP/2 针对基于 TCP 协议栈的 HTTP 优化，几乎上已经达到了最大化，如果需要继续深入优化，只能从协议栈本身的架构做调整。HTTP/2的优化问题主要是 TCP协议的问题：

• TCP 建立连接时的三次握手，增加了请求延时。
• TCP 内部的拥塞控制、慢启动、拥塞避免等机制，可能导致传输效率不足。
• HTTP/2 虽然解决了 HTTP/1 协议中的队列头部请求阻塞，但是无法解决 TCP协议的队头阻塞问题。
• 还有一个方面，现在移动终端上网的需求大大增加，例如当用户手机的IP 发生变更时就需要建立新的连接。

HTTP/3

在 HTTP/2 还处于草案之时，Google 又发明了一个新的协议，叫做 QUIC，起初还是在 Chrome 和自家服务器里试验，依托它的庞大用户量和数据量，持续地推动 QUIC 协议成为互联网上的“既成事实”。

QUIC 丢掉了 TCP 的包袱，基于 UDP，实现了一个安全高效可靠的 HTTP 通信协议。凭借着 0-RTT 建立连接、传输层多路复用、连接迁移、改进的拥塞控制、流量控制等特性，QUIC 在绝大多数场景下获得了比 HTTP/2 更好的效果。

HTTP/3 于 2022 年 6 月 6 日正式发布，IETF 把 HTTP/3 标准制定在了 RFC 9114 中，HTTP/3 其实相较于 HTTP/2 要比 HTTP/2 相较于 HTTP/1.1 的变化来说小很多，最大的提升就在于效率，替换 TCP 协议为 UDP 协议，HTTP/3 具有更低的延迟，它的效率甚至要比 HTTP/1.1 快 3 倍以上。