http2.0 让网站拥有自己的速度与激情

2018-12-31 01:13 |来自: 互联网 1767 0

摘要: 现在国内很多大型公司比如淘宝,京东,知乎等都已经慢慢使用了http2.0 来提升自己网站的性能了,但是也有很大一部分网站没有使用http2.0.一直在继续使用http1.1,或许很多公司都在忙着提升自己的服务器配置,拼命的钻研优 ...

关键词：http 服务器客户端传输数据流消息推送 2.0 二进制

现在国内很多大型公司比如淘宝,京东,知乎等都已经慢慢使用了http2.0 来提升自己网站的性能了,但是也有很大一部分网站没有使用http2.0.一直在继续使用http1.1,或许很多公司都在忙着提升自己的服务器配置,拼命的钻研优化网站代码,以及使用优质的CDN资源,利用各种缓存技术等来给网站进行大提速,但是好多人都忽略了这个http传输协议上的优化

那么接下来我们就来先了解一下http传输协议以及他们的发展史

首先是HTTP1.0

早先1.0的HTTP版本，是一种无状态、无连接的应用层协议。

HTTP1.0规定浏览器和服务器保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器处理完成后立即断开TCP连接（无连接），服务器不跟踪每个客户端也不记录过去的请求（无状态）。

这种无状态性可以借助cookie/session机制来做身份认证和状态记录。而下面两个问题就比较麻烦了。

首先，无连接的特性导致最大的性能缺陷就是无法复用连接。每次发送请求的时候，都需要进行一次TCP的连接，而TCP的连接释放过程又是比较费事的。这种无连接的特性会使得网络的利用率非常低。

其次就是队头阻塞（head of line blocking）。由于HTTP1.0规定下一个请求必须在前一个请求响应到达之前才能发送。假设前一个请求响应一直不到达，那么下一个请求就不发送，同样的后面的请求也给阻塞了。

为了解决这些问题，HTTP1.1出现了。

HTTP1.1

对于HTTP1.1，不仅继承了HTTP1.0简单的特点，还克服了诸多HTTP1.0性能上的问题。

首先是长连接，HTTP1.1增加了一个Connection字段，通过设置Keep-Alive可以保持HTTP连接不断开，避免了每次客户端与服务器请求都要重复建立释放建立TCP连接，提高了网络的利用率。如果客户端想关闭HTTP连接，可以在请求头中携带Connection: false来告知服务器关闭请求。

其次，是HTTP1.1支持请求管道化（pipelining）。基于HTTP1.1的长连接，使得请求管线化成为可能。管线化使得请求能够“并行”传输。举个例子来说，假如响应的主体是一个html页面，页面中包含了很多img，这个时候keep-alive就起了很大的作用，能够进行“并行”发送多个请求。（注意这里的“并行”并不是真正意义上的并行传输，具体解释如下。）

需要注意的是，服务器必须按照客户端请求的先后顺序依次回送相应的结果，以保证客户端能够区分出每次请求的响应内容。

也就是说，HTTP管道化可以让我们把先进先出队列从客户端（请求队列）迁移到服务端（响应队列）。

如图所示，客户端同时发了两个请求分别来获取html和css，假如说服务器的css资源先准备就绪，服务器也会先发送html再发送css。

换句话来说，只有等到html响应的资源完全传输完毕后，css响应的资源才能开始传输。也就是说，不允许同时存在两个并行的响应。

可见，HTTP1.1还是无法解决队头阻塞（head of line blocking）的问题。同时“管道化”技术存在各种各样的问题，所以很多浏览器要么根本不支持它，要么就直接默认关闭，并且开启的条件很苛刻...而且实际上好像并没有什么用处。

那我们在谷歌控制台看到的并行请求又是怎么一回事呢？

如图所示，绿色部分代表请求发起到服务器响应的一个等待时间，而蓝色部分表示资源的下载时间。按照理论来说，HTTP响应理应当是前一个响应的资源下载完了，下一个响应的资源才能开始下载。而这里却出现了响应资源下载并行的情况。这又是为什么呢？

其实，虽然HTTP1.1支持管道化，但是服务器也必须进行逐个响应的送回，这个是很大的一个缺陷。实际上，现阶段的浏览器厂商采取了另外一种做法，它允许我们打开多个TCP的会话。也就是说，上图我们看到的并行，其实是不同的TCP连接上的HTTP请求和响应。这也就是我们所熟悉的浏览器对同域下并行加载6~8个资源的限制。而这，才是真正的并行！

此外，HTTP1.1还加入了缓存处理（强缓存和协商缓存[传送门]）新的字段如cache-control，支持断点传输，以及增加了Host字段（使得一个服务器能够用来创建多个Web站点）。

HTTP2.0

HTTP2.0的新特性大致如下：

二进制分帧

HTTP2.0通过在应用层和传输层之间增加一个二进制分帧层，突破了HTTP1.1的性能限制、改进传输性能。

二进制分帧层
HTTP 2.0 二进制分帧层，封装HTTP 消息并在客户端与服务器之间传输

HTTP2.0 将所有传输的信息分割为更小的消息和帧，并对它们采用二进制格式的编码。
注：HTTPS 是二进制分帧的另一个典型示例：所有HTTP 消息都以透明的方式为我们编码和解码，不必对应用进行任何修改。HTTP2.0工作原理有点类似
流、消息和帧
流：流是连接中的一个虚拟信道，可以承载双向的消息；每个流都有一个唯一的整数标识符（1、2…N）；
消息：是指逻辑上的 HTTP 消息，比如请求、响应等，由一或多个帧组成。
帧：HTTP 2.0 通信的最小单位，每个帧包含帧首部，至少也会标识出当前帧所属的流，承载着特定类型的数据，如 HTTP 首部、负荷，等等

HTTP 2.0 的所有帧都采用二进制编码，所有首部数据都会被压缩。
所有通信都在一个 TCP 连接上完成。
HTTP 2.0 把HTTP协议通信的基本单位缩小为一个一个的帧，这些帧对应着逻辑流中的消息。相应地，很多流可以并行地在同一个TCP 连接上交换消息

可见，虽然HTTP2.0的协议和HTTP1.x协议之间的规范完全不同了，但是实际上HTTP2.0并没有改变HTTP1.x的语义。

简单来说，HTTP2.0只是把原来HTTP1.x的header和body部分用frame重新封装了一层而已。

多路复用（连接共享）

下面是几个概念：

流（stream）：已建立连接上的双向字节流。
消息：与逻辑消息对应的完整的一系列数据帧。
帧（frame）：HTTP2.0通信的最小单位，每个帧包含帧头部，至少也会标识出当前帧所属的流（stream id）。

从图中可见，所有的HTTP2.0通信都在一个TCP连接上完成，这个连接可以承载任意数量的双向数据流。

每个数据流以消息的形式发送，而消息由一或多个帧组成。这些帧可以乱序发送，然后再根据每个帧头部的流标识符（stream id）重新组装。

举个例子，每个请求是一个数据流，数据流以消息的方式发送，而消息又分为多个帧，帧头部记录着stream id用来标识所属的数据流，不同属的帧可以在连接中随机混杂在一起。接收方可以根据stream id将帧再归属到各自不同的请求当中去。

另外，多路复用（连接共享）可能会导致关键请求被阻塞。HTTP2.0里每个数据流都可以设置优先级和依赖，优先级高的数据流会被服务器优先处理和返回给客户端，数据流还可以依赖其他的子数据流。

可见，HTTP2.0实现了真正的并行传输，它能够在一个TCP上进行任意数量HTTP请求。而这个强大的功能则是基于“二进制分帧”的特性。

下面从一个开发的角度走一个:

比如一个入了门的前端开发在谈到性能优化的方法时都可以轻轻松松列举如下几点:

- CSS雪碧图合并-减少请求

- 合并压缩CSS跟JS代码-减少请求

- CSS代码放在header头部里面，JS代码放到body结束之前，因为JS代码执行会阻塞

但HTTP 2.0的多路复用让我们回到最原始最自然的写码状态，先看下图

对HTTP 1.1而言，浏览器通常有并行连接的限制，即最多几个并行链接。而多路复用允许通过单一的HTTP 2.0连接发起多重的请求-相应消息

这意味着HTTP 2.0的通信都在一个连接上完成了，这个连接可以承载任意数量的双向数据流，直观来说，就是上面我们所做的优化已经不需要了

头部压缩

在HTTP1.x中，头部元数据都是以纯文本的形式发送的，通常会给每个请求增加500~800字节的负荷。

比如说cookie，默认情况下，浏览器会在每次请求的时候，把cookie附在header上面发送给服务器。（由于cookie比较大且每次都重复发送，一般不存储信息，只是用来做状态记录和身份认证）

HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。高效的压缩算法可以很大的压缩header，减少发送包的数量从而降低延迟。

如下图所示： HTTP 2.0在客户端和服务端使用首部表来跟踪和存储之间发送的键-值对，对相同请求而言不需要再次发送请求和相应发送，通信期间几乎不会改变的通用键值,如user-Agent和content-Type值发送一次，相当于做了一层缓存。

如果请求不包含首部，如：对同一资源的轮询请求，那首部开销为零字节
如果首部发生变化，那只需发送变化的数据在Headers帧里面，新增或修改的首部帧会被追加到首部表

服务器推送

服务器除了对最初请求的响应外，服务器还可以额外的向客户端推送资源，而无需客户端明确的请求。

HTTP 2.0 新增的一个强大的新功能，就是服务器可以对一个客户端请求发送多个响应。服务器向客户端推送资源无需客户端明确地请求。

HTTP 2.0 连接后，客户端与服务器交换SETTINGS 帧，借此可以限定双向并发的流的最大数量。因此，客户端可以限定推送流的数量，或者通过把这个值设置为0 而完全禁用服务器推送。
所有推送的资源都遵守同源策略。换句话说，服务器不能随便将第三方资源推送给客户端，而必须是经过双方确认才行。
PUSH_PROMISE：所有服务器推送流都由PUSH_PROMISE 发端，服务器向客户端发出的有意推送所述资源的信号。客户端接收到PUSH_PROMISE 帧之后，可以视自身需求选择拒绝这个流
几点限制：
服务器必须遵循请求- 响应的循环，只能借着对请求的响应推送资源
PUSH_PROMISE 帧必须在返回响应之前发送，以免客户端出现竞态条件

好啦接下来我来总结一下他们各自的特征总结

HTTP1.0