[翻译]http2-for-a-faster-web——快速了解http2

http2-for-a-faster-web

Benjamin发表于2015年3月18日

HTTP/2 目标

互联网工程任务组（IETF）于2015年2月经过了HTTP/2标准的提议。HTTP/2是HTTP协议自1999年HTTP 1.1发布后的首个重要的更新。HTTP/2的主要目标是保持与HTTP/1.1的高度兼容性，同时减小延迟。换句话说，避免破坏Web，同时速度更快。

SPDY 起源

自2009年末以来，谷歌一直在开发一种名为SPDY的实验性协议（发音为speedy）。SPDY是Google的商标，而不是首字母缩略词。HTTP/2最初基于SPDY进行实验。其实，许多SPDY核心开发人员都参与了HTTP/2的开发。截至2015年2月,谷歌宣布到2016年将彻底撤销对SPDY的支持，转而对HTTP/2进行支持。

HTTP/1.1

虽然HTTP/1.1自1999年发布以来一直很好用，它是专为当时的计算机和Web而设计的。毋庸置疑，HTTP早就应该进行更新了。为了更好的描述HTTP/1的工做原理，以下图所示。

按照如下数字表示的步骤，首先从客户端（或者Web浏览器）开始，在右侧创建与服务器的HTTP/1链接。

（2）客户端／浏览器访问网站的index.html页面并发送了一个GET请求（HTTP方法）。

（3）第三步表示服务器响应请求的资源。

（4-7）HTML文档所需的CSS样式和JS脚本的请求过程，和上面例子中的请求响应周期同样。

（8）结束，HTTP/1链接关闭。

队头阻塞（Head-of-Line Blocking）

众所周知，客户端/浏览器花费大量时间等待每一个资源。因为HTTP/1没法经过单个链接发出并发请求，所以浏览器一般会尝试经过打开多个链接来加快进程。

昂贵的链接（Expensive Connections）

从计算机网络的角度来看，虽然多个链接是有帮助的，但每打开一个链接都很是昂贵。因此，现代浏览器将HTTP/1.1链接数限制为最多6-8个。因为许多网站如今须要80个或更多资源，所以这些限制会产生严重的性能瓶颈。

HTTP管线化（HTTP Pipelining）

HTTP/1.1尝试使用HTTP管线化的技术来纠正性能瓶颈。然而，当有一个大的或慢的响应的时候，它仍然会阻塞随后的其余响应（也就是说，仍是会出现线头阻塞的现象）。HTTP管线化很难进行部署。没有现代浏览器支持HTTP管线化，由于许多中介和服务器没法正确处理它。

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

多路复用容许多个request-response消息同时在单个HTTP/2链接上传输。为了演示HTTP/2链接的效率，以下图，与HTTP/1进行了比较。即便在只有三个必需资源的简单示例中，请注意网页开始渲染的速度有多快。

将80种所需资源的常见状况进行对比，能够明显的得出6-8个HTTP/1.1的链接开销以及单个HTTP/2链接的效率。

其余HTTP/2性能因素

除了多路复用，HTTP/2是二进制的，而不像HTTP/1是文本。与文本协议相比，二进制协议解析效率更高，在线上更严谨、不容易出错。

HTTP/2还会经过压缩headers来减小开销，而HTTP/1则不会。

服务器推送（Server Push）

Server Push（服务器推送）是一种HTTP/2机制，用于在客户端请求以前向客户端发送数据。例如，若是你的主页有请求，服务器可使用主页以及徽标、样式表进行响应，由于它知道客户端须要这些资源。除了推送的资源能够缓存外，这与在HTML文档中内联全部资源基本相同。

在客户端已经缓存资源的状况下，Server Push可能就会显得冗余。因此我建议使用Server Hints（服务器提示）。

服务器提示（Server Hints）

在客户端发现资源以前，Server Hints（服务器提示）告知客户端即将须要的资源。服务器不发送资源的所有内容，而只发送URL。而后，客户端能够验证其缓存，若是须要的话就正式请求资源。Server Hints对于HTTP/2并不陌生，但值得一提的是，它们不会受到服务器推送可能形成冗余的缺陷的影响。

Server Hints是使用带有HTTP的连接头实现的，并与现有的连接预取语义重叠。例如，HTTP连接头以下所示：

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

若是HTML文档在head标记中包含预取连接，则不须要服务器端实现。例如：

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

想要了解有关rel =“prefetch”的更多信息，请参阅Mozilla关于连接预取的常见问题解答

进一步了解资源提示

预加载关系用于声明资源和获取属性。此规范经过其余处理策略扩展了功能，这些策略能够有效地获取下一个导航可能须要的资源。例如：

<!-- fetch and preprocess for next navigation -->
<link rel="preload" href="//example.com/next-page.html" as="html" loadpolicy="next">

<!-- fetch and do not preprocess for next navigation -->
<link rel="preload" href="//example.com/next-component.html" as="html" loadpolicy="next inert">
复制代码

"next inert"至关于某些浏览器实现的rel = prefetch。“next”在语义上至关于某些浏览器实现的rel = prerender。该规范经过使附加功能标准化并扩展了之前的预取和预渲染功能。

要了解更多信息，请参阅由Ilya Grigorik发布在W3C上的Resource Hints。

HTTP/2安全性批评

尽管HTTP/2的主要目标是使Web更快，可是因为没有强制对链接进行加密，它受到了很严厉的批评。并且，主要的浏览器制造商迄今拒绝对没有加密的HTTP/2进行支持。因此HTTP/2经过代理来部署加密的链接。若是你认为这不利于Web的将来，请查看个人文章：HTTPS Everywhere

译者注： 这里说HTTP/2没有强制对链接进行加密。可是维基百科上提到针对加密的争议时说：

一开始，以HTTP工做组某位主席为首的成员在邮件列表建议引入强制使用TLS协议实现的HTTP/2.0（Mandatory TLS in HTTP/2.0），这招致了争议。批评者认为，加密增长了十分没必要要的开销，并且不少HTTP服务实际上无需加密，提供者也无心为此花费更多的资源。而支持者认为，实践中TLS加密的开销微不足道。

Poul-Henning Kamp 批评IETF在制定HTTP/2时，遵循了一个特定的“政治议程”（political agenda），压缩了讨论的空间。

强制加密议程的批评者认为，其基于现有的证书框架，对于开源社区并不是新创造，亦不是独特的。2013年，一位思科员工表示，现有证书模型与路由器一类的小型化设备并不兼容，由于现有的证书框架须要为每张证书付出不可避免的成本，还须要进行每一年更新的流程。工做组最终未能在强制加密这一点上达成一致，可是大部分客户端只实现了基于TLS的HTTP/2，使之成为事实标准。

HTTP/2也被批评未能支持机会性加密，即相似SMTP中存在已久的STARTTLS同样能抵御被动监控的措施。 批评者指出，HTTP/2的提议违背了IETF自身制定的《最佳实践 188》（BCP 188） 即 RFC 7258。这份文件指出，被动监控应被看成一种攻击，IETF指定的标准应当设置抵御这种攻击的措施（例如机会性加密）。目前，已经有一系列机会性加密规范被提出，工做组也制定了 draft-ietf-httpbis-http2-encryption-01 这一官方版方案。
复制代码

浏览器支持

全部主流浏览器都将支持HTTP/2

• Chrome 40支持HTTP/2草案-14，但默认状况下不开启。HTTP/2 草案-17（最终版）可在Chrome Canary 43（开发人员预发布版本）中找到。目前，仅实现了基于TLS（加密）的HTTP/2。 要在Chrome中启用HTTP/2，请在地址栏中输入：chrome://flags/#enable-spdy4
• Firefox支持HTTP/2，自版本36以来默认启用了HTTP/2.最初在版本34中添加了对HTTP/2的实验性支持。目前，仅实现了TLS上的HTTP/2。
• Internet Explorer 11支持HTTP/2，但仅限于Windows 10 beta，默认状况下启用它。目前，仅实现了基于TLS的HTTP/2。
• 尽管微软新推出的Windows 10浏览器不断爆出细节，但预计Spartan将支持HTTP/2而非TLS。
• 默认状况下，Safari在Mac OS X Yosemite（10.10）和iOS 8中支持SPDY。预计到2015年末将提供完整的HTTP/2支持。
• Opera默认支持SPDY。一般一旦最终的HTTP/2草案在Chrome中可用的时候，Opera就会提供支持。

服务器支持

HTTP/2支持

• IIS（互联网信息服务）在Windows 10 beta中支持HTTP/2。
• OpenLiteSpeed 1.3.8和1.4.5支持HTTP/2草案17。

支持SPDY，可是没有HTTP/2

• Apache经过mod_spdy模块为旧版本的SPDY提供支持，但此模块的开发已中止。
• LiteSpeed Web Server目前支持SPDY/3.1。
• Nginx经过模块为SPDY（草案3.1）提供实验性支持，并计划在2015年末以前支持HTTP/2。

不计划支持HTTP/2的

• lighttpd不对SPDY进行支持。或者计划在1.x版本中支持HTTP/2。

其余HTTP/2实现

能够在GitHub HTTP/2 wiki上找到HTTP/2的其余已知实现。

结语：HTTP/2的思考

正如咱们探讨的那样，HTTP/2是Web早就应该作的更新。随着它在将来几年被普遍采用，网站和其余网络服务将变得比以往更快，更强。感谢具备远见的浏览器制造商，HTTP/2也将加强用户隐私和安全性。虽然还有许多工做要作，但我以为HTTP/2是整个Web的重要一步。

若是你对HTTP/2有任何问题或意见，能够经过Twitter @BenjaminPatch 与我联系。

致谢

感谢Google的网络性能工程师Ilya Grigorik对这篇HTTP/2文章的贡献。Ilya仍是高性能浏览器网络的做者，它是Web开发人员了解有关网络和浏览器性能的很棒的资源。

原文地址