HTTP1诞生到完善

HTTP/1.0

HTTP/1.0多数据格式传输

HTTP/1.0在1996年发布。
通过在请求和响应报文增加头信息来描述传输数据的元信息，从而支持了任意格式的数据传输与处理。
客户端需要再HTTP请求头中指定可以处理的数据类型，同时服务端在响应请求时，会在响应头中指定传输的数据类型，例如图片、音频、视频等，以确保数据能够被正确解析和显示。

此外，为了节省带宽，服务端还可以将数据压缩后再传输，并将压缩方法放到响应头中，这样客户端就可以根据压缩方法解压数据。

HTTP/1.0多数据格式传输处理的基本流程

请求报文
第二行：可以接受服务器返回任意类型的文件
第三行：支持服务器采用gzip、deflate、br，其中任意一种压缩方式
第四行：期望返回的文件编码是UTF-8
第五行：期望优先语言是中文

响应报文
第二行：服务器采用了br压缩方式
第三行：服务端返回的是图片类型的文件
有了响应头信息，浏览器就会用br方法来解压文件，在按照图片格式来处理文件

HTTP/1.0缓存机制

每次客户端请求资源，服务器都会返回完整的响应，即使该资源已经被请求过并且没有发生变化。
这种方式会导致网络带宽的浪费，并且增加服务器的负载，因此HTTP/1.0加入缓存机制。
如果客户端已经缓存了需要请求的资源，它可以使用缓存版本而不必再次请求服务器。

涉及到缓存相关的头字段

Pragma: no-cache不使用缓存数据
Expires：资源过期时间
Last-Modified：资源最后修改时间
If-Modified-Since：验证资源是否过期

HTTP/1.0缓存策略流程

初次请求服务器会返回资源，同时会带上资源的过期时间和最后修改时间。
当下次请求时，通过比较本地时间和过期时间，判断缓存是否过期，未过期则读取并使用。
若检查发现资源已经过期，则带上修改时间重新请求服务器，服务器通过比较资源最后修改时间，判断资源是否变更。
若服务器发现资源变更，则返回新资源，未变更则返回状态码304，表示资源可以继续使用。

HTTP/1.0其余特性

HTTP/1.0还依据当时实际需求引入很多其他特性。
虚拟主机、状态码、服务代理、用户代理等等。

HTTP/1.1

由于HTTP/1.0版本没有充分考虑缓存控制、持久化连接的需求，于是在1997年发布HTTP/1.1版本

HTTP/1.1持久连接

如果在请求index.html的页面含有其他资源，比如style.css、jquery.js等。
每个资源都需要通过单独的HTTP请求来获取，这就需要频繁创建和销毁TCP连接，增加通信双方负载，同时也损耗传输性能。

HTTP/1.1引入了持久连接的机制，也称为HTTP keep-alive或者HTTP连接重用
在一个持久连接中，客户端发送一个请求，服务器响应后不会立即关闭连接，而是继续保持连接，等待客户端发送下一个请求。
这样客户端和服务器在同一个TCP连接上，可以传输多个请求和响应，避免频繁创建和销毁TCP连接，从而提高传输效率。

HTTP/1.1管道机制

尽管通过持久连接机制，可以重用TCP连接来提高传输性能。
但是在同一个TCP连接上，每个请求必须等到前一个请求的响应之后才能发送，这就会导致在页面中请求多个资源时传输效率低下。
为了解决这个问题HTTP/1.1引入管道机制
它允许客户端在同一个TCP连接上，同时发送多个请求，而无需等待前一个请求的响应，以此来充分利用等待响应过程中的时间。

但是因为HTTP是文本协议，请求和响应之间没有序号标识关联，服务器只能收到请求的顺序逐一处理，然后依次响应。
如果其中一个请求非常耗时，或者因为某些原因没有及时响应，后面其他请求就会被阻塞，存在队头阻塞的问题。
此外管道机制稳定性差，而且存在兼容性问题，现在浏览器默认都关闭管道化，大部分服务器默认不支持管道化。