HTTPS,SPDY,HTTP/2性能对比

作者：zhanhailiang 日期：2015-01-24

原文：A Simple Performance Comparison of HTTPS, SPDY and HTTP/2

首先，恭喜Firefox 35成为第一个默认支持HTTP/2协议的浏览器。不过由于HTTP/2协议并未完全确定，所以目前Firefox实际支持的是HTTP/2 Draft 14版本（当然最终的协议确认不会有大的改动）。由于Google已经在服务器端同时支持HTTP/2 Draft 14版本和SPDY协议，所以我们可以通过访问Google服务器来对比HTTPS，SPDY，HTTP/2的性能差别。

注：需要更新HttpWatch到最新版本以支持HTTP/2协议，最新版的HttpWatch添加Protocol列展示请求的协议信息，如下图：

性能对比

以下性能测试将基于Firefox+HttpWatch，通过HTTPS，SPDY/3.1，HTTP/2协议访问谷歌香港首页来得到各自的页面负载测试数据。每次访问我们将通过Firefox about:config页面设置只开启一个指定协议来测试，如下图：

注：每次测试需要清空本地缓存。

测试1 请求头和响应头的大小对比

大家知道，绝大多数的站点会开启gzip来压缩响应的文本内容。但是不幸的是，HTTP/1.1协议本身不支持请求头/响应头的压缩。SPDY和HTTP/2使用不同的压缩算法来解决这个缺陷。其中，SPDY使用DEFLATE算法来压缩请求头，而HTTP/2使用HPACK算法来压缩请求头。

如下图对比数据，其中"Sent"表示请求头大小，"Received"表示响应头大小：

胜者：HTTP/2

测试2：响应消息(Response Message)的大小对比

服务器端的响应消息包括响应头和编码的响应内容。如下图对比数据，HTTP/2虽然可以将响应头压缩到最小，但并不保证能将整体的响应消息压缩到最小：

第一种，请求一个图片资源（可以看出HTTP/2有最好的压缩率）：

第二种，请求文本资源（可以看出SPDY有最好的压缩率）：

使用HTTP/2请求文本资源时资源更大的原因是因为HTTP/2压缩时会填充额外的字节到HTTP/2数据帧导致的。HTTP/2使用填充字节的原因：

Padding can be used to obscure the exact size of frame content, and is provided to mitigate specific attacks within HTTP. For example, attacks where compressed content includes both attacker-controlled plaintext and secret data (see for example, BREACH).

而填充行为之所以没有出现在图片资源中是因为图片资源本身就已经是压缩格式，保证不会被攻击者插入多余的文本。

胜者：SPDY

测试3：TCP连接数和SSL握手数对比

通过将每个域名下并发请求的个数从2调整为6，浏览器已经获取了很大的性能提升。这是通过消耗更多的TCP连接和SSL握手来实现更大的并发下载，而增加的并发可以减小阻塞的请求，更加有效地利用带宽。

SPDY，HTTP/2通过多路复用来支持TCP连接，SSL连接的复用，这样可以在一个连接上使用多个请求，减少TCP连接消耗，如下图，HttpWatch添加Connect列和SSL Handshake列来展示相关数据：

可以看出SPDY，HTTP/2只有在不同域名下的请求才需要创建新的TCP连接/SSL握手，而HTTPS在单个域名中的请求也需要创建多个TCP连接/SSL握手。

胜者：SPDY & HTTP/2

测试4：页面加载时间对比

胜者：HTTP/2

注：本例中页面负载时间HTTPS是最慢的，主要是由于

1. 缺少请求头/响应头压缩；
2. 需要额外的TCP连接/SSL握手；

在更复杂的场景下，SDPY，HTTP/2优势会更加明显。

结论

HTTP/2相对HTTPS，SDPY而言具有很大的性能优势，但是在响应消息中填充节节是一个需要平衡的关注点（保证性能和安全性）。

更多阅读

1. SPDY3.1中的请求/响应头
2. 超文本传输协议(HTTP)2 中英文对照版