Firefox 35發布新版本默認支持HTTP/2協議(草案14版本),針對該升級HttpWatch也發布了相應的更新,使其能夠在Firefox中支持HTTP/2,由于Google的web服務器現在能夠同時支持HTTP/2草案14版本和SPDY協議,使得HttpWatch能夠在同樣的Web頁面上對比HTTPS、SPDY和HTTP/2的性能。
整個性能測試包含4個場景,使用的軟件為Firefox和HttpWatch,測試網頁為Google UK首頁,比較的協議包括原生HTTPS、SPDY/3.1和HTTP/2協議,同時每一個測試都是在沒有瀏覽器緩存的Firefox實例上執行的,雖然這些測試非常簡單,頁面也不復雜,但是這并不影響三種不同協議之間重大差異的比較。
測試#1——請求和響應頭的大小
雖然大部分網站都已經在下載文本內容的時候使用壓縮提升性能,但是HTTP/1.1并不支持HTTP頭壓縮,為此SPDY和HTTP/2應運而生, SPDY使用了通用的DEFLATE算法,而HTTP/2則使用了專門為壓縮頭信息而設計的HPACK算法。
第一個測試通過一個沒有內容的請求生成的頭信息的大小來查看三種協議的不同:
其中,“Sent”列表示請求頭的大小,“Received”列表示響應頭的大小,結果顯示,使用HPACK算法的HTTP/2協議頭信息最小。
測試#2——響應消息的大小
Web服務器的響應由響應頭和編碼的響應內容兩部分組成。對于圖片的請求,測試結果如下:
對于文本資源的請求,結果如下:
結果顯示,對于圖片HTTP/2協議的請求和響應信息都最小,而對于文本資源,雖然HTTP/2的請求信息依然最小,但是響應信息卻比SPDY協議稍大一點。究其原因,這可能是由添加到HTTP/2數據幀中的可選內邊距字節造成的,而圖片資源并不會使用內邊距。
測試#3——TCP連接數和頁面加載時的SSL握手請求數
HTTP/1.1通過增加到每個主機的最大連接數來提高性能,而SPDY和HTTP/2則是通過使用多路復用技術在一個單獨的TCP和SSL連接上支持并發,通過在一個連接上一次性發送多個請求來發送或接收數據。該場景的測試結果如下:
[page]SPDY結果
HTTP/2結果
HTTPS結果
結果顯示,SPDY和HTTP/2通過多路復用技術降低了頁面下載時的連接數,而原生的HTTPS協議則需要創建更多的連接。
測試#4——頁面加載時間
頁面加載時間是一個比較重要的性能指標,該測試使用了HttpWatch中的“頁面加載”事件來查看每種協議所需的時間,結果如下:
結果顯示,由于不支持頭信息壓縮,并且缺少所需的額外TCP連接和SSL握手,原生HTTPS所需的時間最長,如果頁面更復雜,那么差距會更明顯。同時,雖然HTTP/2的響應消息比SPDY大,但是加載時間要比SPDY短。