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

　　這幾天手機不斷被聯通劫持，用知乎日報都會被插入聯通的垃圾廣告，更別說在微信中訪問第三方網站了。於是關注了一下防止網站被運營商劫持的技術，這裡推薦Fenng之前發的文章，在流氓無下限的運營商的手段下面，我們能做的其實並不多。而HTTPS和SPDY其實是更好的技術，不僅能保證不被運營商劫持，更能保護使用者的資料安全。正好看到這篇關於HTTPS、SPDY和即將變為現實的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中啟用/禁用下面的功能來切換不同的協議：

　　每次測試都是基於空快取的。所以即便這個測試很簡單並且只基於一個網站，但其結果還是具有代表性的。

　　測試#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看起來能提供明顯的效能優勢，。然而，響應資訊中填充的使用會是一個潛在的關於效能和安全的權衡點。

　　英文原文：A Simple Performance Comparison of HTTPS, SPDY and HTTP/2 翻譯：qianduan.net