HTTPS加密了什麼內容？
今年6月，維基媒體基金會發布公告，旗下所有網站將默認開啟HTTPS，這些網站中最為人所知的當然是全球最大的在線百科-維基百科。而更早時候的3月，百度已經發布公告，百度全站默認開啟HTTPS。淘寶也默默做了全站HTTPS。
網站實現HTTPS，在國外已經非常普及，也是必然的趨勢。Google、Facebook、Twitter等巨頭公司早已經實現全站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安全和性能研究機構。在線檢測地址為：SSL Server Test (Powered by Qualys SSL Labs)。
SSL Labs會對HTTPS網站的證書鏈、安全性、性能、協議細節進行全面檢測，檢測完畢後會進行打分，同時給出一份詳細的檢測報告和改進建議。
三、提高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壓縮等等，這裡就不扒了。
如果覺得這篇文章有幫助，就請收藏或者分享一下，希望可以幫到更多人。