HTTPS, SPDY和 HTTP/2性能的簡單對比

中文原文：HTTPS, SPDY和 HTTP/2性能的簡單對比
整理自：A Simple Performance Comparison of HTTPS, SPDY and HTTP/2
請尊重版權，轉載請註明來源，謝謝！

Firefox 35這周發佈了，成爲第一個默認開啓支持HTTP/2協議的瀏覽器。Chrome也支持了，只是以SPDY 4的名義，而且要本身在about://flags裏面手動開啓。

不過HTTP/2規範尚未最終完成，因此Firefox實際上支持的是HTTP/2第14版草案，這個版本的草案離最終發佈可能不會有大改動了。Google如今在其服務器上同時支持了HTTP/2的第14草案和SPDY協議，這就給咱們了一個基於同一個網頁來對比HTTPS, SPDY和 HTTP/2的性能的機會。

HttpWatch 也更新了，從而能夠在Firefox裏面監控HTTP/2了，它如今有一列專門顯示每一個請求所使用的協議了：

性能對比

這組性能測試是使用Firefox和HttpWatch，測試頁面爲Google英國首頁，使用了三種協議：

• 原始的HTTPS

• SPDY/3.1

• HTTP/2

經過在Firefox的about:config中啓用/禁用下面的功能來切換不一樣的協議：

性能對比

這組性能測試是使用Firefox和HttpWatch，測試頁面爲Google英國首頁，使用了三種協議：

• 原始的HTTPS

• SPDY/3.1

• HTTP/2

經過在Firefox的about:config中啓用/禁用下面的功能來切換不一樣的協議：

性能對比

這組性能測試是使用Firefox和HttpWatch，測試頁面爲Google英國首頁，使用了三種協議：

• 原始的HTTPS

• SPDY/3.1

• HTTP/2

經過在Firefox的about:config中啓用/禁用下面的功能來切換不一樣的協議：

每次測試都是基於空緩存的。因此即使這個測試很簡單而且只基於一個網站，但其結果仍是具備表明性的。

測試#1：請求和響應報頭的大小

大部分網站在下載文本內容的時候已經啓用了壓縮(Gzip)，由於它能夠提供很明顯的性能優點。可是很不幸，HTTP/1.1不支持壓縮每一個請求和相應的HTTP報頭。SPDY和後來的HTTP/2旨在使用不一樣的壓縮類型來彌補這個短板。

SPDY使用普通的DEFLATE 算法而HTTP/2使用專門爲壓縮報頭而設計的HPACK算法。它使用預約義的token、動態表以及哈夫曼壓縮。

從一個空請求也能夠看到生成的報頭大小的不一樣。在Google英國首頁有返回空內容的信標請求(204返回碼)。下面是HttpWatch的截圖，‘Sent’列顯示請求報頭的大小，‘Received’列顯示響應報頭的大小：

勝出: HTTP/2

HTTP/2的報頭大小仍是很明顯的，看來HPACK確實不錯。

測試#2：響應信息大小

響應信息包括響應報頭和編碼過的響應內容。HTTP/2提供了最小的報頭，那麼它會否給到最小的響應信息？

圖片資源是這樣的：

可是，對於文本內容SPDY卻有着更小的響應信息，儘管它的報頭比HTTP/2要大：

緣由在於可被添加到HTTP/2數據幀的可選填充字節。HttpWatch如今並不能顯示填充，可是在debug log裏面能夠看到Google服務器向文本內容的數據幀中添加了填充。HTTP/2規範給到的使用填充的理由是：

填充能夠用來混淆幀內容的實際大小，並且減小HTTP中的特殊攻擊。例如，壓縮的內容包含攻擊者控制的明文和祕密數據的攻擊(見 [BREACH]).

填充不會用於圖片文件，由於它已是壓縮過的格式了，並不包含攻擊者控制的純文本。

勝出：SPDY

在Google服務器上看到的較大的響應體是由於在數據幀中使用了填充。儘管，HTTP/2產生了比SPDY大的響應信息，它的加密鏈接可能會更安全。這可能會是安全和性能權衡折衷的一個地方。

測試#3：TCP鏈接數和SSL握手請求時間

經過將每一個域名的最大併發鏈接數從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鏈接了。

測試#4：頁面加載時間

HttpWatch中的‘Page Load’時間顯示頁面被徹底下載並可用的時間。大部分狀況下，這是合理的網頁速度的衡量數據。

下面的截圖顯示了三種協議的頁面加載時間：

勝出：HTTP/2

原生的HTTPS的加載時間最長的緣由多是缺少報頭壓縮和額外的TCP鏈接和SSL握手請求。對於更復雜的頁面來講，SPDY和HTTP/2的優點可能會更加明顯。

咱們也發現HTTP/2一般比SPDY要快，儘管它的響應信息一般更大。這個優點多是由於HPACK壓縮減小的更小的GET請求信息。咱們的網絡鏈接，和許多人同樣，是非對稱的——網絡上傳速度比下載速度小不少。這意味着任何節省的上傳數據比節省的等量的下載數據更有價值。

結論

HTTP/2看起來能提供明顯的性能優點，。然而，響應信息中填充的使用會是一個潛在的關於性能和安全的權衡點。