HTTP 0.9 

特点：

1. 只有一个请求行；
2. 服务器仅返回数据，没有响应头。

瓶颈：

1. 仅支持HTML，无法传输其他类型文件；
2. 文件编码格式过少，仅局限于ASCII。

HTTP 1.0

特点：

1. 引入请求头和响应头（数据类型、语言版本、编码类型、用户代理）；
2. 数据压缩；
3. 引入状态码；
4. 提供了Cache缓存机制（head里的缓存头：If-Modified-since、Expires）。

瓶颈：

1. 仅支持短连接，对于包含多个请求的文件，会大大增加开销；
2. 串行文件传输，一个请求没有及时返回，会引起队头阻塞；
3. 一个服务器仅支持一个域名；
4. 因为在响应头中需要指定数据大小，因此无法接收动态生成的数据；
5. 服务器只能传递完整的数据，而不能满足“只想要数据的一部分”这样的需求，会导致带宽浪费；
6. 不支持断点续传。
7. 每次数据传输，在TCP建立连接时，三次握手都会有1.5个RTT（round-trip time）的延迟。

RTT为数据完全发送完（完成最后一个比特推送到数据链路上）到收到确认信号的时间。不包括数据发射（即将数据推送到数据链路上）的时间。

​​​​​​​

• t1为发送第一个比特的时刻
• t2为发完最后一个比特的时刻
• t3为接收到确认信号的时刻

图中明确指出：RTT = t3 - t2

HTTP 1.1

特点：

1. 支持持久连接，一次连接可以发送多个请求和响应（最多6个）；【HTTP 1.1 基于串行文件传输数据，因此这些请求必须是有序的，所以实际上我们只是节省了建立连接的时间，而获取数据的时间并没有减少。最大并发数问题，假设我们在 apache 中设置了最大并发数 300，而因为浏览器本身的限制，最大请求数为 6，那么服务器能承载的最高并发数是 50。】
2. 引入虚拟主机技术，让一个服务器可以支持多个域名；
3. 通过引入分块传输编码机制，支持动态内容；
4. 引入Cookie与安全机制；
5. 引入range头域，可以只请求资源的一部分（状态码206）；
6. 优化缓存策略（在head中，增加Etag、If-Unmodified-Since、If-Match、If-None-Match等缓存头）；
7. 增加错误状态码。

瓶颈：

1. TCP慢启动导致小文件建立连接过慢；
2. 资源下载机制不完善，无法实现资源下载时的优先级调整；
3. 一个TCP连接只能处理一个请求，请求头易阻塞。

SPDY

特点：

1. 多路复用，降低延迟。HTTP2.0的多路复用即是基于此；
2. 增加请求优先级，给request增加优先级，就可以让重要的请求有限得到响应；
3. header压缩，借助通用的DEFLATE 算法来减小包的大小和数量；
4. 基于HTTPS；
5. 服务器推送，在建立连接后，服务器可以主动向客户端发送数据。

SPDY 位于 HTTP 之下，TCP 和 SSL 之上，这样可以轻松兼容老版本的 HTTP 协议(将HTTP1.x 的内容封装成一种新的 frame 格式)，同时可以使用已有的 SSL 功能。

HTTP 2.0

特点：

1. 引入二进制分帧层，将数据拆解成多个二进制编码的帧；【HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。】
2. 使用多路复用技术，一个连接可以发送多个请求；【HTTP/2 对同一域名下所有请求都是基于流，也就是说同一域名不管访问多少文件，也只建立一路连接。同样Apache的最大连接数为300，因为有了这个新特性，最大的并发就可以提升到300，比原来提升了6倍。一个request对应一个id，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。】
3. 可以设置请求优先级；
4. 服务器推送，一个请求是由我们的主页发起的，服务器很可能会响应主页内容、LOGo 以及样式表，因为它知道客户端会用到这些东西；
5. 借助专门为首部压缩设计的HPACK 算法进行首部压缩。

瓶颈：

1. 单个数据包丢失会导致TCP上的队头阻塞；
2. 握手产生的延时。

HTTP2.0可以说是 SPDY 的升级版（其实原本也是基于 SPDY 设计的），但是，HTTP 2.0 跟 SPDY 仍有不同的地方

1. HTTP 2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS

2. HTTP 2.0 消息头的压缩算法采用 HPACK ，而 SPDY 采用的 DEFLATE 

HTTP 3.0 

特点：

1. 基于UDP
2. 实现了多路复用；
3. 实现了流量控制、可靠传输；
4. 实现了快速握手。

瓶颈：

1. 兼容性尚不完整；
2. 优化程度不高。

为什么需要头部压缩？ 假定一个页面有100个资源需要加载（这个数量对于今天的Web而言还是挺保守的）, 而每一次请求都有1kb的消息头（这同样也并不少见，因为Cookie和引用等东西的存在）, 则至少需要多消耗100kb来获取这些消息头。HTTP2.0可以维护一个字典，差量更新HTTP头部，大大降低因头部传输产生的流量。具体参考：HTTP/2 头部压缩技术介绍

HTTP2.0多路复用有多好？ HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP 连接会随着时间进行自我「调谐」，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。 HTTP/2 通过让所有数据流共用同一个连接，可以更有效地使用 TCP 连接，让高带宽也能真正的服务于 HTTP 的性能提升。

参考文章：

6张图从HTTP/0.9进化到HTTP3.0

HTTP1.0、HTTP1.1 和 HTTP2.0 的区别

HTTP/2 多路复用技术分享