Http的发展

作者: 小智DotNet | 来源:发表于2019-05-15 20:50 被阅读0次

目前进行web项目的开发，都是通过http来传输数据，因此前端和后端的同学都要了解下，今天我们就来了解下Http到底是何方神圣以及它发展历程。

what.jpg

一、What

HTTP（HyperText Transfer Protocol）是万维网（World Wide Web）的基础协议。自 Tim Berners-Lee博士和他的团队在1989-1991年间创造出它以来，HTTP已经发生了太多的变化，在保持协议简单性的同时，不断扩展其灵活性。如今，HTTP已经从一个只在实验室之间交换文件的早期协议进化到了可以传输图片，高分辨率视频和3D效果的现代复杂互联网协议。

1.1 万维网简单介绍

1989年，当时在CERN工作的Tim Berners-Lee博士写了一份关于建立一个通过网络传输超文本系统的报告。这个系统起初被命名为Mesh，在随后的1990年项目实施期间被更名为万维网（World Wide Web）。它在现有的TCP和IP协议基础之上建立，由四个部分组成：

一个用来表示超文本文档的文本格式，超文本标记语言（HTML）。
一个用来交换超文本文档的简单协议，超文本传输协议（HTTP）。
一个显示（以及编辑）超文本文档的客户端，即网络浏览器。第一个网络浏览器被称为WorldWideWeb。
一个服务器用于提供可访问的文档，即httpd的前身。

这四个部分完成于1990年底，且第一批服务器已经在1991年初在CERN以外的地方运行了。
1991年8月16日，Tim Berners-Lee 在公开的超文本新闻组上发表的文章被视为是万维网公共项目的开始。

二、Http各版本介绍

2.1 HTTP/0.9 – 单行协议

HTTP在应用的早期阶段非常简单，也没有版本的概念，后来为了方便区分版本，被定义为HTTP/0.9，也称之为单行（one-line）协议。

HTTP/0.9 极其简单：请求由单行指令构成，以唯一可用方法GET开头，其后跟目标资源的路径（一旦连接到服务器，协议、服务器、端口号这些都不是必须的）。

GET /index.html
响应也极其简单的：只包含响应文档本身。

<HTML>
Hello World！！
</HTML>

注意： 和之后的版本相比，HTTP/0.9协议的响应内容并不包含HTTP头，这意味着只有HTML文件可以传送，无法传输其他类型的文件；也没有状态码或错误代码：一旦出现问题，一个特殊的包含问题描述信息的HTML文件将被发回，供人们查看。

2.2 HTTP/1.0 – 构建可扩展性节

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

协议版本信息会追加到每个请求（HTTP/1.0被追加到了GET行）。
状态码会在响应开始时发送，使浏览器能了解请求执行成功或失败，并相应调整行为（如更新或使用本地缓存）。
引入了HTTP头的概念，无论是对于请求还是响应，允许传输元数据，使协议变得非常灵活，更具扩展性。
在新HTTP头的帮助下，具备了传输除纯文本HTML文件以外其他类型文档的能力（Content-Type头）。

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

request

GET /mypage.html HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5)

response

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

从上面这条命令可以看到，每个请求命令必须在尾部添加协议版本（HTTP/1.0）。下面是是本次请求的其它头信息，用来描述本次请求的客户端情况。

接下来是第二个连接，请求获取图片：

request

GET /hello.gif HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5)

response

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

HTTP/1.0 不足

HTTP/1.0的主要不足，每个TCP连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接。

TCP连接的新建成本很高，因为需要客户端和服务器三次握手，并且开始时发送速率较慢（slow start）。因此，HTTP/1.0的性能比较差。随着网页加载的外部资源越来越多，这个问题就愈发严重了。

为了解决这个问题，有些浏览器在请求时，用了一个非标准的Connection字段。

Connection: keep-alive

这个字段要求服务器不要关闭TCP连接，以便其他请求复用。服务器同样回应这个字段。

Connection: keep-alive

一个可以复用的TCP连接就建立了，直到客户端或服务器主动关闭连接。但是，这不是标准字段，不同实现的行为可能不一致，因此不是根本的解决办法。

2.3 HTTP/1.1 – 标准化的协议节

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

HTTP/1.1 引入了多项改进：

持久链接（keep-alive），为了解决上一个版本的不足，节省多次打开TCP连接加载网页文档资源的时间，正式引入了持久连接（persistent connection），即TCP连接默认不关闭，可以被多个请求复用，不用声明Connection: keep-alive。(对于同一个域名，大多数浏览器允许同时建立6个持久连接)。
HTTP管道，允许在第一个应答被完全发送之前就发送第二个请求，以降低通信延迟。
支持响应分块。
引入额外的缓存控制机制。
引入内容协商机制，包括语言，编码，类型等，并允许客户端和服务器之间约定以最合适的内容进行交换。
引入Host头，用来指定服务器的域名，同时可以实现将不同域名配置在同一个IP地址的服务器上的功能，为虚拟主机的兴起打下了基础。。
版还新增了许多动词方法：PUT、PATCH、HEAD、 OPTIONS、DELETE。

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

request

GET /api/v1/User/GetUserInfo HTTP/1.1
Host: localhost:5000
Connection: keep-alive
accept: application/json
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36
Referer: http://localhost:5000/swagger/index.html
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9

response

HTTP/1.1 200 OK
Date: Wed, 15 May 2019 11:20:06 GMT
Content-Type: application/json; charset=utf-8
Server: Kestrel
Transfer-Encoding: chunked
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN

HTTP/1.1 不足

HTTP/1.1 虽然允许复用TCP连接，但是同一个TCP连接里面，所有的数据通信是按次序进行的。服务器只有处理完一个回应，才会进行下一个回应。要是前面的回应特别慢，后面就会有许多请求排队等着。这称为"队头堵塞"（Head-of-line blocking)。

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

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

HTTP/2 介绍

2009年，谷歌公开了自行研发的 SPDY 协议，主要解决 HTTP/1.1 效率不高的问题。
这个协议在Chrome浏览器上证明可行以后，就被当作 HTTP/2 的基础，主要特性都在 HTTP/2 之中得到继承。2015年，HTTP/2正式发布。它没有像之前的版本那边定为HTTP/2.0，是因为标准委员会不打算再发布子版本了，下一个新版本将是HTTP/3。

HHTTP/2在HTTP/1.1有几处基本的不同和引入的新特性:

二进制协议

HTTP/1.1 版的头信息肯定是文本（ASCII编码），数据体可以是文本，也可以是二进制。HTTP/2则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为"帧（frame）：头信息帧和数据帧。二进制协议的一个好处是，可以定义额外的帧。HTTP/2 定义了近十种帧，为将来的高级应用打好了基础。如果使用文本实现这种功能，解析数据将会变得非常麻烦，二进制解析则方便得多。

多工(Multiplexing)

多工是指双向的、实时的通信，就叫做多工。HTTP/2支持多工这是一个复用协议。并行的请求能在同一个链接中处理，移除了HTTP/1.x中顺序和阻塞的约束。HTTP/2 正式由于复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应，这样就避免了"队头堵塞"。

数据流

因为HTTP/2引入了多工，这就出现了的数据包是不按顺序发送的清醒，同一个TCP连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，来识别出它属于哪个请求的回复。

HTTP/2将每个请求或回应的所有数据包，称为一个数据流（stream）。每个数据流都有一个独一无二的编号。数据包发送的时候，都必须标记数据流ID，用来区分它属于哪个数据流。另外还规定，客户端发出的数据流，ID一律为奇数，服务器发出的，ID为偶数。

数据流发送到一半的时候，客户端和服务器都可以发送信号（RST_STREAM帧），取消这个数据流。1.1版取消数据流的唯一方法，就是关闭TCP连接。这就是说，HTTP/2 可以取消某一次请求，同时保证TCP连接还打开着，可以被其他请求使用。

客户端还可以指定数据流的优先级。优先级越高，服务器就会越早回应。

headers压缩

由于HTTP/1.x 协议是无状态的，每次请求都必须附上所有信息。因此Http请求的很多字段都是重复的，比如Cookie和User Agent，这些重复的头信息，在每次请求中也是必须附带的，这就会浪费很多带宽，也影响速度。
在HTTP/2 针对这个不足做了优化,引入了头信息压缩机制(header compression)，主要引入了两个工作，首先使用gzip或compress对头信息压缩后再发送；其次，在客户端、浏览器以及服务器各自维护一张头信息表，所有字段都会存入这个表，并生成一个索引号，以后就不发送同样相同的头信息，仅发送索引号，这样就垫底了重复和传输重复数据的成本。
4 。其允许服务器在客户端缓存中填充数据，通过一个叫服务器推送的机制来提前请求。

服务器推送

HTTP/2 服务器推送（server push）是指允许服务器未经请求，主动向客户端推送资源。

常见场景是客户端请求一个网页，这个网页里面包含很多静态资源。正常情况下，客户端必须收到网页后，解析HTML源码，发现有静态资源，再发出静态资源请求。其实，服务器可以预期到客户端请求网页后，很可能会再请求静态资源，所以就主动把这些静态资源随着网页一起发给客户端了

HTTP/2发展

在2015年5月正式标准化后，HTTP/2取得了极大的成功，在2016年7月前，8.7%的站点已经在使用它，代表超过68%的请求[2] 。高流量的站点最迅速的普及，在数据传输上节省了可观的成本和支出。
这种迅速的普及率很可能是因为HTTP2不需要站点和应用做出改变：使用HTTP/1.1和HTTP/2对他们来说是透明的。拥有一个最新的服务器和新点的浏览器进行交互就足够了。只有一小部分群体需要做出改变，而且随着陈旧的浏览器和服务器的更新，而不需Web开发者做什么，用的人自然就增加了。

随着HTTP/2.的发布，就像先前的HTTP/1.x一样，HTTP没有停止进化，HTTP的扩展性依然被用来添加新的功能。特别的，我们能列举出2016年里HTTP的新扩展：

对Alt-Svc的支持允许了给定资源的位置和资源鉴定，允许了更智能的CDN缓冲机制。
Client-Hints 的引入允许浏览器或者客户端来主动交流它的需求，或者是硬件约束的信息给服务端。
在Cookie头中引入安全相关的的前缀，现在帮助保证一个安全的cookie没被更改过。