扒一扒HTTPS網站的內幕

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

網站實現HTTPS，在國外已經非常普及，也是必然的趨勢。Google、非死book、推ter等巨頭公司早已經實現全站 HTTPS，而且為鼓勵全球網站的HTTPS實現，Google甚至調整了搜索引擎算法，讓采用HTTPS的網站在搜索中排名更靠前。但是在國 內，HTTPS網站進展并不好，大部分的電商網站也僅僅是對賬戶登錄和交易做HTTPS，比如京東；很多網站甚至連登錄頁面也沒有實現HTTPS...這 里面有很多的原因，比如現有架構改動的代價過大、CDN實現困難、對用戶隱私和安全的不重視等。

還有個重要原因是擔心網站實現HTTPS后，網站的用戶體驗和性能下降明顯。事實上，通過合理部署和優化，HTTPS網站的訪問速度和性能基本不會受到影響。

一、什么是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.1、TLS1.2。SSL3.0和TLS1.0由于存在安全漏洞，已經很少被使用到。

那網站為什么要實現HTTPS？

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

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

感興趣的同學可以Google之，基礎都是一樣的。

二、HTTPS網站的直觀了解

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

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

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

12306購票頁面

淘寶首頁

百度首頁

維基百科首頁

WildDog首頁

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

三、提高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壓縮等等，這里就不扒了。

如果覺得這篇文章有幫助，就請收藏或者分享一下，希望可以幫到更多人。