HTTP/2.0 协议基本上已经开始大规模使用,本文主要介绍 HTTP/2.0 协议的一些特性,以及前端应该对应做哪些优化的调整。
HTTP/2.0 之前
最早期的 HTTP/1.0 时代,一个资源 == 一个 TCP 链接 == 一个 HTTP 链接,每个 HTTP 请求结束都会断开 TCP 连接,新的 HTTP 请求会另外新建一个 TCP 连接,并且只有当一个完整的请求结束(TCP closed)才会开始下一个请求(阻塞)。
这种使用 TCP 的方式最严重的问题是阻塞。后来为了解决阻塞问题,请求允许并发,即同一个域名允许建立多个 TCP 链接,这样算是解决了部分阻塞问题,但是还是有多次建立 TCP 连接的延迟(Hand shaking)以及 TCP 特有的慢启动(Slow start)问题。
补充:TCP 慢启动(Slow start)
TCP 连接会随着时间自我调整,起初会限制连接的最大速度,如果数据传输成功,会随着时间的推移提高传输速度
TCP 协议本身太复杂了,细节以后再看吧。简单来说,TCP 协议主要解决的是两个问题
- 稳定传输:ACK 确认机制
- 包乱序:Sequence Number
同时,TCP 还有两套控制机制
- Congestion Control (堵塞控制):避免高速发送端瘫痪网络
- Flow Control(流量控制):避免高速发送端瘫痪低速接收端
这些机制使得 TCP 协议不仅仅知道自己信道的情况,还能知道整个网络的情况
慢启动是堵塞控制的一个基本算法,简单说就是,先设置小一点的窗口,发送少一点的数据,然后接受 ACK,然后慢慢增加窗口大小,通过丢包率,Round Trip Time 等等来判断网络环境,设定一个合适的窗口大小。
长链接
为了解决 TCP 连接利用率低的问题,所以又提出了长链接(1.0 开启,1.1 默认开启)。即一个请求完成后,不会立刻断开连接,而是在一定的时间内保持连接,以便快速处理即将到来的 HTTP 请求,复用同一个 TCP 通道,直到客户端心跳检测失败或服务器连接超时。
- server 通过 set HTTP Header
Connection: keep-alive
来建立 - client 通过 set HTTP Header
Connection: close
来关闭
长链接解决了多次创建 TCP 连接的延迟,但是还是有线头阻塞(Head of line blocking)的问题,即一个 TCP 连接一次只能发出一个请求,所以客户端必须等待收到响应后才能发出另外一个请求,这样耗时的请求如果在前面会 block 后面耗时的请求。
小插曲:管道 Pipelining
HTTP 管道曾被提出来用以解决线头阻塞问题,即把多个 HTTP 请求通过一个 TCP 连接传送,在发送过程中不需要等待服务器对前一个请求的响应,但是客户端还是要按照发送请求的顺序接收响应。这种方式并没有根本解决线头阻塞问题,因为响应按顺序接收还是会有阻塞,所以这个功能都被浏览器默认关闭(或者压根没有)
HTTP/2.0 通过分帧将数据通过帧的方式传送,彻底解决了这个问题,并且做了一些别的优化
HTTP/2.0
协议抽象描述(下面这段话很牛逼,需要仔细研读)
在客户端与服务器之间仅建立 一个 TCP 连接,而且该连接在交互持续期间一直处于打开状态。在此连接上,消息是通过逻辑 流进行传递的。一条 消息包含一个完整的 帧序列。在经过整理后,这些帧表示一个响应或请求。
这里有一些概念很重要,下面的内容都围绕这些概念展开
- Connection (连接):仅与一个对等节点建立一个
- Stream(流):逻辑意义上的流,物理实体为连接,一个物理连接拥有多个逻辑流
- 消息 Message(请求/响应):是一组帧,通过逻辑流传输,重建这些帧会得到一个完整的请求或者响应
- 帧(Frame):通信的基本单位
帧的结构
- LENGTH :帧的大小,最多可为 2 24 bit (16MB)
- TYPE :标识帧的用途
- HEADERS:只有 header 信息
- DATA:只有 message's payload
- PRIORITY:流的优先级信息
- RST_STREAM:报错,reject PUSH_PROMISE,关闭连接
- SETTINGS:连接设置
- PUSH_PROMISE: 通知客户端有服务器推送的意图(intent)
- PING:心跳和 round-trip time
- GOAWAY:对当前连接停止提供流
- WINDOW_UPDATE:flow control of streams
- CONTINUATION:继续一系列的 HEADER fragment
- R:reserved 保留位
- FLAG:Boolean 值( 0/1)
- DATA frame 有两个 flag:END_STREAM / PADDED
- HEADER frame 有四个 flag:END_STREAM / PADDED / END_HEADERS / PRIORITY
- PUSH_PROMISE 有两个 flag:END_HEADERS / PADDED
- STREAM IDENTIFIER:用于 track the frame membership of a logical stream
其中 FLAG :
- END_STREAM:end of the data stream
- PADDED:存在填充数据
- END_HEADERS:end of the headers
- PRIORITY:优先级被设定
二进制分帧(Binary framing)
分帧层处理的栗子
1. 文本请求映射到帧
- END_STREAM 为 true (+),表示为请求的最后一帧(没有 DATA 帧)
- END_HEADERS 为 true,表示为流中最后一个包含 HEADER 信息的帧
2. 文本响应映射到帧
- END_STREAM in HEADERS 为 false (-) 表示不是流的最后一帧
- END_HEADER in HEADERS 为 true (+) 表示最后一个 HEADER 帧
- END_STREAM in DATA 为 true (+) 表示当前流最后一帧
1. 二进制协议(Binary Protocol)
HTTP/2 保留了原始 HTTP 协议的语义,但更改了在系统之间传输数据的方式
HTTP/2.0 文本格式跟二进制格式的主要差别在于解析
- 比如 TCP 就是二进制协议,每一位表示什么都是固定的,解析起来只用判断 0/1 就好,效率更高
- HTTP/1.0 就是文本协议,因为都是字符串,解析起来要么是正则,要么是状态机,效率更低
HTTP/2.0 允许保留原来的文本格式,但会经过一个"二进制分帧"的过程,将文本彻底转化为二进制传输。
2. 多路复用(Multplexing)
旧的 HTTP 协议有个问题叫线头阻塞(Head of line blocking),之前的解决方案是同时开启多个 TCP 链接(Chrome 有6个),但是这样多个 TCP 连接就很耗费网络资源了。实际上"单线程"就够了,方式就是将消息分成更小的单位(帧),这样就实现了完全双向?的请求和响应消息复用。
比如下图有三个逻辑流,一个请求(深蓝),两个响应(浅蓝,绿),每一块代表一个帧
将帧分解成 HEADER 和 DATA 帧
优点:
- Request 和 Response 都在一个 socket
- 所有的响应和请求都无法相互阻塞
- 减少了建立连接带来的延迟
- 不再需要像 HTTP/1.1 那样将多个请求合成一个
每个服务器(域)只是用一个链接,而不是每个文件一个链接
3. 服务器推送(Server push)
允许服务器预测客户端的需要,在请求处理完成之前就可以先发一个 PUSH_PROMISE frame,然后在 push 资源。为防止发送不必要的资源,服务器会给每一个要推送的资源发送一个 PUSH_PROMISE frame,如果资源已经有缓存,浏览器可以 respond 一个 RST_STREAM frame,来拒绝 PUSH
(服务器推送这个选项怎么说呢,理论上有用,但是实际上还需要 tune,有待观察吧)
4. 流控制(Flow control)
防止 receiver overwhelmed by the sender,允许 receiver 停止/减少发送的数据。
比如视屏流媒体服务,用户点击暂停,client will informs the server to stop sending video data。
连接一旦 open,server 和 client 便会交换 SETTINGS frame,从而构建 flow-control window 的大小。默认为 65KB,但是可以通过 WINDOW_UPDATE frame 来改变。
5. 头部压缩(Header compression)
头部压缩的原理是 --- 缓存,与其叫头部压缩还不如叫头部缓存。使用 HPACK 协议,要求客户端和服务器各自维护一个 HEADER 字段的列表,在多次发送的时候,只发送差异的部分,其余的从缓存表里面取。
// 用 JavaScript 描述的话大概是下面的意思
const cachedHeaders = {
method: 'GET',
host: 'example.com'
}
const newHeaders = {
method: 'POST'
}
const receivedHeaders = {
...cachedHeaders
...newHeaders
}
举个栗子,第一次请求后,第二次请求只发送与之前请求头不同的部分
6. 优先级(Priority)
Messgae 通过流传输,每个流都会被指定一个优先级,优先级决定处理的顺序和分配的资源,优先级的大小会在 HEADER frame 或者是 PRIORITY frame,为 0 - 256 的数字。
优先级还可以为树形结构,来标记依赖关系
A 先发送,B / C 同时发送,分别拿到 40% / 60% 的资源,D / E 则拿到 C 的各一半的资源。
优先级仅仅是一个参考(only a suggestion),让客户端告诉服务如何处理请求是不对的,服务器应该根据自己的能力(capabilities)来决定如何处理。
使用 HTTP/2.0 时的优化
- 减少分片(Sharding)的使用
sharding 指的是将服务分散到多个主机上,因为 2.0 以前是通过多个 TCP 连接来达到并发的目的,而浏览器对每个域名可以建立的 TCP 连接是有限制的,所以以前的优化手段是将多个资源分散到多个服务器。
但是 2.0 协议使用多个 TCP 连接反而会造成性能的下降,因为建立连接很耗费网络资源。同理原来的一些优化方式也都没什么用了比如
- Spiriting(雪碧图)一种将多个图合成一个图从而减少请求的方式
- Inline(内联)将图片用 data url 代替,从而减少请求
- Concatenation(拼接)将多个 JS 文件打包成一个
这些原来的优化方式反而会损害性能,因为各种合成和拼接都会导致缓存没那么容易。
Ref
- https://www.mnot.net/talks/h2fe/#5
- https://ye11ow.gitbooks.io/http2-explained/content/
- https://www.zhihu.com/question/34074946
- https://www.w3ctech.com/topic/1563#tip7sharding
- http://www.ruanyifeng.com/blog/2016/08/http.html
- https://juejin.im/post/5b8909036fb9a01a0b31a7a4
- https://www.ibm.com/developerworks/cn/web/wa-http2-under-the-hood/index.html
- https://developer.ibm.com/articles/wa-http2-under-the-hood/