參考資料

• EMC: 網(wǎng)絡(luò)基本功系列

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

Firefox 35 這周發(fā)布了，成為第一個默認(rèn)開啟支持 HTTP/2 協(xié)議的瀏覽器。Chrome 也支持了，只是以 SPDY 4 的名義，并且要自己在 about://flags 里面手動開啟。

不過 HTTP/2 規(guī)范還沒有最終完成，所以 Firefox 實際上支持的是 HTTP/2 第14版草案，這個版本的草案離最終發(fā)布可能不會有大改動了。Google 現(xiàn)在在其服務(wù)器上同時支持了 HTTP/2 的第14草案和 SPDY 協(xié)議，這就給我們了一個基于同一個網(wǎng)頁來對比 HTTPS, SPDY和 HTTP/2 的性能的機會。

HttpWatch 也更新了，從而可以在 Firefox 里面監(jiān)控 HTTP/2 了，它現(xiàn)在有一列專門顯示每個請求所使用的協(xié)議了：

性能對比

這組性能測試是使用 Firefox 和 HttpWatch，測試頁面為 Google 英國首頁，使用了三種協(xié)議:

• 原始的 HTTPS
• SPDY/3.1
• HTTP/2 每次測試都是基于空緩存的。所以即便這個測試很簡單并且只基于一個網(wǎng)站，但其結(jié)果還是具有代表性的。

測試#1：請求和響應(yīng)報頭的大小

大部分網(wǎng)站在下載文本內(nèi)容的時候已經(jīng)啟用了壓縮(Gzip)，因為它可以提供很明顯的性能優(yōu)勢。但是很不幸，HTTP/1.1 不支持壓縮每個請求和相應(yīng)的 HTTP 報頭。SPDY 和后來的 HTTP/2 旨在使用不同的壓縮類型來彌補這個短板。

SPDY 使用普通的 DEFLATE 算法而 HTTP/2 使用專門為壓縮報頭而設(shè)計的 HPACK 算法。它使用預(yù)定義的 token、動態(tài)表以及哈夫曼壓縮。

從一個空請求也可以看到生成的報頭大小的不同。在 Google 英國首頁有返回空內(nèi)容的信標(biāo)請求(204返回碼)。下面是 HttpWatch 的截圖，‘Sent’列顯示請求報頭的大小，‘Received’列顯示響應(yīng)報頭的大小：

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

測試#2：響應(yīng)信息大小

響應(yīng)信息包括響應(yīng)報頭和編碼過的響應(yīng)內(nèi)容。HTTP/2 提供了最小的報頭，那么它會否給到最小的響應(yīng)信息？

原因在于可被添加到 HTTP/2 數(shù)據(jù)幀的可選填充字節(jié)。HttpWatch 現(xiàn)在并不能顯示填充，但是在 debug log 里面可以看到 Google 服務(wù)器向文本內(nèi)容的數(shù)據(jù)幀中添加了填充。HTTP/2 規(guī)范給到的使用填充的理由是： 填充可以用來混淆幀內(nèi)容的實際大小，而且減少 HTTP 中的特殊攻擊。例如，壓縮的內(nèi)容包含攻擊者控制的明文和秘密數(shù)據(jù)的攻擊(見 [BREACH]).

填充不會用于圖片文件，因為它已經(jīng)是壓縮過的格式了，并不包含攻擊者控制的純文本。

勝出: SPDY

在 Google 服務(wù)器上看到的較大的響應(yīng)體是因為在數(shù)據(jù)幀中使用了填充。盡管，HTTP/2 產(chǎn)生了比 SPDY 大的響應(yīng)信息，它的加密連接可能會更安全。這可能會是安全和性能權(quán)衡折衷的一個地方。

TCP 連接數(shù)和 SSL 握手請求時間

通過將每個域名的最大并發(fā)連接數(shù)從2個提升到6個甚至更多，瀏覽器在 HTTP/1.1 實現(xiàn)了明顯的性能提升。增加并發(fā)使得網(wǎng)絡(luò)帶寬可以更有效的利用，因為它減少了請求塊。

SPDY 和 HTTP/2 通過復(fù)用單個連接來允許多個請求一次發(fā)送和接收數(shù)據(jù)來支持在一個 TCP 和 SSL 連接中的并發(fā)。

增加了‘Connect’和‘SSL Handshake’時間后，SPDY：

勝出: 共同勝出: SPDY & HTTP/2.

在 SPDY 和 HTTP/2 中增加的復(fù)用支持減少了下載頁面時不得不設(shè)置的網(wǎng)絡(luò)連接的數(shù)量。作為附加好處，當(dāng) HTTP/2 使用的更加廣泛時，網(wǎng)絡(luò)服務(wù)器不用再不得不維護太多的活動 TCP 連接了。

測試#4：頁面加載時間

HttpWatch 中的‘Page Load’時間顯示頁面被完全下載并可用的時間。大部分情況下，這是合理的網(wǎng)頁速度的衡量數(shù)據(jù)。

勝出：HTTP/2

原生的 HTTPS 的加載時間最長的原因可能是缺乏報頭壓縮和額外的 TCP 連接和 SSL 握手請求。對于更復(fù)雜的頁面來說，SPDY 和 HTTP/2 的優(yōu)勢可能會更加明顯。

我們也發(fā)現(xiàn) HTTP/2 通常比 SPDY 要快，盡管它的響應(yīng)信息通常更大。這個優(yōu)勢可能是因為 HPACK 壓縮減少的更小的 GET 請求信息。我們的網(wǎng)絡(luò)連接，和許多人一樣，是非對稱的——網(wǎng)絡(luò)上傳速度比下載速度小很多。這意味著任何節(jié)省的上傳數(shù)據(jù)比節(jié)省的等量的下載數(shù)據(jù)更有價值。

結(jié)論

HTTP/2 看起來能提供明顯的性能優(yōu)勢，。然而，響應(yīng)信息中填充的使用會是一個潛在的關(guān)于性能和安全的權(quán)衡點。

參考資料

• A Simple Performance Comparison of HTTPS, SPDY and HTTP/2
• 如何防止網(wǎng)站被電信運營劫持彈廣告
• Hypertext Transfer Protocol version 2
• SPDY
• HttpWatch

HTTP 狀態(tài)碼

http://wiki.jikexueyuan.com/project/a-programmer-prepares/images/1.jpg" alt="" />