HTTP当时出现于1990年， HTTP 此时尚未建立正式标准 HTTP 含有 HTTP/1.0 之前版本的意思。主要用于学术交流，需求非常简单——在网络之间传递 HTML 超文本的内容被称为超文本传输协议。整体来看，它的实现也很简单，采用了基于请求响应的模式，从客户端发出请求，服务器返回数据。

一般来说，当时的需求非常简单，用于传输体积小的需求 HTML 文件，所以 HTTP/0.9 实现具有以下三个特点。

• 第一个是只有一个请求行，没有 HTTP 请求头和请求体，因为客户端的需求只需要一个请求行。
• 二是服务器没有返回头部信息，因为服务器端不需要告诉客户端太多信息，只需返回数据即可。
• 第三个是返回文件的内容 ASCII 字符流传输，因为它们都是 HTML 所以使用格式文件， ASCII 传输字节码是最合适的

万维网的快速发展带来了许多新的需求， HTTP/0.9 新兴网络的发展不再适用，因此需要新的协议来支持新兴网络，这就是 HTTP/1.0 出生的原因。

但在详细分析中 HTTP/1.0 先分析一下新兴网络带来的新需求。浏览器中显示的第一件事不仅仅是 HTML 包括文件 JavaScript、CSS、不同类型的文件，如图片、音频、视频等。因此，支持各种类型的文件下载 HTTP/1.0 核心诉求，文件格式不限于 ASCII 其他类型的编码文件也很多。

HTTP/0.9 建立连接后，只会发送类似的连接GET /index.html简单的请求命令没有其他方式告诉服务器更多信息，如文件编码、文件类型等。同样，服务器直接将数据返回到浏览器，也没有其他方式告诉浏览器更多关于服务器返回的文件。
为了使客户端与服务器进行更深入的沟通，HTTP/1.0 引入请求头和响应头，他们都认为 Key-Value 形式保存，在 HTTP 发送请求时，会带上请求头信息，服务器返回数据时，会先返回响应头信息。

• 首先，浏览器需要知道服务器返回的数据类型，然后浏览器可以根据不同的数据类型进行有针对性的处理。
• 其次，由于万维网络支持的应用越来越广泛，单个文件的数据量也越来越大。为了降低传输性能，服务器在传输前压缩数据，浏览器需要知道服务器压缩的方法。
• 第三，由于万维网络支持全球，需要国际支持，服务器需要为不同地区提供不同的语言版本，这需要浏览器告诉服务器它想要什么语言版本的页面。
• 最后，由于添加了不同类型的文件，每个文件的编码形式可能不同。为了准确地读取文件，浏览器需要知道文件的编码类型。

基于上述问题，HTTP/1.0 方案是通过请求头和响应头协商，在发起请求时会通过 HTTP 请求头告诉服务器它期望服务器返回什么类型的文件，压缩什么形式，提供什么语言文件和文件的具体代码。

accept: text/html  // 期待服务器返回 html 类型的文件 accept-encoding: gzip, deflate, br  // 可采用预期服务器 gzip、deflate 或者 br 压缩方法之一 accept-Charset: ISO-8859-1,utf-8  // 期望返回的文件编码是 UTF-8 或者 ISO-8859-1 accept-language: zh-CN,zh  // 期望页面的优先语言是中文 

接收到浏览器发送的请求头信息后，服务器将根据请求头信息准备响应数据。然而，有时会发生一些事故。例如，浏览器要求的压缩类型是 gzip，但服务器不支持 gzip，只支持 br 压缩，然后通过响应头部 content-encoding 字段告诉浏览器最终压缩类型，即最终浏览器需要根据响应头的信息处理数据。以下是响应头的数据信息：

 content-encoding: br  // 说明服务器已经采用了 br 的压缩方法 content-type: text/html; charset=UTF-8 // 表示服务器返回 html 该文件的编码类型 UTF-8 

HTTP/1.0 除了对多个文件提供良好的支持外，还根据当时的实际需要引入了许多其他特征，通过请求头和响应头实现。让我们来看看一些新的典型特征：

HTTP/1.0 每进行一次 HTTP 通信需要建立 TCP 连接、传输 HTTP 数据和断开 TCP 连接三个阶段。
当时，由于通信文件相对较小，每个页面的参考也不多，这种传输形式没有大问题。然而，随着浏览器的普及，单个页面中的图片文件越来越多。有时一个页面可能包含数百个外部参考资源文件。如果您下载每个文件，您需要建立它 TCP 连接、传输数据和断开连接的步骤无疑会增加大量不必要的费用。

要解决这个问题，HTTP/1.1 增加了持久连接的方法，其特点是一种 TCP 多个可以在连接上传输 HTTP 请求，只要浏览器或服务器没有明确断开连接，就应该 TCP 保持连接。
持久连接在 HTTP/1.1 中是默认开启的，所以你不需要专门为了持久连接去 HTTP 如果您不想使用持久连接，请求头可以设置信息 HTTP 请在头中加入Connection: close。默认允许浏览器中同一域名同时建立 6 个 TCP 持久连接。

虽然可以减少持久连接 TCP 建立和断开数，但是它需要等待前面的请求返回之后，才能进行下一次请求。如果 TCP 通道中的某个请求因为某些原因没有及时返回，那么就会阻塞后面的所有请求，这就是著名的队头阻塞的问题。
HTTP/1.1 中试图通过管线化的技术来解决队头阻塞的问题。HTTP/1.1 中的管线化是指将多个 HTTP 请求整批提交给服务器的技术，虽然可以整批发送请求，不过服务器依然需要根据请求顺序来回复浏览器的请求。

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

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