HTTP 2,实战篇
SPDY
虽然 HTTP1.0 和 HTTP 1.1 存在这么多问题,业界也是想出了各种优化手段,但是这些手段怎么说呢,都是治标不治本,直到 2020 年 Google 提出了 SPDY 的方案,大家才开始从正面看待和解决老版本 HTTP 协议本身的问题,这也直接加速了 HTTP 2.0 的诞生。
我们先来聊一下 SPDY 是什么,它都有哪些特点?
认识 SPDY
SPDY 的目标在于解决 HTTP 的缺陷,即延迟和安全性。我们上面一直在讨论延迟,至于安全性,虽然我们上面没有具体聊,不过 HTTP 的明文传输确是个问题。如果以降低延迟为目标,应用层的 HTTP 和传输层的 TCP 都是都有调整的空间,不过 TCP 作为更底层协议存在已达数十年之久,其实现已深植全球的网络基础设施当中,如果要动必然伤经动骨,业界响应度必然不高,所以 SPDY 的手术刀对准的是 HTTP 。
降低延迟,客户端的单连接单请求,服务端的 FIFO 响应队列都是延迟的大头。
HTTP 最初设计都是客户端发起请求,然后服务端进行响应,服务端无法主动发送内容到客户端。
压缩 HTTP header,HTTP 1.x 的 header 越来越膨胀,cookie 和 user agent 很容易让 header 的 size 增至 1kb 大小甚至更多。而且由于 HTTP 的无状态特性,header 必须每次请求都重复携带,很浪费流量。
为了增加解决这些问题的可行性,聪明的 Google 一开始就避开了从传输层动手,而且打算利用开源社区的力量以提高扩散的力度,对于协议使用者来说,也只需要在请求的 header 里设置 user agent,然后在服务端做好支持即可,极大的降低了部署的难度。SPDY 的设计如下
![](https://static001.geekbang.org/infoq/d0/d0379f1776320e57e68e68f44d978e55.jpeg?x-oss-process=image/resize,p_80/auto-orient,1)
可以看到,SPDY 位于 HTTP 之下,SSL 之上,这样可以轻松的兼容老版本的 HTTP 协议,SPDY 的功能分为基础功能和高级功能两部分,基础功能是默认启用的,高级功能需要手动启用。
SPDY 基础功能
多路复用(multiplexing),多路复用通过多个请求共用一个连接的方式,降低了 TCP 连接建立和释放的开销,同时提高了带宽的利用率。
请求优先级(request prioritization),多路复用带来的一个问题是,在共享连接的基础上会存在一些关键请求被阻塞,SPDY 允许给每个请求设置优先级,这样重要的请求就会优先得到响应。
header 压缩,前面提到的 HTTP 1.x 的 header 很多时候都是重复而且多余的。选择合适的压缩算法可以减小包的大小和数量。SPDY 对 header 的压缩率可以达到 80% 以上。
SPDY 高级功能
服务端推送,HTTP 只能由客户端发送,服务器只能被动发送响应。不过在开启服务端推送后,服务端通过 X-Associated-Content header 会告知服务器会有新的内容被推送过来,
服务端暗示,和服务端推送所不同的是,服务端暗示不会推送内容,只是告诉客户端有新的内容产生,,内容的下载还是需要客户端主动发起请求。服务端暗示通过 X-Subresources header 来通知,一般应用场景是客户端需要先查询服务端状态,然后再下载资源,可以节约一次查询请求。
自动 SPDY 出现后,页面加载时间相比于 HTTP 减少了 64%,而且各大浏览器厂商在 SPDY 诞生之后的 1 年多时间里也都陆续支持了 SPDY。但是,SPDY 的生存时间却没有人们想象中的那么长,SPDY 从 2012 年诞生到 2016 年停止维护,如果 HTTP 2.0 没有诞生,我相信 Google 可能会收到更多的真实反馈和数据,但是 SPDY 在这段时间里也完成了自己的使命。
初探 HTTP 2.0
HTTP 2.0 也被写作 HTTP/2 ,它是超文本传输协议的 2.0 版本,因为 SPDY 的流行让 IETF 看到了优化后的效果,以及可以通过修改协议层来优化 HTTP,所以 IETF 开始决定正式考虑制定 HTTP 2.0 的计划,而且,SPDY 的部分设计人员也被邀请参与了 HTTP 2.0 的设计。
HTTP2.0 在设计之初就与 SPDY 的设计目的和出发点不同,SPDY 更像是 Google 自家的一个产品,相当于自家的一个玩具,你怎么玩儿都行,而 HTTP 2.0 在设计之初就是为了普适性的这个目的,所以,一开始任何的设计都会关系到以后的维护问题,如果有什么瑕疵或者不足的地方可能会影响巨大,所以考虑的问题角度要非常严谨和慎重。
HTTP 2.0 在设计之初就有一些重要的前提:
客户端向服务器发送请求的这种基本模型不会改变。
原有的协议头不会改变,使用 http:// 和 https:// 的服务和应用不会做任何修改,不会有 http2://。
使用 HTTP 1.x 的客户端和服务器可以平滑升级到 HTTP 2.0 上。
不识别 HTTP 2.0 的代理服务器可以将请求降级到 HTTP 1.x。
客户端在和服务器确定是使用 HTTP1.x 还是 HTTP 2.0 之前,需要先确定对方是否支持 HTTP 2.0,所以这里必须要先进行协商,也就是客户端询问服务器,这样一来一回就多了一个 RTT 的延迟。我们对 HTTP 1.x 的修改就是为了降低延迟,现在又多了一个 RTT,这样显然是无法接受的。Google 制定 SPDY 协议的时候也遇到了这个问题,他们采取的做法是强制协商在 SSL 层完成,还因此制定了一个 TLS 的拓展,叫做 NPN(Next Protocol Negotiation)。虽然 HTTP 2.0 也采用了相同的方式,不过经过讨论后,最终 HTTP 2.0 没有强制要走 SSL 层,HTTP 2.0 没有使用 NPN,却制定了一个 TLS 的拓展叫做 ALPN(Application Layer Protocol Negotiation),现在,SPDY 也打算迁移到 ALPN 了。HTTP 2.0 的主要变化
HTTP 2.0 自从设计到诞生以来,发生了很多变化,不过对于开发人员和厂商来说,影响比较大的就几点:
二进制格式
HTTP 1.x 的诞生使用的是明文协议,它的格式主要由三部分构成:请求行(request line) 、请求头(header) 和报文体(body),要识别这三部分必须要做协议解析,而协议解析是基于文本的,基于文本的解析存在多样性的缺陷,而二进制格式只能识别 0 和 1 ,比较固定,基于这种考量,HTTP 2.0 决定采用二进制格式,实现方便而且健壮性强。
下面这幅图很好的诠释了 HTTP1.x 和 HTTP 2.0 使用的不同报文格式。
![](https://static001.geekbang.org/infoq/dc/dc5ce8113e4228525737988fad6e3ac4.jpeg?x-oss-process=image/resize,p_80/auto-orient,1)
在 HTTP 2.0 报文中,length 定义了整个 frame 的开始到结束,type 定了 frame 的类型,一种有十种,flags 定义了一些重要的参数,stream id 用作流控制,剩下的 payload 就是 request 的正文。
虽然 HTTP 2.0 报文格式看上去和 HTTP 1.x 的完全不同,但是实际上 HTTP 2.0 并没有改变 HTTP 1.x 的语义,它只是在 HTTP 1.x 的基础上封装了一层,如下图所示
![](https://static001.geekbang.org/infoq/e2/e2aaace2ce1b7d4dc139003748052d9a.jpeg?x-oss-process=image/resize,p_80/auto-orient,1)
从上图可以看到,HTTP 1.x 中的请求行、请求头被 HTTP 2.0 封装成为了 HEADERS Frame,而 HTTP 1.x 中的报文体被 HTTP 2.0 封装成为了 Data Frame。调试的时候浏览器会把 HTTP 2.0 的 frame 自动还原成 HTTP 1.x 的格式。
连接共享
我们上面聊到,HTTP 1.x 并没有真正意义上的解决连接复用问题,所以 HTTP 2.0 要解决的一大难题就是连接共享(MultiPlexing),连接共享意味着客户端与服务器之间也只需要一个连接即可,这样即使来自很多流的数据包也能够混合在一起通过同样连接传输,再根据不同帧首部的 stream id 标识符重新连接将不同的数据流进行组装。
![](https://static001.geekbang.org/infoq/64/646155ca54f5856ed8b07aba5b5bbfec.jpeg?x-oss-process=image/resize,p_80/auto-orient,1)
什么是 stream?
stream 是连接中的一个虚拟信道,可以承载双向消息传输。每个流有唯一整数标识符。为了防止两端 streaam id 冲突,客户端发起的流具有奇数 id,服务器端发起的流具有偶数 id。
我们上面提到 HTTP 1.x 没有真正解决连接共享还有一个主要的因素就是无法对不同的请求设置优先级,这样会导致关键请求被阻塞。而 HTTP 2.0 你可以对不同的 stream 设置不同的优先级,stream 之间也可以设置依赖,依赖和优先级都可以动态调整,这样就会解决关键请求被阻塞的问题。
头部压缩
上面还聊到了 HTTP1.x 中的 header 由于 cookie 和 user agent 不存在记忆
性,这样导致每次都要带着这些头重新发送请求,HTTP 2.0 使用 encoder 来减少传输的 header 大小,通信双方会各自缓存一份 header 字段表,这样能够避免重复传输 header ,也能够减小传输的大小。HTTP 2.0 采用的是 HPACK 压缩算法。
这种压缩算法的主要思想可以参考官方文档 https://httpwg.org/specs/rfc7541.html
服务端推送
服务端推送(Server Push) 我们上面也已经聊过,HTTP 2.0 能够以推的方式将客户端的内容预先发送出去,正因为没有发起请求,建立连接等操作,所以静态资源通过服务端推送的方式可以极大地提升速度。服务端推送还有一个更大的优势:缓存,缓存也能够在不同页面之间共享缓存资源。
需要注意下面几个点:
1、推送遵循同源策略;
2、这种服务端的推送是基于客户端的请求响应来确定的。
评论