从理论到实践 全面理解HTTP/2

前言

为了降低加载时间，相信大多数人都做过如下尝试

• Keep-alive: TCP持久连接，增加了TCP连接的复用性，但只有当上一个请求/响应完全完成后，client才能发送下一个请求
• Pipelining: 可同时发送多个请求，但是服务器必须严格按照请求的先后顺序返回响应，若第一个请求的响应迟迟不能返回，那后面的响应都会被阻塞，也就是所谓的队头阻塞
• 请求合并：雪碧图，css/js内联、css/js合并等，然而请求合并又会带来缓存失效、解析变慢、阻塞渲染、木桶效应等诸多问题
• 域名散列：绕过了同域名最多6个TCP的限制，但增加了DNS开销和TCP开销，也会大幅降低缓存的利用率
• ……

不可否认，这些优化在一定程度上降低了网站加载时间，但对于一个web应用庞大的请求量来说，这些只是冰上一角、隔靴搔痒。

以上问题归根结底是HTTP1.1协议本身的问题，若要从根本上解决HTTP1.1的低效，只能从协议本身入手。为此Google开发了SPDY协议，主要是为了降低传输时间；基于SPDY协议，IETF和SPDY组全体成员共同开发了HTTP/2，并在2015年5月以RFC 7504正式发表。SPDY或者HTTP/2并不是一个全新的协议，它只是修改了HTTP的请求与应答在网络上的传输方式，增加了一个spdy传输层，用于处理、标记、简化和压缩HTTP请求，所以它们并不会破坏现有程序的工作，对于支持的场景，使用新特性可以获得更快的速度，对于不支持的场景，也可以实现平稳退化。

HTTP/2继承了spdy的多路复用、优先级排序等诸多优秀特性，也额外做了不少改进。其中较为显著的改进是HTTP/2使用了一份经过定制的压缩算法，以此替代了SPDY的动态流压缩算法，用于避免对协议的Oracle攻击。

多数主流浏览器已在2015年底支持了该标准（划重点）。具体支持度如下：

数据来源

可以看到国内有58.55%的浏览器已经完全支持HTTP/2，而全球的支持度更是高达85.66%。这么高的支持度，so，你心动了吗

why HTTP/2

二进制格式传输

我们知道HTTP/1.1的头信息肯定是文本（ASCII编码），数据体可以是文本，也可以是二进制（需要做自己做额外的转换，协议本身并不会转换）。而在HTTP/2中，新增了二进制分帧层，将数据转换成二进制，也就是说HTTP/2中所有的内容都是采用二进制传输。

使用二进制有什么好处吗？当然！效率会更高，而且最主要的是可以定义额外的帧，如果用文本实现帧传输，解析起来将会十分麻烦。HTTP/2共定义了十种帧，较为常见的有数据帧、头部帧、PING帧、SETTING帧、优先级帧和PUSH_PROMISE帧等，为将来的高级应用打好了基础。

如上图，Binary Framing就是新增的二进制分帧层。

多路复用

二进制分帧层把数据转换为二进制的同时，也把数据分成了一个一个的帧。帧是HTTP/2中数据传输的最小单位；每个帧都有stream_ID字段，表示这个帧属于哪个流，接收方把stream_ID相同的所有帧组合到一起就是被传输的内容了。而流是HTTP/2中的一个逻辑上的概念，它代表着HTTP/1.1中的一个请求或者一个响应，协议规定client发给server的流的stream_ID为奇数，server发给client的流ID是偶数。需要注意的是，流只是一个逻辑概念，便于理解和记忆的，实际并不存在。

理解了帧和流的概念，完整的HTTP/2的通信就可以被形象地表示为这样：

<