HTTPS中S帶來的性能損失

HTTPS中S帶來的性能損失

來自專欄 Tech Builds

本文編譯自David Naylor et all, The Cost of the 「S」 in HTTPS, CONEXT 2014

動機

隨著Lets Encrypt等服務的出現，使用HTTPS的成本已經十分低廉了。也有越來越多的網站開始使用HTTPS了，在YouTube上，史無前例的有超過50%的流量使用HTTPS。HTTPS中的S是Security的含義，而我們知道，安全總是伴隨著成本的上升，HTTPS也不例外。HTTP上額外的安全性會帶來那些成本上的提高呢？出於這個目的，本文研究了過去三年（即2011-2014年）間的HTTPS網路流量的變化，以及TLS(Transport Layer Security)對分別在有線網、Wi-Fi和3G連接的情況下對網路延遲、數據消耗、電池消耗的影響。我們將首先介紹本文的結論，之後分別介紹HTTPS的使用趨勢、對網頁載入時間的影響、對數據流量的影響、對電池生命的影響，對增值服務的影響。

結論

在三個截獲自普通人家中的網路和無線網路的數據集以及自己進行的實驗上，得出了以下的三個結論：

1.儘管存在著潛在的部署成本，HTTPS的使用還是很快的增長。

2.HTTPS存在一些較為明顯的延時消耗影響。

3.HTTPS的數據開銷是有限的

4.對於一些大文件，HTTPS帶來了顯著的電池消耗。

HTTPS使用趨勢

(注意，由於這是一篇2014年的文章，作者提及的使用成本可能不適用。在最近幾年，隨著Lets Encrypt等免費的簽發機構，大大降低了HTTPS的上車成本，擴大了其使用。)

通常來說，使用HTTPS都會增加基礎設施的成本（如計算成本、內存、數據開銷等），更主要的則是證書的成本（有的高達1999美刀一年），因此大家會想僅在必要的時候使用HTTPS。為了測試HTTPS的使用趨勢，我們監測了歐洲主要的一個ISP的25,000個居民家裡的網路，在監測點使用一個實現了對HTTP和HTTPS進行分類的TStat程序。對於TLS的連接，TStat解析如下的內容：

1.SNI(Server Name Indication),即欲連接的主機名。

2.伺服器證書的所附帶的SCN(Subject Common Name)

上圖展示了從2012年4月到2014年9月的HTTPS流量變化，HTTPS流量的增長是驚人的：在兩年間就增長了超過2倍。到了2014年的9月，44.3%的網路連接都已經使用了HTTPS。

對網頁載入時間的影響

我們都知道使用HTTPS協議進行通信的過程中會對數據進行加密和解密，所以不難推測對於相同內容的頁面在分別使用HTTP和HTTPS時的載入時間會有所不同，因此對於這一點，作者進行了驗證實驗。

作者分別讓測試的客戶端處在用3G路由器連接的無線網路環境和通過光纖連接的有線網路中，進行兩次實驗。每次實驗，測試機均在PhantomJS瀏覽器中首先使用HTTP協議來載入在Alexa網站上訪問量為前500的網站20次，之後使用HTTPS協議做相同的操作。實驗結果如下：

由上圖可以明顯看出，在3G環境下，90%的網站HTTPS的額外延遲大於500ms.在有線網路下的延遲小一點，但是仍然有40%的使用HTTPS的網站需要額外載入多於500ms.

通過分別使用HTTP協議和HTTPS協議載入相同網頁的對比實驗得出，相比於使用HTTP協議來說，使用HTTPS的網站載入時間明顯更長。

那麼是什麼原因導致HTTPS的載入時間更長呢？作者通過收集每個頁面的HTTP請求/響應信息（HAR）發現如下圖，雖然相比於HTTP，40%的網站載入HTTPS時，建立更少的TCP連接；但是，接近一半的網站在建立TCP連接時，每一次握手卻需要耗費更多的時間，這部分時間主要是由TLS引起的協商開銷。因此，HTTPS的載入時間反而更長。

所以不難發現，HTTPS的開銷與TLS握手的延遲帶來的開銷息息相關，但是此時還不能排除使用HTTPS協議的網頁載入時間長短是否和網路狀況的好壞有關。為了更好地了解其中的原因，作者修改了Tstat，並讓Tstat從2014年4月3日由RES-ISP收集的一小時pcap蹤跡數據，約有100萬個TLS流量中提取（i）持續時間和（ii）每次TLS握手的位元組數。作者選取了美國幾個具有代表性的網站進行實驗。通常我們認為，網路延遲的長短與客戶端和伺服器的之間的遠近有關，因此作者引入外部的RTT來表示上述距離，當RTT大於100ms的時候表示伺服器已經在歐洲之外了。然而在實驗中發現，即使是客戶端與伺服器的距離很近，TLS握手的持續時間仍然很長（如下圖左邊），以TLS協商延遲最小的Google為例（如下圖中間），大約90%的TLS握手持續時間在300ms以內，10%超過300ms。由此可以看出一個完整的TLS握手請求時間至少是RTT的2倍以上，由此不難發現TLS握手請求為伺服器帶來的巨大額外開銷。一般來時，可能由於客戶或伺服器開銷，或網路擁塞，或緩慢的OCSP認證，5%的請求一般都會經過一個時長是RTT的10倍的握手。

更近一步看，可以發現有4％的客戶體驗TLS握手持續時間最短的一個連接超過300毫秒（如下圖中間）。 對於這種連接，50％（75％）具有51ms（97ms）的內部RTT（即有利位置和最終用戶設備之間的RTT），較不保守的閾值（例如1秒）也是如此。這表明即使是具有良好網路連接性的客戶端仍然遭受TLS握手開銷的困擾。 TLS快速協商有助於減少握手延遲，但是我們發現只有30％的連接被使用。 我們推測這是一個下限，但不幸的是，根據現有數據，我們無法評估從更廣泛採用TLS快速協商獲得的可實現的上限。

對數據流量使用的影響

HTTPS的使用對數據流量也可能會有一定的影響，這是由於：

1. TLS握手包的數據
2. 我們往往無法優化這一過程中的緩存和進行壓縮的代理

所以我們可以將其分為兩部分討論，分別來研究。

TLS握手包的開銷

TLS握手包開銷的影響，很大程度上取決於整體的數據包數量：很明顯，如果整體的數據包數量越大，那相對來說，協商過程中的開銷所佔的比重就會越低。

上圖展示了各大網站中TLS握手包所佔的量。我們發現，大多數TLS的連接都處於非重度使用的狀態，事實上，這些連接中有一半都是TLS握手包佔總的包大小的42%以上。當然，也有一些服務是非常高效率的，他們重度使用TLS的連接，例如Amazon S3，這相對地減少了在協商階段的消耗。也有一些服務是會在真正發送數據時選擇使用「預打開」連接，這掩蓋了一些對延遲的影響。因為在這種情況下，如果連接沒有被真正的使用，TLS的開銷就會佔到總開銷的100%。

不過總的來說，TLS的開銷大約佔到總開銷的5%。

網路中的代理

HTTPS會阻止一些在網路中的內容優化措施，例如一些壓縮和緩存的代理。為了衡量這種無法使用代理所帶來的影響，作者分析了兩種生產級別的移動環境上的HTTP代理Transp-Proxy和OptIn-Proxy，Transp-Proxy是一個服務了兩千萬歐洲用戶的、廣泛應用於歐洲大型運營商的的透明代理。OptIn-Proxy則是一個每日服務兩千多用戶的、同樣廣泛應用於歐洲國家的顯式代理。

作者分別討論了HTTPS對緩存和壓縮兩方面的影響。

對於緩存來說，在過去兩年間，Transp-Proxy的命中率約有14.9%。對於一個單一服務300萬訂閱者的的Transp-Proxy實例來說，這意味著每天可以節省高達2TB的流量。實際上，這一命中率已經是下降的結果了。在2012年其命中率可以達到16.8%，到了2014年就只有13.2%了。OptIn-Proxy的結果與Transp-Proxy的結果類似。

但作者也同時提到，這一命中率的下降是多種因素造成的，亦有可能是個性化的內容快速產生，使得命中率下降，也有可能是HTTPS的廣泛使用使得命中率下降。但無論如何，代理節省的流量還是十分可觀的，但倘若全部切換到HTTPS，就沒有辦法使用代理節省流量了。（不知道3年後的今天，有沒有辦法代理HTTPS的流量？）

第二方面則是壓縮，在將內容返回用戶之前，網路代理往往會做一次無損的壓縮（例如使用gzip），甚至會重新編碼圖像或是調整圖像的大小。這個功能在網路總流量有限時是非常有用的（想一想瀏覽器的限流模式，是不是在流量只有30M的時候非常有用）。Transp-Proxy的日誌顯示其壓縮比例高達28.5%。對於一些重度用戶，這一壓縮可能是十分關鍵的，每個月可能都會省下數百MB的流量。

總的來說，普通用戶可能沒有關注到HTTPS中緩存和壓縮的消失帶來的流量增多，但對於運營商來說，這就是一個比較明顯的趨勢了。

對電池使用時間的影響

HTTPS的使用對電池的使用時間有潛在的負面影響，這是由於：

1. 加解密操作會使用額外的CPU時間
2. 由於需要更長的下載時間，因此會有天線方面的消耗

作者將實驗分成了兩部分，合成的內容和真實的內容。

合成內容

作者使用了一部帶電錶的Galaxy S II，將亮度調至最低，每200微秒測量一次電力消耗。用這部手機通過3G及Wi-Fi下載從1KB-1MB的合成的內容。每個內容都會分別使用HTTP和HTTPS下載100次。值得注意的是，作者在Android上編譯了curl，以避免無關的影響。

上圖展示了在不同情況下完成一次下載的平均時間和電量的消耗情況。很明顯，電池電量和下載時間是相關聯的。而且，對於一些大文件，在Wi-Fi情況下的開銷是比較明顯的（相對於3G情況下），但造成這一點的原因尚不明確。總的來說，除去下載時間不同之外，HTTPS中的加密對電池的影響是幾乎沒有的。

真實內容

作者首先在自己的伺服器上鏡像了一個CNN的首頁，並且使用Android上的Chrome來分別使用HTTP和HTTPS下載50次。結果如圖：

可以看出，雖然有一定的開銷，但並沒有十分顯著。

在第二個實驗中，作者播放了5-12分鐘的YouTube視頻。但是由於在手機上的客戶端及網站沒有辦法播放非HTTPS的視頻，所以作者強制使用桌面版本的YouTube網站來使用HTTP。經過作者的測試，在Wi-Fi情況下，HTTP和HTTPS幾乎沒有差別；但在3G情況下，網路中的代理極大地影響了HTTP的結果，有兩個視頻使用HTTP的電池電量消耗比HTTPS的結果少了將近25%，另外兩個視頻也節省了10%-20%。

造成這一結果的是代理的兩個行為：

1.一方面，代理限制了下載速率以減少網路擁塞（這和我們下載時選擇「上網優先」是類似的），同時如果用戶取消了，不再看這個視頻了，這樣做也可以減少對網路流量的消耗（想一想，有多少次我們點開了一個視頻，然後又關掉它）。如果不使用代理的話，整個視頻會在進入時迅速被下載完，之後網路設備就處於休眠狀態。而使用代理的話，下載速度是較慢且穩定的，在整個視頻播放過程中會即放即播，因此網路設備沒有休息的機會，這會導致更多的電量消耗。

2.另一方面，代理會將JavaScript插入頁面中，它會改寫發送到YouTube伺服器上的URL，以獲取更適應移動設備的編碼和視頻質量。對於第二個和第四個視頻，最初獲取了webm格式的視頻，而這兩種視頻格式在我們的移動設備上都不支持硬解碼，因此代理將其更改為了mp4格式的視頻。硬解碼帶來的優勢抵消了部分網路設備的電量消耗。

在真實情況下的實驗，控制變數的難度是相當大的。因此作者也提到，對這些數字應抱有懷疑和審慎的態度(should be taken with a grain of salt)。如果試圖嚴謹地控制變數，我們應自行建立一個HTTPS和一個HTTP的視頻站點，視頻源使用同一個視頻的不同格式來進行這個實驗。

總的來說，這個實驗還是告訴我們：

1. HTTPS中加密的操作對電池的消耗的影響並不顯著，但代理可能會極大地影響電池的生命。
2. 運營商應仔細地考慮其中間件的設計，社區也是時候考慮是不是要全盤切換到HTTPS了。

總結和看法

魚和熊掌不可得兼

安全和效率往往是很難同時兼顧的兩面。儘管近年來的設備和技術更新已經大大降低了使用HTTPS的成本，但HTTPS的性能消耗依然是值得我們注意的一個問題。與此同時，HTTP 2.0也開始逐漸走入視野，除去安全性的考量，它的性能表現如何也是值得我們多加關注的一個話題。

但不得不說的是，在國內的網路環境下，甚至存在一些運營商劫持的問題下，網站使用HTTPS來保護用戶使用過程的安全還是十分有必要的。我們也希望可信代理可以成為互聯網的一個非常重要的組成部分。

推薦閱讀：