整理自:A Simple Performance Comparison of HTTPS, SPDY and HTTP/2
html
Firefox 35,成为第一个默认开启支持HTTP/2协议的浏览器。Chrome也支持了,只是以SPDY 4的名义,而且要本身在about://flags
里面手动开启。git
不过HTTP/2规范尚未最终完成,因此Firefox实际上支持的是HTTP/2第14版草案,这个版本的草案离最终发布可能不会有大改动了。Google如今在其服务器上同时支持了HTTP/2的第14草案和SPDY协议,这就给咱们了一个基于同一个网页来对比HTTPS, SPDY和 HTTP/2的性能的机会。github
HttpWatch 也更新了,从而能够在Firefox里面监控HTTP/2了,它如今有一列专门显示每一个请求所使用的协议了:web
这组性能测试是使用Firefox和HttpWatch,测试页面为Google英国首页,使用了三种协议:算法
原始的HTTPS浏览器
SPDY/3.1缓存
HTTP/2安全
经过在Firefox的about:config
中启用/禁用下面的功能来切换不一样的协议:服务器
每次测试都是基于空缓存的。因此即使这个测试很简单而且只基于一个网站,但其结果仍是具备表明性的。网络
大部分网站在下载文本内容的时候已经启用了压缩(Gzip),由于它能够提供很明显的性能优点。可是很不幸,HTTP/1.1不支持压缩每一个请求和相应的HTTP报头。SPDY和后来的HTTP/2旨在使用不一样的压缩类型来弥补这个短板。
SPDY使用普通的DEFLATE 算法而HTTP/2使用专门为压缩报头而设计的HPACK算法。它使用预约义的token、动态表以及哈夫曼压缩。
从一个空请求也能够看到生成的报头大小的不一样。在Google英国首页有返回空内容的信标请求(204返回码)。下面是HttpWatch的截图,‘Sent’列显示请求报头的大小,‘Received’列显示响应报头的大小:
胜出: HTTP/2
HTTP/2的报头大小仍是很明显的,看来HPACK确实不错。
响应信息包括响应报头和编码过的响应内容。HTTP/2提供了最小的报头,那么它会否给到最小的响应信息?
图片资源是这样的:
可是,对于文本内容SPDY却有着更小的响应信息,尽管它的报头比HTTP/2要大:
缘由在于可被添加到HTTP/2数据帧的可选填充字节。HttpWatch如今并不能显示填充,可是在debug log里面能够看到Google服务器向文本内容的数据帧中添加了填充。HTTP/2规范给到的使用填充的理由是:
填充能够用来混淆帧内容的实际大小,并且减小HTTP中的特殊攻击。例如,压缩的内容包含攻击者控制的明文和秘密数据的攻击(见 [BREACH]).
填充不会用于图片文件,由于它已是压缩过的格式了,并不包含攻击者控制的纯文本。
胜出:SPDY
在Google服务器上看到的较大的响应体是由于在数据帧中使用了填充。尽管,HTTP/2产生了比SPDY大的响应信息,它的加密链接可能会更安全。这可能会是安全和性能权衡折衷的一个地方。
经过将每一个域名的最大并发链接数从2个提高到6个甚至更多,浏览器在HTTP/1.1实现了明显的性能提高。增长并发使得网络带宽能够更有效的利用,由于它减小了请求块。
SPDY和HTTP/2经过复用单个链接来容许多个请求一次发送和接收数据来支持在一个TCP和SSL链接中的并发。
增长了‘Connect’和‘SSL Handshake’时间后,SPDY:
HTTP/2:
它们只为不一样的域名建立链接,而原来的HTTPS能够为一个域名来建立多个链接来提升并发:
共同胜出: SPDY & HTTP/2
在SPDY和HTTP/2中增长的复用支持减小了下载页面时不得不设置的网络链接的数量。做为附加好处,当HTTP/2使用的更加普遍时,网络服务器不用再不得不维护太多的活动TCP链接了。
HttpWatch中的‘Page Load’时间显示页面被彻底下载并可用的时间。大部分状况下,这是合理的网页速度的衡量数据。
下面的截图显示了三种协议的页面加载时间:
胜出:HTTP/2
原生的HTTPS的加载时间最长的缘由多是缺少报头压缩和额外的TCP链接和SSL握手请求。对于更复杂的页面来讲,SPDY和HTTP/2的优点可能会更加明显。
咱们也发现HTTP/2一般比SPDY要快,尽管它的响应信息一般更大。这个优点多是由于HPACK压缩减小的更小的GET请求信息。咱们的网络链接,和许多人同样,是非对称的——网络上传速度比下载速度小不少。这意味着任何节省的上传数据比节省的等量的下载数据更有价值。
HTTP/2看起来能提供明显的性能优点,。然而,响应信息中填充的使用会是一个潜在的关于性能和安全的权衡点。