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英國首頁，使用了三種協議：
通過在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看起來能提供明顯的性能優勢，。然而，響應信息中填充的使用會是一個潛在的關於性能和安全的權衡點。
原文：http://www.qianduan.net/a-simple-performance-comparison-of-https-spdy-and-http2/
