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

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

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

一,、什么是HTTPS網(wǎng)站,？

在介紹HTTPS網(wǎng)站前，首先簡單介紹什么是HTTPS,。

HTTPS可以理解為HTTP+TLS,，HTTP是互聯(lián)網(wǎng)中使用最為廣泛的協(xié)議，目前不部分的WEB應用和網(wǎng)站都是使用HTTP協(xié)議傳輸,。主流版本是HTTP1.1,，HTTP2.0還未正式普及，2.0由Google的SPDY協(xié)議演化而來,，在性能上有明顯的提升,。

TLS是傳輸層加密協(xié)議，是HTTPS安全的核心,，其前身是SSL,，主流版本有SSL3.0、TLS1.0,、TLS1.1,、TLS1.2,。SSL3.0和TLS1.0由于存在安全漏洞，已經(jīng)很少被使用到,。

那網(wǎng)站為什么要實現(xiàn)HTTPS,？

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

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

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

二、HTTPS網(wǎng)站的直觀了解

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

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

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

12306購票頁面

淘寶首頁

百度首頁

維基百科首頁

WildDog首頁

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

三,、提高HTTPS網(wǎng)站性能和訪問速度

如果你認為網(wǎng)站加上TLS證書,，就是HTTPS網(wǎng)站了，那你就跟12306犯了同樣的錯誤......

首先,，網(wǎng)站在加上TLS證書時,，為什么會變慢,？這主要又兩方面造成：

1. HTTPS比HTTP在通信時會產(chǎn)生更多的通信過程，隨之RTT時間就會增加,；

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

但是，每個HTTPS網(wǎng)站其實都有著巨大的優(yōu)化空間,。下面我們結(jié)合WildDog網(wǎng)站,，來看看QPS值從30000到80000，加載時延從800ms到300ms,，這中間的每個優(yōu)化點是怎樣的,。

HSTS

HTTPS網(wǎng)站通常的做法是對HTTP的訪問在服務器端做302跳轉(zhuǎn)，跳轉(zhuǎn)到HTTPS,。但這個302跳轉(zhuǎn)存在兩個問題：

1. 使用不安全的HTTP協(xié)議進行通信,；

2. 增加一個Round-Trip Time。

而HSTS是HTTP Strict Transport Security的縮寫,，服務器端配置支持HSTS后,，會在給瀏覽器返回的HTTP Header中攜帶HSTS字段，瀏覽器在獲取到該信息后,，在接下來的一段時間內(nèi),，對該網(wǎng)站的所有HTTP訪問，瀏覽器都將請求在內(nèi)部做307跳轉(zhuǎn)到HTTPS,，而無需任何網(wǎng)絡過程,。

Session Resume

Session Resume即會話復用，這提升HTTPS網(wǎng)站性能最基礎也是最有效的方法,。

在HTTPS握手階段,，對服務器性能消耗最為嚴重的是非對稱密鑰交換計算，而Session Resume通過對已經(jīng)建立TLS會話的合理復用,，節(jié)省非對稱密鑰交換計算次數(shù),，可大幅提高服務器的TLS性能。

TLS協(xié)議提供兩種實現(xiàn)機制Session Resume,，分別是Session cache和Session ticket,。

Session Cache

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

Session ticket

Session ticket的原理是服務器降session信息加密成ticket發(fā)送給瀏覽器,，瀏覽器后續(xù)進行TLS握手時,，會發(fā)送ticket，如果服務器能夠解密和處理該ticket,，則可以復用session,。

Session ticket可以很好的解決分布式問題，但Session ticket的支持率還不是很高,，而且需要考慮服務器上key的安全性方案,。

OCSP Stapling

在HTTPS通信過程時，瀏覽器會去驗證服務器端下發(fā)的證書鏈是否已經(jīng)被撤銷,。驗證的方法有兩種：CRL和OCSP,。

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

1. CRL列表只會越來越大,；

2. 如果瀏覽器更新不及時，會造成誤判,。

OCSP是實時證書在線驗證協(xié)議,，是對CRL機制的彌補，通過OCSP瀏覽器可以實時的向CA機構驗證證書,。但OCSP同樣存在不足：

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

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

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

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

SPDY和HTTP2.0

SPDY 是 Google 推出的優(yōu)化 HTTP 傳輸效率的協(xié)議,，采用多路復用方式，能將多個 HTTP 請求在同一個連接上一起發(fā)出去,，對HTTP通信效率提升明顯,。HTTP2.0是 IETF 2015 年 2 月份通過的 HTTP 下一代協(xié)議，它以 SPDY 為原型,。SPDY 和 HTTP2 目前的實現(xiàn)默認使用 HTTPS 協(xié)議。

Nginx stable版本當前只能支持到SPDY3.1,，但最新發(fā)布的1.9.5版本通過打patch的方式,，可以支持HTTP2.0，這絕對是不一樣的奇妙體驗,。不過不建議直接在線上環(huán)境部署，等到2015年年底吧,，Nginx會發(fā)布Stable版本支持HTTP2.0.

TCP優(yōu)化

因為TCP是HTTPS的承載,，TCP的性能提升,，上層業(yè)務都可以受益,。

慢啟動是TCP規(guī)范中很重要的算法，其目的是為避免網(wǎng)絡擁塞,。通過客戶端和服務器之間的數(shù)據(jù)交換，從一個很保守的初始擁塞窗口值,，收斂到雙方都認可的可用帶寬,。當客戶端和服務器收斂到一定帶寬時，如果一段時間內(nèi),，雙方?jīng)]有收發(fā)數(shù)據(jù)包,，服務器端的擁塞窗口會被重置為初始擁塞窗口值。這對于連接中的突發(fā)數(shù)據(jù)傳輸性能影響是很嚴重的,。

在沒有充足的理由時,，服務器端需要禁用空閑后的慢啟動機制。

另外,，當前瀏覽器和服務器之間的可用帶寬已經(jīng)相對較大,，所以我們還應該將初始的擁塞窗口值擴大，新的RFC中的建議是10,，Google是16,。

TLS Record Size

服務器在建立TLS連接時,，會為每個連接分配Buffer,，這個Buffer叫TLS Record Size。這個Size是可調(diào),。

Size值如果過小,，頭部負載比重就會過大，最高可達6%,。

Size值如果過大,，那單個Record在TCP層會被分成多個包發(fā)送。瀏覽器必須等待這些全部達到后，才能解密,，一旦出現(xiàn)丟包,、擁塞、重傳,、甚至重新建立的情況,，時延就會被相應增加。

那TLS Record Size值如何選擇呢,？有兩個參數(shù)可參考,。

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

其次，要小于初始擁塞窗口值,，保證服務器在通信之初可以發(fā)送足夠數(shù)據(jù)而不需要等待瀏覽器確認

一般來說,，從根CA機構申請的證書為2-3KB左右，級數(shù)越多,，證書鏈越大,，ocsp響應為2KB左右，所以TLS Record Size是需要根據(jù)你的實際情況設置,，Google的值5KB,。WildDog當前的值是6KB。

證書鏈完整且不冗余

瀏覽器在驗證服務器下發(fā)的證書鏈時,，不僅僅驗證網(wǎng)站證書,。如果是多級證書，網(wǎng)站證書和根證書之間所有的中間證書都需要被驗證,。一旦出現(xiàn)證書鏈出現(xiàn)不完整,，瀏覽器就會暫停握手過程,，自行到因特網(wǎng)進行驗證,，這個時間基本是不可估算的。

至于怎么查看,，通過openssl命令查看,，也可以通過SSL Labs幫你在線檢測。

移動設備上的ChaCha20-Poly1305

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

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

ChaCha20-Poly1305正式為解決這個問題而生,。以下是Google的相關測試數(shù)據(jù),，在使用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的分支上已經(jīng)開始支持ChaCha20-Poly1305,，而對ChaCha20-Poly1305支持最好的當屬BoringSSL,。通過重新對Nginx的SSL庫編譯，可以支持到ChaCha20-Poly1305,，不過對于線上環(huán)境,，建議看明白源碼再使用。

除此之外,，還有不少優(yōu)化的細節(jié),，如硬件加速、False Start,、禁用TLS壓縮等等,，這里就不扒了。

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

本文由 野狗實時 創(chuàng)作,，采用 知識共享署名-相同方式共享 3.0 中國大陸許可協(xié)議 進行許可,。轉(zhuǎn)載、引用前需聯(lián)系作者,，并署名作者且注明文章出處,。