HTTP/2：让Web服务更快[翻译]

HTTP/2 目标

InternetEngineering Task Force (IETF)在2015年2月，批准了HTTP/2标准提案。对于HTTP协议来说，HTTP/1.1是1999年被批准成为标准的，而HTTP/2将会是这些年来首次的大更新。HTTP/2主要的目的是在兼容HTTP/1.1的协议的情况下，降低网络通信的延迟。换句话说，就是在保持原有的Web体系的情况下，让Web更快。

 

SPDY的起源

自从2009年底，谷歌一直在开发一种叫做SPDY（发音为speedy）的试验协议。SPDY是谷歌的一个技术商标，并不是多个单词首字符的缩写，HTTP/2最初是起源于SPDY试验。实际上，很多SPDY的核心开发者也参与到了HTTP/2的协议标准的开发中。在2015年2月，谷歌为了全力支持HTTP/2，宣布停止对SPDY的开发计划。HTTP/2预计会在2016年全部完成。

 

HTTP/1.1

HTTP/1.1从1999开始为我们提供服务，已经过去了很多年，它是为了服务当时的计算机和网络场景而设计的。毋庸置疑，HTTP已经太久没有更新了。为了清晰讲述HTTP/1的工作方式，我添加了如下的图表。按照数字的顺序，你会看到，它从一个客户端（很可能是一个web浏览器）开始，建立一个HTTP/1的连接，连接到右边的服务端。

(1)建立连接

(2)客户端/浏览器发送一个GET请求（HTTP方法），获取站点的index.html页面。

(3) 服务端返回被请求的资源。

(4-7) 在我们的简单例子中，这个应答请求继续循环依次请求这个HTML文档的样式表单和script脚本。

(8)最后，关闭HTTP/1连接。

线头阻塞（Head-of-LineBlocking）

正如你所看见的，客户端/浏览器花费了大量时间在等待每个资源上。因为HTTP/1无法通过单一的连接，使用并发请求，因此，浏览器通常采用增加多个连接数，来优化传输的效率。

 

代价高昂的连接

从计算机网络的角度来看，建立多个连接是昂贵的，因为每个连接的创建都是消耗很多资源。基于这个昂贵的成本，目前主流浏览器，在单个域下的HTTP/1.1最大连接数通常都会被限制在6-8个。现在，许多网站需要请求80个或者更多资源个数，而这些限制变成了一个显著的性能瓶颈。

 

HTTP管道（HTTP Pipelining）

HTTP/1.1尝试通过HTTP管道的技术来解决这个性能瓶颈，但是不幸的是，单个的大文件或者响应缓慢的请求，仍然会阻塞其他后续请求。HTTP管道技术虽然不难部署，却几乎等于无法部署，因为目前的主流浏览器并不支持HTTP管道技术，而且，许多中间服务也不能正确处理它。

HTTP/2多路复用（HTTP/2 Multiplexing）

多路复用技术在单个HTTP/2连接上，支持在同一个时间，实现多个双向消息通信（请求-响应）。为了展示HTTP/2是多么高效，我准备了一个HTTP/1.1和HTTP/2并排的比较图。在这个简单的例子中，客户端只请求了3个资源，HTTP/2比HTTP/1.1快了不少。如果将这个HTTP/2技术用在一个请求80个资源的场景下，相比于HTTP/1.1的6-8个并发连接，单一HTTP/2连接的传输效率更高。

 

额外的HTTP/2的性能因素

除了多路复用技术，HTTP/2还采用了二级制的传输方式，替换掉HTTP/1.1的文本传输方式。比起文本协议，二级制协议在解析、传输和减少错误方面，都表现得更优秀。HTTP/2通过压缩HTTP头部信息，来减少开销，而这些是HTTP/1.1里没有的。

服务端推送（ServerPush）

服务端推送技术是HTTP/2支持的一种机制，在客户端发出请求之前，提前推送资源给客户端。如果客户端请求了你的主页（只请求了主页，尚未为发出其他css等资源文件的请求），服务端可以响应主页，同时主动加上logo和样式表单等资源，因为它知道客户端后续肯定会请求这些东西。本质上和将全部资源内嵌到一个HTML文档相同，除非被推送的资源可以缓存。

服务端推送有一个缺点，就是在客户端已经在本地缓存这些资源时，主动推送这些资源给客户端将产生资源浪费。这也是为什么，我更推荐使用服务端提示。

 

服务端提示（ServerHints）

服务端提示让客户端提前知道它需要请求的资源（原来的做法，通常是，浏览器解析HTML文档后，才知道自己需要请求的资源）。服务端不用发送完整的资源，只需要发送URL，客户端校验这些URL对应的资源，是否在缓存中，如果需要，则发送正式请求获取。服务端提示虽然不是什么新的技术，但是，在这里非常值得一提，因为它不像服务端推送技术，有可能产生冗余传输的缺点。

 

服务端提示通过HTTP的Link header实现，和现存的link prefetching语法一起使用。举个例子，一个HTTP link header如下：

Link:<https://example.com/images/large-background.jpg>; rel=prefetch

如果HTML文档头部标签已经包含了一个prefetch link，就不需要服务端的实现。例如：

<link rel="prefetch" href="https://example.com/images/large-background.jpg">

查看更多rel="prefetch"的相关资料：Linkprefetching FAQ by Mozilla.

 

更多资源提示的资料

预加载关系用于声明一个资源或者它的fetch属性，这个规范通过额外的处理策略拓展了功能，让页面有效提前加载下一个导航会用到的资源。例如：

<!-- fetch and preprocess for next navigation -->
<linkrel="preload" href="//example.com/next-page.html" as="html" loadpolicy="next">
<!-- fetch and do not preprocess for next navigation -->
<linkrel="preload" href="//example.com/next-component.html" as="html" loadpolicy="next inert">

在一些浏览器中，“next inert”加载策略和rel=prefetch的实现相同，“next”加载策略语义上等价于rel=prerender。这个规范对预获取和预渲染进行的标准化，并且拓展了一些其他功能。

想了解更多，请查看 Resource Hints （由Ilya Grgorik编辑并且发表在W3C）

HTTP/2安全批评

虽然HTTP/2的主要目的是让Web更快，但是它还是在安全方面受到猛烈批评，因为它没有实现强制加密连接。主流的浏览器厂商拒绝支持没有数据加密的HTTP/2标准。因此，HTTP/2需要通过代理的方式，部署一个数据加密连接。如果你不赞同加密连接是有益于未来Web发展的，请查看我的文章HTTPS Everywhere 。

 

浏览器支持

HTTP/2未来可能会得到所有主流浏览器的支持。

（1）Chrome 40 支持HTTP/2的14号草案，但是并非默认开启。HTTP/2的17号草案（最终版），可以在Chrome Canary 43（开发者预览版本）里使用。目前，只有基于TLS（加密）的HTTP/2实现。开启Chrome的HTTP/2支持，可以在导航栏中输入：

chrome://flags/#enable-spdy4

（2）Firefox从版本号36开始默认支持HTTP/2，它从版本号34开始，就试验性支持HTTP/2。目前，也仅实现了基于TLS的HTTP/2。

（3）IE11仅在Windows 10测试版本中支持HTTP/2，也是默认开启。目前，它也仅实现了基于TLS的HTTP/2。

（4）Spartan预计会支持基于TLS的HTTP/2，虽然，这个为Windows 10打造的新浏览器的技术细节尚未确认。

（5）Safari默认在Mac OS X Yosemite(10.10)和iOS 8中支持SPDY，预计会在2015年年底全面支持HTTP/2。

（6）Opera默认支持SPDY，预计在HTTP/2最终草案完成后，将全面支持。

服务器支持

支持HTTP/2

IIS (InternetInformation Services)在Windows10测试版中支持HTTP/2。

OpenLiteSpeed 1.3.8和 1.4.5 支持HTTP/2的17号草案。

支持SPDY，但是不支持HTTP/2

Apache 通过mod_spdy模块支持老版本的SPDY，但是目前已经停止开发了。

LiteSpeed WebServer 目前支持SPDY/3.1。

Nginx 通过一个模块为SPDY/3.1提供实验性支持，计划2015年年底支持HTTP/2。

不计划支持HTTP/2

lighttpd在版本1.x中没有支持SPDY和HTTP/2的计划。

其他HTTP/2的实现

其他已知的HTTP/2的实现，可以在GitHub HTTP/2 wiki里找到。

 

最后，关于HTTP/2的思考

正如我们所看见的，HTTP/2是一个早就应该更新应用的Web协议标准。随着在未来几年，它逐渐被广泛接受，web站点和web服务将会变得越来越快，并且各项特性将会比以前更高效。多亏了这些有远见的浏览器厂商，HTTP/2在用户私隐和安全方面也会得到加强。虽然这里仍然有很多的工作要做，但是，我能感受到HTTP/2对于整个Web体系来说，是具有重大意义的一步。

如果你对HTTP/2有疑问或者建议，可以在Twitter上联系@BenjaminPatch 。

致谢

非常感谢IlyaGrigorik, 他是谷歌的一名web性能工程师，感谢他对这篇HTTP/2文章的帮助。Ilya同时也是 《高性能浏览器网络》（High-Performance Browser Networking）的作者，这是一本很棒的书，可以让web开发者学习到更多关于网络和浏览器性能的知识。

英文原文：

https://cascadingmedia.com/insites/2015/03/http-2.html