8. http2的世界

那么当http2被广泛采用的时候，世界将会成什么样呢？或者说，它会被真正的采用吗？

到目前为止，http2还没被大范围部署使用，我们也无法确定到底会发生什么变化，但至少可以参考SPDY的例子和曾经做过的实验来进行大概的估计。

http2减少了网络往返传输的数量，并且用多路复用和快速丢弃不需要的流的办法来完全避免了head of line blocking(线头阻塞)的困扰。

它也支持大量并行流，所以即使网站的数据分发在各处也不是问题。

合理利用流的优先级，可以让客户端尽可能优先收到更重要的数据。

所有这些加起来，我认为页面载入时间和站点的响应速度都会更快。简而言之，它们都代表着更好的Web体验。

但到底能变得多快，到底提升有多大呢？我认为目前很难说清楚。毕竟这些技术依然在早期阶段，我们还无法看见客户端和服务器实现这些并真正受益于它所提供的强大功能。

近年来，Web开发者、Web开发环境为HTTP 1.1存在的一些问题提供了一部分临时的解决方案。其中的一部分我已在上文中简单的介绍了，不妨简单的回忆一下。

很多工具和开发者可能会默认使用这些方案，但它们其中的一部分也许会损害到http2的性能，或者至少让我们无法真正利用到http2新提供的强大威力。Spriting和内联应该是http2里面最不需要的了。因为http2更倾向于使用更少的连接，所以Sharding甚至会伤害到http2的性能。

这里的问题在于：对于网站的开发者而言，在短期内开发和部署同一套前端来支持http 1.1和http2的客户端访问并获得最大性能将会是一个挑战。

考虑到这些问题，我认为彻底发掘http2的潜力还有很长一段路要走。

在这样一篇文章中详细说明每个实现细节注定乏味且毫无意义，我将用更通用的术语来解释实际的场景，并在此给大家提供一个http2的实现列表作为参考。

在http2的早期就已经有大量的实现。并且在http2标准化工作期间，这个数量还持续增长。截至我写这篇文档的时候，共有40种实现已记录在案，他们中的大多数都实现了最新的草案。

Firefox一直紧跟最新的协议，Twitter也紧追不舍提供了基于http2的服务。2014年4月期间，Google在少数测试服务器上提供http2支持。从同年5月开始，开发版的Chrome支持http2。Microsoft也在他们的产品预发布会上展示了支持http2的下一代浏览器。Safari (iOS 9 以及 Mac OS X El Capitan) 和 Opera也都表态它们将会支持http2。

事实上，已经有不少的服务器实现了http2。

时下最流行的Nginx自1.9.5(发布于2015年9月22号)版本后提供了对http2的支持并且取缔了原来的SPYD模块(因此SPYD和http2无法同时运行在同一个Nginx服务器实例中)。

而Apache HTTPD服务器也实现了一个名为mod_http2的http2模块，并与2015年10月9号在2.4.17的版本中发布。

此外，H2O, Apache Traffic Server, nghttp2, Caddy 以及 LiteSpeed 也都发布了可以工作于http2下的服务器。

curl和libcurl支持未加密的http2并借助某些TLS库支持了TLS版本。

Wireshark同样支持了http2, 所以用它来分析http2网络数据流着实是再好不过的了。

在制定协议的讨论过程中往往存在许多争议，甚至会有不少人认为这样的协议最终会以失败告终。这里我想提一些常见的对协议的批评以及我的解释：

江湖上有太多传言暗示着这个世界越来越被Google所控制，但事实显然并非如此。这个协议是IETF制定的，就跟过去30年间很多其他协议一样。但不得不承认，SPDY是Google非常出色的成果。它不仅仅证明了开发一个新协议的可行性，还充分展现了新协议所能带来的好处。

而Google也公开的声明了他们会在2016年移除Chrome里对SPDY和NPN的支持，并且极力推动服务器迁移至HTTP/2。

在一定意义上，这是对的。开发http2的其中一个主要原因就是修复HTTP pipelining。如果在你的应用场景里本来就不需要pipelining，那么确实很有可能http2对你没有太大帮助。虽然这并不是唯一的提升，但显然这是非常重要的一个。

一旦当某些服务意识到在一个连接上建立多路复用流的强大威力时，我认为会有越来越多的程序采用http2。

小规模的REST API和采用http 1.x的简单程序可能并不会从迁移到http2中获得多大的收益。但至少，迁移至http2对绝大部分用户来讲几乎是没有坏处的。

完全不是这样。因为缺乏内容分发网络，小网站的网络延迟往往较高，而多路复用的能力可以极大的改善在高网络延迟下的体验。大型网站往往已经将内容分发到各处，所以速度其实已经非常快了。

这个评价在某种程度上是对的。虽然TLS的握手确实增加了额外的开销，但也有越来越多的方案提出来减少TLS往返的时间。使用TLS而不是纯文本带来的开销是显著的，有可观证据表明，和传输同样的流量相比，TLS会消耗更多的CPU和其他资源。具体影响有多大以及怎么影响是一个和具体测量有关的课题。更多的例子可以参看istlsfastyet.com。

Telecom和一些其他网络服务商，例如ATIS开放网络联盟，表示为了为卫星、飞机等提供的快速网络体验，他们需要一些不加密的流量来提供caching，压缩和其他技术。

由于http2并不强制要求使用TLS，所以我们不应该为此担心。

如今，很多互联网使用者都希望TLS能被更广泛的使用来保护用户隐私。

实验也证明了通过使用TLS能比用在80端口实现一个新的基于文本的协议更容易成功。因为当前已经有太多中间商使用该方案，所以凡是基于80端口的协议，都很可能被理所当然的当作HTTP 1.1。

最后，得益于http2可以在单一连接上提供多路复用的流，正常使用普通浏览器也可以减少TLS握手的次数，所以使用HTTPS仍然会比HTTP 1.1更快。

是的，如果我们可以直接读出协议内容，那么调试和追踪都会变得更为简单。但是基于文本的协议更容易产生错误，造成更多解析的问题。

假如你真的无法接受二进制协议，那么你也很难在HTTP 1.x中处理TLS和压缩。因为其实这些技术已经被使用了很久了。

当然，到底该如何定义和衡量“快”就是另外一个话题了，但在SPDY的时代，已经有很多实验证明了该协议会让浏览器载入页面变得更快（例如华盛顿大学的“SPDY有多快？”和Hervé Servy的“评估启用SPDY后的Web服务器的性能”），同样这些实验也可以被用来证明http2。我期待能有越来越多的诸如此类的测试实验结果发布。而这篇文章httpwatch.com的一个简单测试亦能证明HTTP/2名副其实。

你确定这也是反对的理由么？网络分层并不是不可侵犯的。如果我们在制定http2的时候已经踏入了灰色地带，那我们当然可以尝试在限制内制定出更好更高效的协议。

确实是这样。兼容HTTP/1.1的范式是我们的目标之一，所以一些老的HTTP功能仍然被保留。例如一些常用的协议头、可怕的cookies、验证头等等。但保留这些范式的好处就是我们在升级到新协议的时候少掉很多工作，也不需要重写很多底层的东西。Http2其实只是一个新的帧层。

现在讨论这个议题还言之尚早，但我仍然要在这里做出我的预估。

很多怀疑论者会以“看看IPv6现在的德性”为让我们回想起这个经历了10多年才开始慢慢被采用的协议。但http2毕竟不是IPv6。它是一个建立在TCP之上的使用基于原有HTTP协议升级过后的机制、端口号和TLS等的协议。大部分路由器或者防火墙不需要为此而进行更改。

Google向世界展示了他们的SPDY，证明了像这样的新协议也能在足够短的时间内拥有多种实现，并且能被浏览器和服务所采用。虽然如今支持SPDY服务器端数量在1%以内，但通过这些服务器所交换的数据却要大很多。很多非常流行的网站现在也有提供SPDY支持。

我认为建立在SPDY的基本范式之上的http2会被更广泛的部署，其中一个主要的原因是：它是一个IETF制定的协议。而SPDY则因为背负了“它是Google的协议”这个恶名，导致它的发展总是畏首畏脚。

在它首次发布的幕后有很多大型浏览器支持。来自Firefox，Chrome，Safari，Internet Explorer和Opera的代表宣布了他们会发布支持http2特性的浏览器，并且他们已经演示了一些能正常运作的实现。

也有很多像Google，Twitter和Facebook这样的服务器运营者希望尽快支持http2，也同样希望可以快点在主流服务器实现中出现对http2的支持（例如Apache HTTP Server和nginx）。而H2o作为一个极具潜力的新生HTTP服务器，已经支持了http2。

那些大型代理程序开发者，例如HAProxy、Squid和Varnish也表示出了他们对支持http2的兴趣。

纵观2015年，http2的流量正在逐步上升。9月初，Firefox 40中http2流量占据了所有HTTP流量中的13%，HTTPS中的27%。与此同时，Google表示约有18%的流量来自HTTP/2。值得注意的是，Google同时也在实验其他协议（参见12.1中的QUIC），这也使得http2的使用量暂时比正常值低一些。