这篇文章会从下面几个维度来对比 HTTP 1.0 和 HTTP 1.1 和 HTTP 2.0：

• 响应状态码
• 缓存处理
• 连接方式
• Host头处理
• 带宽优化

1. 响应状态码

Http1.1 与 Http1.0 相比，新加入了大量的状态码。

2. 缓存处理

Http1.0 中的缓存机制非常简单，服务端使用 Expires 标签来标识一个相应体，在 Expires 标志的时间内的所有请求，获得的都会是缓存。

服务端 初次返回给 客户端 的响应体中，会有一个 Last-Modified 标签，该标签标记了被请求资源在服务器端的最后一次修改的时间。

在请求头中使用 If-Modified-Since 标签来 器：“该时间之前，要请求的资源是否有被修改过?”。

通常情况下， If-Modified-Since 的值即为上一次获得该资源时，响应体中的 Last-Modified 的值。

服务器接收到请求头之后，会判断 If-Modified-Since 时间，如果资源没有被修改过，则返回给客户端一个 304 not modified 的相应头，表示 "缓存可用，你直接从本地里拿吧"。

HTTP/1.1的缓存机制在HTTP/1.0的基础上，大大增加了灵活性和扩展性。基本工作原理和HTTP/1.0保持不变，而是增加了更多细致的特性。

3. 连接方式

Http 1.0 默认使用的是短链接，即客户端和服务端的每一次通信操作，都会建立一个新的链接，任务结束后就会中断链接，这样就会导致有大量的 "握手报文" 和 "挥手报文" 占用带宽。但是可以主动采用在请求头部加上 Connection：keep-alive，来要求服务器不要关闭TCP连接，以便其他请求复用。但是这样也需要客户端手动关闭连接 Connection: close。

为了解决资源浪费问题，Http 1.1 优化为默认长链接模式。客户端采用长链接的模式，通过请求报文来通知服务端：“向你发起请求链接，并且链接成功建立后，请不要关闭”。在后续的CS通信中，该TCP链接就会一直处于打开状态。

TCP链接一直保持开启的话，对于服务器资源来说，也是一种资源浪费。因此像 Apache 这样的服务器软件，还会支持超时自动关闭 TCP 链接的设置。

注意：在 Http1.0 中也提供了长链接的选项，也就是需要在请求头中加入 Connection: Keep-alive ；同样的，在 Http1.1 中如果想关闭长链接，则可以在请求头中加入 Connection: close；

4. Host 头处理

域名系统 DNS 允许多个主机名，绑定到同一个域名上。但是在 Http1.0中并没有考虑这个问题。

假设我们有一个资源URL是 http://example1.org/home.html，HTTP/1.0的请求报文中，将会请求的是GET /home.html HTTP/1.0.也就是不会加入主机名。这样的报文送到服务器端，服务器是理解不了客户端想请求的真正网址。

因此，HTTP/1.1在请求头中加入了Host字段。加入Host字段的报文头部将会是:

GET /home.html HTTP/1.1
Host: example1.org

这样，服务器端就可以确定客户端想要请求的真正的网址了。

5. 带宽优化

5.1 范围请求

Http 1.1 引入了范围请求机制（range request），以避免带宽的浪费。当客户端想请求一个文件的一部分，或者需要继续下载一个已经下载了部分但被终止的文件，HTTP/1.1可以在请求中加入Range头部，以请求（注意：只能请求字节型数据）数据的一部分。服务器端则可以忽略Range头部，也可以返回若干Range响应。

在 Http 1.0 中，如果一个响应体中只是包含部分数据的话，那么将会返回 206 (Partial Content) 的状态码。

在范围响应体中， 头部标志 Content-Range 指示出了该数据块的偏移量和数据块的长度。

5.2 状态码 100

Http1.1 中新加入了状态码 100，当存在某些大文件的请求时，该状态码 100 表示服务器可能不愿意响应这类请求，因此需要客户端再次进行确认是否继续请求该类资源。然而在 Http 1.0 中，并没有 100 (Continue) 状态码。

 5.3. 压缩

许多格式的数据在传输时都会做预压缩处理。数据的压缩可以大幅优化带宽的利用。然而，HTTP/1.0对数据压缩的选项提供的不多。HTTP/1.1则对内容编码（content-codings）和传输编码（transfer-codings）做了区分。内容编码总是端到端的，传输编码总是逐跳的。

Http 1.1 的特点

• 加入了管道机制
  在同一个 TCP 连接里，允许多个请求同时发送，增加了并发性，进一步改善了 HTTP 协议的效率。
  举例来说，客户端需要请求两个资源。以前的做法是，在同一个 TCP 连接里面，先发送 A 请求，然后等待服务器做出回应，收到后再发出 B 请求。
  管道机制则是允许浏览器同时发出 A 请求和 B 请求，但是服务器还是按照顺序，先回应 A 请求，完成后再回应 B 请求。
  一个 TCP 连接现在可以传送多个回应，势必就要有一种机制，区分数据包是属于哪一个回应的。这就是 Content-length 字段的作用，声明本次回应的数据长度。
• 分块传输编码
  使用 Content-Length 字段的前提条件是，服务器发送回应之前，必须知道回应的数据长度。对于一些很耗时的动态操作来说，这意味着，服务器要等到所有操作完成，才能发送数据，显然这样的效率不高。
  更好的处理方法是，产生一块数据，就发送一块，采用"流模式"（stream）取代"缓存模式"（buffer）。
  因此，HTTP 1.1 版本规定可以不使用 Content-Length 字段，而使用"分块传输编码"（chunked transfer encoding）。只要请求或回应的头信息有 Transfer-Encoding 字段，就表明回应将由数量未定的数据块组成。
• 新增了请求方式 PUT、PATCH、OPTIONS、DELETE 等。
• 客户端请求的头信息新增了 Host 字段，用来指定服务器的域名。
• HTTP 1.1 支持文件断点续传，RANGE:bytes，HTTP 1.0 每次传送文件都是从文件头开始，即 0 字节处开始。RANGE:bytes=XXXX 表示要求服务器从文件 XXXX 字节处开始传送，断点续传。即返回码是 206（Partial Content）

Http2.0 的特点

• 二进制协议
  HTTP 1.1 版的头信息肯定是文本（ASCII 编码），数据体可以是文本，也可以是二进制。
  HTTP 2.0 则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为"帧"（frame）：头信息帧和数据帧。
• 多工
  HTTP 2.0 复用 TCP 连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应，这样就避免了"队头堵塞"（HTTP 2.0 使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比 HTTP 1.1大了好几个数量级）。
  举例来说，在一个 TCP 连接里面，服务器同时收到了 A 请求和 B 请求，于是先回应 A 请求，结果发现处理过程非常耗时，于是就发送 A 请求已经处理好的部分， 接着回应 B 请求，完成后，再发送 A 请求剩下的部分。
• 头信息压缩
  HTTP 协议不带有状态，每次请求都必须附上所有信息。所以，请求的很多字段都是重复的，比如 Cookie 和 User Agent，一模一样的内容，每次请求都必须附带，这会浪费很多带宽，也影响速度。
  HTTP 2.0 对这一点做了优化，引入了头信息压缩机制（header compression）。一方面，头信息使用 gzip 或c ompress 压缩后再发送；另一方面，客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。
• 服务器推送
  HTTP 2.0 允许服务器未经请求，主动向客户端发送资源，这叫做服务器推送（server push）。意思是说，当我们对支持 HTTP 2.0 的 web server 请求数据的时候，服务器会顺便把一些客户端需要的资源一起推送到客户端，免得客户端再次创建连接发送请求到服务器端获取。这种方式非常合适加载静态资源。 服务器端推送的这些资源其实存在客户端的某处地方，客户端直接从本地加载这些资源就可以了，不用走网络，速度自然是快很多的。