超文本传输协议（HTTP）是一个用于传输超媒体文档（例如 HTML）的应用层协议。它是为 Web 浏览器与 Web 服务器之间的通信而设计的，但也可以用于其他目的。HTTP 遵循经典的客户端—服务端模型，客户端打开一个连接以发出请求，然后等待直到收到服务器端响应。
查阅了各种资料，梳理了HTTP协议的发展历史中所经历的各个阶段，以及在各个阶段中解决了什么问题 / 遗留了什么问题。了解了这些之后，对我们再去学习http其他知识会有一个总体上的概览，形成一整个知识体系框架。

HTTP 0.9

这一时期的HTTP协议是仅仅用来在网络之间传递体积较小的HTML超文本的内容，所以被称为超文本传输协议。采用了基于请求响应的模式，从客户端发出请求，服务器返回数据。
整个流程如下图所示：

这一时期的HTTP有如下三个特定

1. 只有一个请求行，并没有 HTTP 请求头和请求体，因为只需要一个请求行就可以完整表达客户端的需求了
2. 服务器也没有返回头信息，这是因为服务器端并不需要告诉客户端太多信息，只需要返回数据就可以了
3. 返回的文件内容是以 ASCII 字符流来传输的，因为都是 HTML 格式的文件，所以使用 ASCII 字节码来传输是最合适的

HTTP1.0

主要解决的问题

不过随着互联网高速发展，最初的HTTP0.9已近不能满足新的需求了，比如请求的文件，不单单是简单的HTML文件，也包含JavaScript、CSS、图片、音频、视频等不同类型的文件。因此支持多种类型的文件下载是 HTTP/1.0 的一个核心诉求，而且文件格式不仅仅局限于 ASCII 编码，还有很多其他类型编码的文件。
于是在HTTP/1.0 引入了请求头和响应头，它们都是以为 Key-Value 形式保存的，在 HTTP 发送请求时，会带上请求头信息，服务器返回数据时，会返回响应头信息。整个流程如下如所示：

有了请求头和响应头，浏览器和服务器就能进行更加深入的交流了。
同时如果支持多种类型的文件，我们就需要解决以下几个问题：

1. 浏览器需要知道服务器返回的数据是什么类型的，然后浏览器根据不同的数据类型做针对性的处理
2. 由于万维网所支持的应用变得越来越广，所以单个文件的数据量也变得越来越大。为了减轻传输性能，服务器会对数据进行压缩后再传输，所以浏览器需要知道服务器压缩的方法
3. 由于万维网是支持全球范围的，所以需要提供国际化的支持，服务器需要对不同的地区提供不同的语言版本，这就需要浏览器告诉服务器它想要什么语言版本的页面

HTTP/1.0 的方案是通过请求头和响应头来进行协商，在发起请求时候会通过 HTTP 请求头告诉服务器它期待服务器返回什么类型的文件、采取什么形式的压缩、提供什么语言的文件以及文件的具体编码。比如我们以京东首页为例，看其中index.html的一个请求头如下：

服务器接收到浏览器发送过来的请求头信息之后，会根据请求头的信息来准备响应数据。比如我们看index.html也就是上述请求头对应的响应头的内容如下：

有了响应头的信息，浏览器就会使用 对应的压缩方法来解压文件，再按照 UTF-8 的编码格式来处理原始文件，最后按照 HTML 的方式来解析该文件。这就是 HTTP/1.0 支持多文件的一个基本的处理流程。

其他特性

HTTP/1.0 除了对多文件提供良好的支持外，还依据当时实际的需求引入了很多其他的特性，这些特性都是通过请求头和响应头来实现的。比如：

1. 状态码：有的请求服务器可能无法处理，或者处理出错，这时候就需要告诉浏览器服务器最终处理该请求的情况就是通过状态码来实现的
2. Cache 机制：用缓存已经下载过的数据，来缓解服务器的压力
3. 用户代理：便于服务器统计客户端的基础信息

关于这些特点，后续我们单独一篇文章系统性的介绍，这里就不在赘述了。

HTTP1.1

随着互联网的高速发展，发现HTTP1.0也不能满足需求了，于是多了一个缝缝补补的1.1版本。在HTTP1.1版本主要做了如下的更新：

改进持久连接

HTTP/1.0 每进行一次 HTTP 通信，都需要经历建立 TCP 连接、传输 HTTP 数据和断开 TCP 连接三个阶段。如下图所示：

在早期由于通信的文件比较小，而且每个页面的引用也不多，所以这种传输形式没什么大问题。但是随着浏览器普及发展，单个页面中的图片文件越来越多，有时候一个页面可能包含了几百个外部引用的资源文件，如果在下载每个文件的时候，都需要经历建立 TCP 连接、传输数据和断开连接这样的步骤，无疑会增加大量无谓的开销
为了解决这个问题，HTTP/1.1 中增加了持久连接的方法，它的特点是在一个 TCP 连接上可以传输多个 HTTP 请求，只要浏览器或者服务器没有明确断开连接，那么该 TCP 连接会一直保持。如下图所示：

持久连接在 HTTP/1.1 中是默认开启的，所以你不需要专门为了持久连接去 HTTP 请求头设置信息，如果你不想要采用持久连接，可以在 HTTP 请求头中加上Connection: close。目前浏览器中对于同一个域名，默认允许同时建立 6 个 TCP 持久连接。通过持久连接就可以减少 TCP 的建立和断开次数

每个域名最多同时维护 6 个 TCP 持久连接

浏览器为每个域名最多同时维护6个TCP链接再加上【域名分片】(将内容拆分到多个子域中。当使用多个域来处理多个资源时，浏览器能够同时下载更多资源，从而缩短了页面加载时间并改善了用户体验)技术，就可以大大提高了页面的下载速度。如下图所示:

支持动态生成的内容

在设计 HTTP/1.0 时，需要在响应头中设置完整的数据大小，如Content-Length: 520，这样浏览器就可以根据设置的数据大小来接收数据。不过随着服务器端的技术发展，很多页面的内容都是动态生成的，因此在传输数据之前并不知道最终的数据大小，这就导致了浏览器不知道何时会接收完所有的文件数据。HTTP/1.1 通过引入 Chunk transfer 机制来解决这个问题，服务器会将数据分割成若干个任意大小的数据块，每个数据块发送时会附上上个数据块的长度，最后使用一个零长度的块作为发送数据完成的标志。这样就提供了对动态内容的支持

提供虚拟主机的支持

在 HTTP/1.0 中，每个域名绑定了一个唯一的 IP 地址，因此一个服务器只能支持一个域名。但是随着虚拟主机技术的发展，需要实现在一台物理主机上绑定多个虚拟主机，每个虚拟主机都有自己的单独的域名，这些单独的域名都公用同一个 IP 地址。因此，HTTP/1.1 的请求头中增加了 Host 字段，用来表示当前的域名地址，这样服务器就可以根据不同的 Host 值做不同的处理。

HTTP1.X遗留的问题

队头阻塞

上面提到的持久连接虽然能减少 TCP 的建立和断开次数，但是它需要等待前面的请求返回之后，才能进行下一次请求。如果 TCP 通道中的某个请求因为某些原因没有及时返回，那么就会阻塞后面的所有请求，这就是著名的队头阻塞的问题。
比如在HTTP1.1中，浏览器在每个域名中最多同时建立6个TCP，每个TCP可以同时处理一个请求，如果此时网页比较复杂，有几十个的话，那同一时间只能处理6个请求，其余的就需要等前面的请求处理完成之后再一个个处理下面的请求。如果此时前面的某个请求因为服务器处理的业务过于复杂没有及时返回的话，后面的请求也就被阻塞了。

在HTTP/1.1 中试图通过管线化的技术来解决队头阻塞的问题。HTTP/1.1 中的管线化是指将多个 HTTP 请求整批提交给服务器的技术，虽然可以整批发送请求，不过服务器依然需要根据请求顺序来回复浏览器的请求。
FireFox、Chrome 都做过管线化的试验，但是由于各种原因，它们最终都放弃了管线化技术。

TCP慢启动

一旦一个 TCP 连接建立之后，就进入了发送数据状态，刚开始 TCP 协议会采用一个非常慢的速度去发送数据，然后慢慢加快发送数据的速度，直到发送数据的速度达到一个理想状态，这个过程称为慢启动。
就好像开车一样，我们开车从0加速到理想的车速需要一个过程。慢启动是 TCP 为了减少网络拥塞的一种策略，是没有办法改变的。

多个TCP竞争带宽

假如系统同时建立了多条 TCP 连接，当带宽充足时，每条连接发送或者接收速度会慢慢向上增加；而一旦带宽不足时，这些 TCP 连接又会减慢发送或者接收的速度。比如一个页面有 100 个文件，使用了 5 个 CDN，那么加载该网页的时候就需要建立 6 * 5，也就是 30个 TCP 连接来下载资源；在下载过程中，当发现带宽不足的时候，各个 TCP 连接就需要动态减慢接收数据的速度了。
这样就会出现一个问题，因为有的 TCP 连接下载的是一些关键资源，如 CSS 文件、JavaScript 文件等，而有的 TCP 连接下载的是图片、视频等普通的资源文件，但是多条 TCP 连接之间又不能协商让哪些关键资源优先下载，这样就有可能影响那些关键资源的下载速度了。

其中队头阻塞是由于 HTTP/1.1 的机制导致的，而慢启动和 TCP 连接之间相互竞争带宽是由于 TCP 本身的机制导致的

最后

HTTP从最初的0.9版本到1.0再到1.1。每一个版本的出现都是为了解决当下面临的问题，现在HTTP1.X已近完成了他的历史使命，随着互联网的高速发展又有新的挑战需要面对，这就交给后面的H2 & H3了