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

中文原文： HTTPS, SPDY和 HTTP/2性能的簡單對比

 <p> 整理自： <a href="/misc/goto?guid=4958862088745377445">A Simple Performance Comparison of HTTPS, SPDY and HTTP/2</a> </p>

 <p> 請尊重版權，轉載請注明來源，謝謝！ </p>

</div>

<p> 這幾天手機不斷被聯通劫持，用知乎日報都會被插入聯通的垃圾廣告，更別說在微信中訪問第三方網站了。于是關注了一下防止網站被運營商劫持的技術，這里推薦 <a href="/misc/goto?guid=4958862088846165052" target="_blank">Fenng之前發的文章</a> ，在 <a href="/misc/goto?guid=4958862088937648173" target="_blank">流氓無下限的運營商的手段</a> 下面，我們能做的其實并不多。而HTTPS和SPDY其實是更好的技術，不僅能保證不被運營商劫持，更能保護用戶的數據安全。正好看到這篇關于HTTPS、SPDY和即將變為現實的HTTP/2的文章，覺得比較有價值，就順手翻譯了過來。 </p>

<p> Firefox 35這周發布了，成為第一個默認開啟支持 <a href="/misc/goto?guid=4958862089017240216">HTTP/2協議</a> 的瀏覽器。Chrome也支持了，只是以SPDY 4的名義，并且要自己在about://flags里面手動開啟。 </p>

<p> 不過HTTP/2規范還沒有最終完成，所以Firefox實際上支持的是 <a href="/misc/goto?guid=4958862089125831941">HTTP/2第14版草案</a> ，這個版本的草案離最終發布可能不會有大改動了。Google現在在其服務器上同時支持了HTTP/2的第14草案和 <a href="/misc/goto?guid=4958823781746290775">SPDY協議</a> ，這就給我們了一個基于同一個網頁來對比HTTPS, SPDY和 HTTP/2的性能的機會。 </p>

<p> <a href="/misc/goto?guid=4958862089248231263">HttpWatch</a> 也更新了，從而可以在Firefox里面監控HTTP/2了，它現在有一列專門顯示每個請求所使用的協議了： </p>

<p> <img src="https://simg.open-open.com/show/51cc05d400c678100b82f95c69f5d1fd.png" alt="HTTPS, SPDY和 HTTP/2性能的簡單對比" width="603" height="187" /> </p>

<h2> 性能對比 </h2>

<p> 這組性能測試是使用Firefox和HttpWatch，測試頁面為 <a href="/misc/goto?guid=4958862089343984628">Google英國首頁</a> ，使用了三種協議： </p>

<ul> 
 <li> 原始的HTTPS </li>

 <li> SPDY/3.1 </li>

 <li> HTTP/2 </li>

</ul>

<p> 通過在Firefox的about:config中啟用/禁用下面的功能來切換不同的協議： </p>

<p> <img src="https://simg.open-open.com/show/a1ed4fa6f4459a7643fc8e3d01aa0db3.png" alt="HTTPS, SPDY和 HTTP/2性能的簡單對比" width="464" height="322" /> </p>

<p> 每次測試都是基于空緩存的。所以即便這個測試很簡單并且只基于一個網站，但其結果還是具有代表性的。 </p>

<h3> 測試#1：請求和響應報頭的大小 </h3>

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

<p> SPDY使用普通的 <a href="/misc/goto?guid=4958862089432665316">DEFLATE</a> 算法而HTTP/2使用專門為壓縮報頭而設計的 <a href="/misc/goto?guid=4958862089522109045">HPACK算法</a> 。它使用預定義的token、動態表以及哈夫曼壓縮。 </p>

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

<p> <img src="https://simg.open-open.com/show/7ae7fb469b670400a86156e9a372e7f5.png" alt="HTTPS, SPDY和 HTTP/2性能的簡單對比" width="603" height="60" /> </p>

<p> <img src="https://simg.open-open.com/show/2740c5b255eef4b3603626538d9ac5d4.png" alt="HTTPS, SPDY和 HTTP/2性能的簡單對比" width="603" height="60" /> </p>

<p> <img src="https://simg.open-open.com/show/abed5d04e2c654e139cde276715c87be.png" alt="HTTPS, SPDY和 HTTP/2性能的簡單對比" width="603" height="60" /> </p>

<h4> 勝出: HTTP/2 </h4>

<p> HTTP/2的報頭大小還是很明顯的，看來HPACK確實不錯。 </p>

<h3> 測試#2：響應信息大小 </h3>

<p> 響應信息包括響應報頭和編碼過的響應內容。HTTP/2提供了最小的報頭，那么它會否給到最小的響應信息？ </p>

<p> 圖片資源是這樣的： </p>

<p> <img src="https://simg.open-open.com/show/af15a0656de4d8b4a61aa3158d23f4c0.png" alt="HTTPS, SPDY和 HTTP/2性能的簡單對比" width="603" height="60" /> <img src="https://simg.open-open.com/show/2a537c7086045920f70b4bb9598068b1.png" alt="HTTPS, SPDY和 HTTP/2性能的簡單對比" width="603" height="60" /> <img src="https://simg.open-open.com/show/3e1a5db0be023ed253df390855565544.png" alt="HTTPS, SPDY和 HTTP/2性能的簡單對比" width="603" height="60" /> </p>

<p> 但是，對于文本內容SPDY卻有著更小的響應信息，盡管它的報頭比HTTP/2要大： </p>

<p> <img src="https://simg.open-open.com/show/5784e2941b351797c03001262f71a618.png" alt="HTTPS, SPDY和 HTTP/2性能的簡單對比" width="603" height="60" /> <img src="https://simg.open-open.com/show/f7b3e32f6a8c731882126c1eefdb5e78.png" alt="HTTPS, SPDY和 HTTP/2性能的簡單對比" width="603" height="60" /> <img src="https://simg.open-open.com/show/22c35f46fc0220204e5bb4137e7589a7.png" alt="HTTPS, SPDY和 HTTP/2性能的簡單對比" width="603" height="60" /> </p>

<p> 原因在于可被添加到 <a href="/misc/goto?guid=4958862089622377183">HTTP/2數據幀</a> 的可選填充字節。HttpWatch現在并不能顯示填充，但是在debug log里面可以看到Google服務器向文本內容的數據幀中添加了填充。 <a href="/misc/goto?guid=4958862089709923980">HTTP/2規范給到的使用填充的理由是</a> ： </p>

<p> 填充可以用來混淆幀內容的實際大小，而且減少HTTP中的特殊攻擊。例如，壓縮的內容包含攻擊者控制的明文和秘密數據的攻擊(見 [ <a href="/misc/goto?guid=4958862089800611985">BREACH</a> ]). </p>

<p> 填充不會用于圖片文件，因為它已經是壓縮過的格式了，并不包含攻擊者控制的純文本。 </p>

<h4> 勝出：SPDY </h4>

<p> 在Google服務器上看到的較大的響應體是因為在數據幀中使用了填充。盡管，HTTP/2產生了比SPDY大的響應信息，它的加密連接可能會更安全。這可能會是安全和性能權衡折衷的一個地方。 </p>

<h3> 測試#3：TCP連接數和SSL握手請求時間 </h3>

<p> 通過將每個域名的最大并發連接數從2個提升到6個甚至更多，瀏覽器在HTTP/1.1實現了明顯的性能提升。增加并發使得網絡帶寬可以更有效的利用，因為它減少了 <a href="/misc/goto?guid=4958862089891598059">請求塊</a> 。 </p>

<p> SPDY和HTTP/2通過復用單個連接來允許多個請求一次發送和接收數據來支持在一個TCP和SSL連接中的并發。 </p>

<p> 增加了‘Connect’和‘SSL Handshake’時間后，SPDY： </p>

<p> <img src="https://simg.open-open.com/show/434da4ee6a921208b1ac7ff2b327cd37.png" alt="HTTPS, SPDY和 HTTP/2性能的簡單對比" width="603" height="379" /> </p>

<p> HTTP/2: </p>

<p> <img src="https://simg.open-open.com/show/48706e925211bf3e7bc45563cc1cc349.png" alt="HTTPS, SPDY和 HTTP/2性能的簡單對比" width="603" height="379" /> </p>

<p> 它們只為不同的域名創建連接，而原來的HTTPS可以為一個域名來創建多個連接來提高并發： </p>

<p> <img src="https://simg.open-open.com/show/ba4675d072f96f52aa53ab6e18fbf6f9.png" alt="HTTPS, SPDY和 HTTP/2性能的簡單對比" width="603" height="384" /> </p>

<h4> 共同勝出: SPDY & HTTP/2 </h4>

<p> 在SPDY和HTTP/2中增加的復用支持減少了下載頁面時不得不設置的網絡連接的數量。作為附加好處，當HTTP/2使用的更加廣泛時，網絡服務器不用再不得不維護太多的活動TCP連接了。 </p>

<h3> 測試#4：頁面加載時間 </h3>

<p> HttpWatch中的‘Page Load’時間顯示頁面被完全下載并可用的時間。大部分情況下，這是合理的網頁速度的衡量數據。 </p>

<p> 下面的截圖顯示了三種協議的頁面加載時間： </p>

<p> <img src="https://simg.open-open.com/show/e084af5c3d78d4ba14a1ab7efcd48820.png" alt="HTTPS, SPDY和 HTTP/2性能的簡單對比" width="603" height="332" /> </p>

<p> <img src="https://simg.open-open.com/show/1bdbe239ec6711923ecea261ba480943.png" alt="HTTPS, SPDY和 HTTP/2性能的簡單對比" width="603" height="332" /> </p>

<p> <img src="https://simg.open-open.com/show/f9933909c09b22c80c3a31d21c0df5a9.png" alt="HTTPS, SPDY和 HTTP/2性能的簡單對比" width="603" height="332" /> </p>

<h4> 勝出：HTTP/2 </h4>

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

<p> 我們也發現HTTP/2通常比SPDY要快，盡管它的響應信息通常更大。這個優勢可能是因為HPACK壓縮減少的更小的GET請求信息。我們的網絡連接，和許多人一樣，是非對稱的——網絡上傳速度比下載速度小很多。這意味著任何節省的上傳數據比節省的等量的下載數據 <a href="/misc/goto?guid=4958862089985562602">更有價值</a> 。 </p>

<h2> 結論 </h2>

<p> HTTP/2看起來能提供明顯的性能優勢，。然而，響應信息中填充的使用會是一個潛在的關于性能和安全的權衡點。 </p>

</div>

</div>