Http 协议版本进化

HTTP/0.9 - 单行协议

最初版本的HTTP协议并没有版本号，后来它的版本号被定位在0.9以区分后来的版本。HTTP/0.9极其简单：请求由单行指令构成，以唯一可用方法GET开头，其后跟目标资源的路径（一旦连接到服务器，协议、服务器、端口号这些都不是必须的）。跟后来的版本不同，HTTP/0.9的响应内容并不包含HTTP头，这意味着只有 HTML 文件可以传送，无法传送其他类型的文件；也没有状态码或者错误代码；一旦出现问题，一个特殊的包含问题描述信息的HTML文件将被发回，供人们查看。

HTTP/1.0 - 构建可扩展性

由于 HTTP/0.9协议的应用十分有限，浏览器和服务器迅速扩展内容使其用途更广：

协议版本信息现在会随着每个请求发送（HTTP/1.0被追加到了 GET行）

状态码会在响应开始时发送，使浏览器能了解请求执行成功或失败，并响应调整行为（如更新或使用本地缓存）

引入了 HTTP 头的概念，无论是对于请求还是响应，允许传输元数据，使协议变得非常灵活，更具扩展性。

在新 HTTP 头的的帮助下，具备了传输纯文本HTML文件以外其他类型文档的能力（凭借Content-Type头）

一个典型的请求看起来就像这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
一个包含图片的页面
  <IMG SRC="/myimage.gif">
</HTML>

接下来是第二个请求：

1
2
3
4
5
6
7
8


GET /myimage.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(这里是图片内容)

在 1991-1995年，这些新扩展并没有被引入到标准中以促进下注工作，而仅仅作为一种尝试：服务器和浏览器天界这些新扩展功能，但出现了大量的互操作问题。知道 1996年11月，为了解决这些问题，一份新文档（RFC 1945）被发表出来，泳衣描述如何操作实践这些新扩展功能，文档 RFC 1945 定义了 HTTP/1.0，但它是狭义的，并不是官方标准

HTTP/1.1 - 标准化的协议

HTTP/1.0 多种不同的实现方式在实际运用中显得有些混乱，自 1995 年开始，即 HTTP/1.0 文档发布的下一年，就开始修订 HTTP 的第一个标准化版本。在 1997 年初，HTTP1.1 标准发布，就在 HTTP/1.0 发布的几个月后。

HTTP/1.1 消除了大量歧义内容并引入了多项改进：

连接可以复用，节省了多次打开 TCP 连接加载网页文档资源的时间。

增加管线化技术，允许在第一个应答被完全发送之前就发送第二个请求，以降低通信延迟。

支持响应分块。

引入额外的缓存控制机制。

引入内容协商机制，包括语言，编码，类型等，并允许客户端和服务器之间约定以最合适的内容进行交换。

凭借Host头，能够使不同域名配置在同一个 IP 地址的服务器上。

一个典型的请求流程，所有请求都通过一个连接实现，看起来就像这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


GET /en-US/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

(content)

HTTP/1.1 在 1997 年 1 月以 RFC 2068 文件发布。

HTTP 用于安全传输

HTTP 最大的变化发生在 1994 年底。HTTP 在基本的 TCP/IP 协议栈上发送信息，网景公司（Netscape Communication）在此基础上创建了一个额外的加密传输层：SSL 。SSL 1.0 没有在公司以外发布过，但 SSL 2.0 及其后继者 SSL 3.0 和 SSL 3.1 允许通过加密来保证服务器和客户端之间交换消息的真实性，来创建电子商务网站。SSL 在标准化道路上最终成为 TLS，随着版本 1.0, 1.1, 1.2 的出现成功地关闭漏洞。TLS 1.3 目前正在形成。

与此同时，人们对一个加密传输层的需求也愈发高涨：因为 Web 最早几乎是一个学术网络，相对信任度很高，但如今不得不面对一个险恶的丛林：广告客户、随机的个人或者犯罪分子争相劫取个人信息，将信息占为己有，甚至改动将要被传输的数据。随着通过 HTTP 构建的应用程序变得越来越强大，可以访问越来越多的私人信息，如地址簿，电子邮件或用户的地理位置，即使在电子商务使用之外，对 TLS 的需求也变得普遍。

HTTP 用于复杂应用

Tim Berners-Lee 对于 Web 的最初设想不是一个只读媒体。他设想一个 Web 是可以远程添加或移动文档，是一种分布式文件系统。大约 1996 年，HTTP 被扩展到允许创作，并且创建了一个名为 WebDAV 的标准。它进一步扩展了某些特定的应用程序，如 CardDAV 用来处理地址簿条目，CalDAV 用来处理日历。但所有这些 *DAV 扩展有一个缺陷：它们必须由要使用的服务器来实现，这是非常复杂的。并且他们在网络领域的使用必须保密。

在 2000 年，一种新的使用 HTTP 的模式被设计出来：representational state transfer (或者说 REST)。由 API 发起的操作不再通过新的 HTTP 方法传达，而只能通过使用基本的 HTTP / 1.1 方法访问特定的 URI。这允许任何 Web 应用程序通过提供 API 以允许查看和修改其数据，而无需更新浏览器或服务器：所有需要的内容都被嵌入到由网站通过标准 HTTP/1.1 提供的文件中。 REST 模型的缺点在于每个网站都定义了自己的非标准 RESTful API，并对其进行了全面的控制；不同于 *DAV 扩展，客户端和服务器是可互操作的。 RESTful API 在 2010 年变得非常流行。

自2005年以来，可用于 Web 页面的API大大增加，其中几个API为特定目的扩展了HTTP协议，大部分是新的特定HTTP头：

Server-sent events 服务器可以偶尔推送消息到浏览器
Websocket 一个新协议，可以通过升级现有 HTTP 协议来建立

放松安全措施-基于当前的web模型

HTTP 和 Web安全模型 – 同源策略是互不相关的。事实上，当前的Web安全模型是在HTTP被创造出来后才被发展的！这些年来，已经在证实了它如果能通过在特定的约束下移除一些这个策略的限制来管的宽松些的话，将会更有用。这些策略导致大量的成本和时间被话费在通过转交到服务端来添加一些新的HTTP头来发送。这些被定义在了 Cross-Origin Resource Sharing(CORS) or the Content Security Policy(CSP)规范里。

不只是这大量的扩展，很多的其他的头也被加了进来，有些只是实验性的，比较著名的有 Do Not Track(DNT)来控制隐私， X-Frame-Option，还有很多

HTTP/2 - 为了更优异的表现

这些年来，网页愈渐变得的复杂，甚至演变成了独有的应用，可见媒体的播放量，增进交互的脚本大小也增加了许多：更多的数据通过 HTTP 请求被传输。HTTP/1.1 链接需要请求以正确的顺序发送，理论上可以用一些并行的链接（尤其是 5 到 8 个），带来的成本和复杂性堪忧。比如，HTTP 管线化（pipelining）就成为了 Web 开发的负担。

在 2010 年到 2015 年，谷歌通过实践了一个实验性的 SPDY 协议，证明了一个在客户端和服务器端交换数据的另类方式。其收集了浏览器和服务器端的开发者的焦点问题。明确了响应数量的增加和解决复杂的数据传输，SPDY 成为了 HTTP/2 协议的基础。

HTTP/2 和 HTTP/1.1 有几处基本的不同：

HTTP/2 是二进制协议而不是文本协议。不在可读，也不是无障碍的手动创建，改善的优化技术现在可被实施。
这是一个复用协议。并行的请求能在同一个链接中处理，移除了HTTP/1.x 中顺序和阻塞的约束。
压缩了headers，因为 headers 在一系列请求中常常是相似的，其移除了重复和传输重复数据的成本。
其允许服务器在客户端缓存中填充数据，通过一个叫服务器推送的机制来提前请求。

HTTP/3 - 基于UDP的QUIC协议实现

在HTTP/3中，将启用TCP协议，改为使用基于UDP协议的QUIC协议实现，此改变是为了解决HTTP/2中存在的队头阻塞问题，由于HTTP/2在单个TCP连接上使用了多路复用，收到TCP拥塞控制的影响，少量的丢包就可能导致整个TCP连接上的所有流被阻塞。

QUIC（快速UDP网络连接）是一种实验性的网络传输协议，由Google开发，该协议旨在使网页传输更快。