扒一扒HTTPS網站的內幕

做者：王繼波
野狗科技運維總監，曾在360、TP-Link從事網絡運維相關工做，在網站性能優化、網絡協議研究上經驗豐富。
野狗官博：https://blog.wilddog.com/
野狗官網：https://www.wilddog.com/
公衆訂閱號：wilddogbaas

今年6月，維基媒體基金會發布公告，旗下全部網站將默認開啓HTTPS，這些網站中最爲人所知的固然是全球最大的在線百科-維基百科。而更早時候的3月，百度已經發布公告，百度全站默認開啓HTTPS。淘寶也默默作了全站HTTPS。

網站實現HTTPS，在國外已經很是普及，也是必然的趨勢。Google、Facebook、Twitter等巨頭公司早已經實現全站HTTPS，並且爲鼓勵全球網站的HTTPS實現，Google甚至調整了搜索引擎算法，讓採用HTTPS的網站在搜索中排名更靠前。可是在國內，HTTPS網站進展並很差，大部分的電商網站也僅僅是對帳戶登陸和交易作HTTPS，好比京東；不少網站甚至連登陸頁面也沒有實現HTTPS...這裏面有不少的緣由，好比現有架構改動的代價過大、CDN實現困難、對用戶隱私和安全的不重視等。

還有個重要緣由是擔憂網站實現HTTPS後，網站的用戶體驗和性能降低明顯。事實上，經過合理部署和優化，HTTPS網站的訪問速度和性能基本不會受到影響。

1、什麼是HTTPS網站？

在介紹HTTPS網站前，首先簡單介紹什麼是HTTPS。

HTTPS能夠理解爲HTTP+TLS，HTTP是互聯網中使用最爲普遍的協議，目前不部分的WEB應用和網站都是使用HTTP協議傳輸。主流版本是HTTP1.1，HTTP2.0還未正式普及，2.0由Google的SPDY協議演化而來，在性能上有明顯的提高。

TLS是傳輸層加密協議，是HTTPS安全的核心，其前身是SSL，主流版本有SSL3.0、TLS1.0、TLS1.一、TLS1.2。SSL3.0和TLS1.0因爲存在安全漏洞，已經不多被使用到。

那網站爲何要實現HTTPS？

一言概之，爲保護用戶隱私和網絡安全。經過數據加密、校驗數據完整性和身份認證三種機制來保障安全。

因爲本文的重點是HTTPS網站的性能加速，對於HTTPS通訊過程和加解密算法就不展開介紹了。

感興趣的同窗能夠Google之，基礎都是同樣的。

2、HTTPS網站的直觀瞭解

推薦一個在線版全球知名的HTTPS網站檢測工具-SSL Labs。Qualys SSL Labs同時也是很具備影響力的SSL安全和性能研究機構。在線檢測地址爲：https://www.ssllabs.com/ssltest/。

SSL Labs會對HTTPS網站的證書鏈、安全性、性能、協議細節進行全面檢測，檢測完畢後會進行打分，同時給出一份詳細的檢測報告和改進建議。

下面咱們對一些經常使用網站進行檢測。分別是12306購票頁面、淘寶首頁、百度首頁、維基百科首頁、WildDog首頁的檢測結果。

12306購票頁面

淘寶首頁

百度首頁

維基百科首頁

WildDog首頁

能夠看到，雖然都是HTTPS網站，可是差距就是那麼大...... 這裏要順便提下，12306真的很挫，百度和淘寶爲兼容一些低端版本的用戶，也是各類使用弱加密和協議。

3、提升HTTPS網站性能和訪問速度

若是你認爲網站加上TLS證書，就是HTTPS網站了，那你就跟12306犯了一樣的錯誤......

首先，網站在加上TLS證書時，爲何會變慢？這主要又兩方面形成：

1. HTTPS比HTTP在通訊時會產生更多的通訊過程，隨之RTT時間就會增長；

2. HTTPS通訊過程的非對稱和對稱加解密計算會產生更多的服務器性能和時間上的消耗。

可是，每一個HTTPS網站其實都有着巨大的優化空間。下面咱們結合WildDog網站，來看看QPS值從30000到80000，加載時延從800ms到300ms，這中間的每一個優化點是怎樣的。

HSTS

HTTPS網站一般的作法是對HTTP的訪問在服務器端作302跳轉，跳轉到HTTPS。但這個302跳轉存在兩個問題：

1. 使用不安全的HTTP協議進行通訊；

2. 增長一個Round-Trip Time。

而HSTS是HTTP Strict Transport Security的縮寫，服務器端配置支持HSTS後，會在給瀏覽器返回的HTTP Header中攜帶HSTS字段，瀏覽器在獲取到該信息後，在接下來的一段時間內，對該網站的全部HTTP訪問，瀏覽器都將請求在內部作307跳轉到HTTPS，而無需任何網絡過程。

Session Resume

Session Resume即會話複用，這提高HTTPS網站性能最基礎也是最有效的方法。

在HTTPS握手階段，對服務器性能消耗最爲嚴重的是非對稱密鑰交換計算，而Session Resume經過對已經創建TLS會話的合理複用，節省非對稱密鑰交換計算次數，可大幅提升服務器的TLS性能。

TLS協議提供兩種實現機制Session Resume，分別是Session cache和Session ticket。

Session Cache

Session Cache的原理是使用Session ID查詢服務器上的session cache，若是命中，則直接使用緩存信息。但Session Cache有個明顯的缺點，它不支持分佈式緩存，只支持單機進程間的共享緩存。這對於多個接入節點的架構很難適用。

Session ticket

Session ticket的原理是服務器降session信息加密成ticket發送給瀏覽器，瀏覽器後續進行TLS握手時，會發送ticket，若是服務器可以解密和處理該ticket，則能夠複用session。

Session ticket能夠很好的解決分佈式問題，但Session ticket的支持率還不是很高，並且須要考慮服務器上key的安全性方案。

OCSP Stapling

在HTTPS通訊過程時，瀏覽器會去驗證服務器端下發的證書鏈是否已經被撤銷。驗證的方法有兩種：CRL和OCSP。

CRL是證書撤銷列表，CA機構會維護並按期更新CRL列表，但這個機制存在不足：

1.CRL列表只會愈來愈大；

2.若是瀏覽器更新不及時，會形成誤判。

OCSP是實時證書在線驗證協議，是對CRL機制的彌補，經過OCSP瀏覽器能夠實時的向CA機構驗證證書。但OCSP一樣存在不足：

1. 對CA機構要求太高，要求實時全球高可用；

2. 客戶端的訪問隱私會在CA機構被泄露；

3. 增長瀏覽器的握手時延。

而OCSP Stapling是對OCSP缺陷的彌補，服務器可事先模擬瀏覽器對證書鏈進行驗證，並將帶有CA機構簽名的OCSP響應保存到本地，而後在握手階段，將OCSP響應和證書鏈一塊兒下發給瀏覽器，省去瀏覽器的在線驗證過程。

SPDY和HTTP2.0

SPDY 是 Google 推出的優化 HTTP 傳輸效率的協議，採用多路複用方式，能將多個 HTTP 請求在同一個鏈接上一塊兒發出去，對HTTP通訊效率提高明顯。HTTP2.0是 IETF 2015 年 2 月份經過的 HTTP 下一代協議，它以 SPDY 爲原型。SPDY 和 HTTP2 目前的實現默認使用 HTTPS 協議。

Nginx stable版本當前只能支持到SPDY3.1，但最新發布的1.9.5版本經過打patch的方式，能夠支持HTTP2.0，這絕對是不同的奇妙體驗。不過不建議直接在線上環境部署，等到2015年年末吧，Nginx會發布Stable版本支持HTTP2.0.

TCP優化

由於TCP是HTTPS的承載，TCP的性能提高，上層業務均可以受益。

慢啓動是TCP規範中很重要的算法，其目的是爲避免網絡擁塞。經過客戶端和服務器之間的數據交換，從一個很保守的初始擁塞窗口值，收斂到雙方都承認的可用帶寬。當客戶端和服務器收斂到必定帶寬時，若是一段時間內，雙方沒有收發數據包，服務器端的擁塞窗口會被重置爲初始擁塞窗口值。這對於鏈接中的突發數據傳輸性能影響是很嚴重的。

在沒有充足的理由時，服務器端須要禁用空閒後的慢啓動機制。

另外，當前瀏覽器和服務器之間的可用帶寬已經相對較大，因此咱們還應該將初始的擁塞窗口值擴大，新的RFC中的建議是10，Google是16。

TLS Record Size

服務器在創建TLS鏈接時，會爲每一個鏈接分配Buffer，這個Buffer叫TLS Record Size。這個Size是可調。

Size值若是太小，頭部負載比重就會過大，最高可達6%。

Size值若是過大，那單個Record在TCP層會被分紅多個包發送。瀏覽器必須等待這些所有達到後，才能解密，一旦出現丟包、擁塞、重傳、甚至從新創建的狀況，時延就會被相應增長。

那TLS Record Size值如何選擇呢？有兩個參數可參考。

首先，TLS Record Size要大於證書鏈和OCSP Stapling響應大小，證書鏈不會分紅多個record；

其次，要小於初始擁塞窗口值，保證服務器在通訊之初能夠發送足夠數據而不須要等待瀏覽器確認

通常來講，從根CA機構申請的證書爲2-3KB左右，級數越多，證書鏈越大，ocsp響應爲2KB左右，因此TLS Record Size是須要根據你的實際狀況設置，Google的值5KB。WildDog當前的值是6KB。

證書鏈完整且不冗餘

瀏覽器在驗證服務器下發的證書鏈時，不只僅驗證網站證書。若是是多級證書，網站證書和根證書之間全部的中間證書都須要被驗證。一旦出現證書鏈出現不完整，瀏覽器就會暫停握手過程，自行到因特網進行驗證，這個時間基本是不可估算的。

至於怎麼查看，經過openssl命令查看，也能夠經過SSL Labs幫你在線檢測。

移動設備上的ChaCha20-Poly1305

去年的時候，谷歌已經在Android的Chrome瀏覽器上增長支持一個新的TLS加密套件，這個加密套件就是ChaCha20-Poly1305。它的設計者是伊利諾伊大學的教授和研究員Dan BernsteinChaCha20被用來加密，Poly1305被用來消息認證，兩個操做都須要運行於TLS上。

當前流行的加密套件AES-GCM在TLS 1.2支持，它是不安全RC4和AES-CBC加密套件的替代品。可是，在不支持硬件AES的設備上會引發性能問題，如大部分的智能手機、平板電腦、可穿戴設備。

ChaCha20-Poly1305正式爲解決這個問題而生。如下是Google的相關測試數據，在使用Snapdragon S4 Pro處理器的Nexus 4或其餘手機中，AES-GSM的加密吞吐量是41.5MB/s，而ChaCha20-Poly1305是130.9MB/s。在使用OMAP 4460的老的Galaxy Nexus手機上，AES-GSM的吞吐量是24.1MB/s，而ChaCha20-Poly1305是75.3MB/s。

當前，OpenSSL 1.0.2的分支上已經開始支持ChaCha20-Poly1305，而對ChaCha20-Poly1305支持最好的當屬BoringSSL。經過從新對Nginx的SSL庫編譯，能夠支持到ChaCha20-Poly1305，不過對於線上環境，建議看明白源碼再使用。

除此以外，還有很多優化的細節，如硬件加速、False Start、禁用TLS壓縮等等，這裏就不扒了。

若是以爲這篇文章有幫助，就請收藏或者分享一下，但願能夠幫到更多人。