Firefox 35發(fā)布新版本默認支持HTTP/2協(xié)議(草案14版本)，針對該升級HttpWatch也發(fā)布了相應的更新，使其能夠在Firefox中支持HTTP/2，由于Google的web服務器現(xiàn)在能夠同時支持HTTP/2草案14版本和SPDY協(xié)議，使得HttpWatch能夠在同樣的Web頁面上對比HTTPS、SPDY和HTTP/2的性能。

[[127353]]

整個性能測試包含4個場景，使用的軟件為Firefox和HttpWatch，測試網(wǎng)頁為Google UK首頁，比較的協(xié)議包括原生HTTPS、SPDY/3.1和HTTP/2協(xié)議，同時每一個測試都是在沒有瀏覽器緩存的Firefox實例上執(zhí)行的，雖然這些測試非常簡單，頁面也不復雜，但是這并不影響三種不同協(xié)議之間重大差異的比較。

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

雖然大部分網(wǎng)站都已經(jīng)在下載文本內(nèi)容的時候使用壓縮提升性能，但是HTTP/1.1并不支持HTTP頭壓縮，為此SPDY和HTTP/2應運而生， SPDY使用了通用的DEFLATE算法，而HTTP/2則使用了專門為壓縮頭信息而設計的HPACK算法。

***個測試通過一個沒有內(nèi)容的請求生成的頭信息的大小來查看三種協(xié)議的不同：

其中，“Sent”列表示請求頭的大小，“Received”列表示響應頭的大小，結果顯示，使用HPACK算法的HTTP/2協(xié)議頭信息最小。

測試#2——響應消息的大小

Web服務器的響應由響應頭和編碼的響應內(nèi)容兩部分組成。對于圖片的請求，測試結果如下：

對于文本資源的請求，結果如下：

結果顯示，對于圖片HTTP/2協(xié)議的請求和響應信息都最小，而對于文本資源，雖然HTTP/2的請求信息依然最小，但是響應信息卻比SPDY協(xié)議稍大一點。究其原因，這可能是由添加到HTTP/2數(shù)據(jù)幀中的可選內(nèi)邊距字節(jié)造成的，而圖片資源并不會使用內(nèi)邊距。

測試#3——TCP連接數(shù)和頁面加載時的SSL握手請求數(shù)

HTTP/1.1通過增加到每個主機的***連接數(shù)來提高性能，而SPDY和HTTP/2則是通過使用多路復用技術在一個單獨的TCP和SSL連接上支持并發(fā)，通過在一個連接上一次性發(fā)送多個請求來發(fā)送或接收數(shù)據(jù)。該場景的測試結果如下：

#p#

SPDY結果

HTTP/2結果

HTTPS結果

結果顯示，SPDY和HTTP/2通過多路復用技術降低了頁面下載時的連接數(shù)，而原生的HTTPS協(xié)議則需要創(chuàng)建更多的連接。

測試#4——頁面加載時間

頁面加載時間是一個比較重要的性能指標，該測試使用了HttpWatch中的“頁面加載”事件來查看每種協(xié)議所需的時間，結果如下：

結果顯示，由于不支持頭信息壓縮，并且缺少所需的額外TCP連接和SSL握手，原生HTTPS所需的時間最長，如果頁面更復雜，那么差距會更明顯。同時，雖然HTTP/2的響應消息比SPDY大，但是加載時間要比SPDY短。