HTTPS網(wǎng)絡(luò)優(yōu)化

HTTPS可以解決很多安全方面的困擾

https通信過程

https通信過程.png
  1. 客戶端發(fā)出握手請求（Client Hello）,包含以下信息：
    • 支持的協(xié)議版本，比如TLS 1.0版。
    • 一個(gè)客戶端生成的隨機(jī)數(shù)(random_1)，這個(gè)隨機(jī)數(shù)既需要客戶端保存又需要發(fā)送給服務(wù)器。
    • 支持的加密方法，比如RSA公鑰加密。
    • 支持的壓縮方法。
  2. 服務(wù)器回復(fù)（Server Hello），包含以下信息：
    • 確認(rèn)使用的加密通信協(xié)議版本，比如TLS 1.0版本。如果瀏覽器與服務(wù)器支持的版本不一致，服務(wù)器關(guān)閉加密通信。
    • 一個(gè)服務(wù)器生成的隨機(jī)數(shù)(random_2)。
    • 確認(rèn)使用的加密方法，比如RSA公鑰加密。
    • 服務(wù)器證書。
    • 如果服務(wù)器需要確認(rèn)客戶端的身份，就會(huì)再包含一項(xiàng)請求，要求客戶端提供”客戶端證書”。比如，金融機(jī)構(gòu)往往只允許認(rèn)證客戶連入自己的網(wǎng)絡(luò)，就會(huì)向正式客戶提供USB密鑰，里面就包含了一張客戶端證書。
  3. 客戶端回應(yīng),包含以下步驟：
    • 驗(yàn)證服務(wù)器證書的合法性，證書合法性包括：證書是否過期，發(fā)行服務(wù)器證書的 CA 是否可靠，發(fā)行者證書的公鑰能否正確解開服務(wù)器證書的“發(fā)行者的數(shù)字簽名”，服務(wù)器證書上的域名是否和服務(wù)器的實(shí)際域名相匹配。如果合法性驗(yàn)證沒有通過，通訊將斷開；
    • 客戶端使用一些加密算法(例如：RSA,Diffie-Hellman)產(chǎn)生一個(gè)48個(gè)字節(jié)的Key，這個(gè)Key叫PreMaster Secret。該PreMaster Secret用服務(wù)器公鑰加密傳送，防止被竊聽。
    • 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
    • 客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值，用來供服務(wù)器校驗(yàn)。
    • 如果前一步，服務(wù)器要求客戶端證書，客戶端會(huì)在這一步發(fā)送證書及相關(guān)信息。
  4. 服務(wù)器回應(yīng)，服務(wù)器通過上面的三個(gè)隨機(jī)數(shù)(random_1,random_2,PreMaster Secret)，計(jì)算出本次會(huì)話的會(huì)話密鑰(session secret)，然后向客戶端發(fā)送下面信息
    • 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
    • 服務(wù)器握手結(jié)束通知，表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值，用來供客戶端校驗(yàn)。

至此，服務(wù)器和客戶端的握手階段全部結(jié)束，接下來，客戶端與服務(wù)器進(jìn)入加密通信，就完全是使用普通的HTTP協(xié)議，只不過用會(huì)話密鑰(session secret)對內(nèi)容做對稱加密。

備注：HTTPS 的通信過程中只在握手階段使用了非對稱加密，后面的通信過程均使用的對稱加密。盡管非對稱加密相比對稱加密更加安全，但也存在兩個(gè)明顯缺點(diǎn)：

  • CPU 計(jì)算資源消耗非常大。一次完全 TLS 握手，密鑰交換時(shí)的非對稱解密計(jì)算量占整個(gè)握手過程的 90% 以上。而對稱加密的計(jì)算量只相當(dāng)于非對稱加密的 0.1%，如果應(yīng)用層數(shù)據(jù)也使用非對稱加解密，性能開銷太大，無法承受。
  • 非對稱加密算法對加密內(nèi)容的長度有限制，不能超過公鑰長度。比如現(xiàn)在常用的公鑰長度是 2048 位，意味著待加密內(nèi)容不能超過 256 個(gè)字節(jié)。

HTTPS主要計(jì)算環(huán)節(jié)

首先看HTTPS主要的計(jì)算環(huán)節(jié)，下圖是一個(gè)協(xié)議交互的簡要介紹圖，它的四種顏色分別代表4種不同的主要計(jì)算環(huán)節(jié)：

  • 紅色環(huán)節(jié)是非對稱密鑰交換，通過客戶端和服務(wù)端不一致的信息協(xié)商出對稱的密鑰；
  • 藍(lán)色環(huán)節(jié)是證書校驗(yàn)，對證書的簽名進(jìn)行校驗(yàn)，確認(rèn)網(wǎng)站的身份；
  • 深綠色環(huán)節(jié)是對稱加解密，通過非對稱密鑰交換協(xié)商出對稱密鑰來進(jìn)行加解密；

  • 淺綠色環(huán)節(jié)是完整性校驗(yàn)，不僅要加密還要防止內(nèi)容被篡改，所以要進(jìn)行自身的完整性校驗(yàn)。


優(yōu)化

1、優(yōu)化 SSL 握手之前過程
  • TCP 優(yōu)化
    TCP Fast Open(一下簡稱 TFO)目的在于簡化TCP 握手的過程，通過一定的協(xié)商過程（SYN 攜帶 cookie 信息）使得下一次握手的時(shí)候在 SYN 包中就可以攜帶數(shù)據(jù)，同時(shí) Server可以在發(fā)出 SYN ACK之后立即開始發(fā)送數(shù)據(jù)。因此如果我們的 SSL 握手建立 TCP 連接的時(shí)候能夠啟用 TFO，那么我們的SSL 握手流量就可以減少至少一個(gè)RTT 。
    備注：需要服務(wù)器內(nèi)核支持TFO，TCP_FASTOPEN 特性在kernel-3.6 被客戶端支持，在 kernel-3.7 被服務(wù)端支持;
    參考：美圖HTTPS優(yōu)化探索與實(shí)踐
2、優(yōu)化 SSL 握手的過程

首先第一步也是最簡單的一個(gè)優(yōu)化策略，就是減少完全握手的發(fā)生，因?yàn)橥耆帐炙浅Ｏ臅r(shí)間；
首先看協(xié)議層如何支持。TLS協(xié)議層有兩個(gè)策略可以實(shí)現(xiàn):

  • 使用Session ID，Session ID由服務(wù)器生成并返回給客戶端，客戶端再次發(fā)起SSL握手時(shí)會(huì)攜帶上Session ID，服務(wù)端拿到后會(huì)從自己的內(nèi)存查找，如果找到便意味著客戶端之前已經(jīng)發(fā)生過完全握手，是可以信任的，然后可以直接進(jìn)行簡化握手。
  • 使用Session Ticket，同樣它也是客戶端發(fā)起握手時(shí)會(huì)攜帶上的擴(kuò)展，服務(wù)器拿到Session Ticket后會(huì)對它進(jìn)行解密，如果解密成功了就意味著它是值得信任的，從而可以進(jìn)行簡化握手，直接傳輸應(yīng)用層數(shù)據(jù)。

工程實(shí)現(xiàn)上會(huì)有什么問題呢？ 請閱讀騰訊HTTPS性能優(yōu)化實(shí)踐

對于不能減少的完全握手，對于必須要發(fā)生的完全握手，對于需要直接消耗CPU進(jìn)行的握手，我們使用代理計(jì)算；請閱讀騰訊HTTPS性能優(yōu)化實(shí)踐中異步代理的原理和實(shí)現(xiàn)；

3、對稱加密的優(yōu)化；

AES-GCM性能最高，建議大家使用。請閱讀騰訊HTTPS性能優(yōu)化實(shí)踐中對稱加密算法的優(yōu)化。

4、HttpDNS優(yōu)化

DNS解析想必大家都知道，在傳統(tǒng)PC時(shí)代DNS Lookup基本在幾十ms內(nèi)。而我們通過大量的數(shù)據(jù)采集和真實(shí)網(wǎng)絡(luò)抓包分析（存在DNS解析的請求），DNS的消耗相當(dāng)可觀，2G網(wǎng)絡(luò)大量5-10s，3G網(wǎng)絡(luò)平均也要3-5s。
參考:手淘雙十一系列（一） | 521 性能優(yōu)化項(xiàng)目揭秘
App域名劫持之DNS高可用 - 開源版HttpDNS方案詳解
美團(tuán)點(diǎn)評移動(dòng)網(wǎng)絡(luò)優(yōu)化實(shí)踐中的短連方案一、域名合并方案

5、建連復(fù)用：SSL化，SPDY建連高復(fù)用

全站SSL化，SSL化之后，SPDY可以默認(rèn)開啟，SPDY協(xié)議下的傳輸效率和建連復(fù)用效益將最大化。SPDY協(xié)議下，資源并發(fā)請求數(shù)將不再受瀏覽器webview的并發(fā)請求數(shù)量限制，并發(fā)100+都是可能的。
參考:手淘雙十一系列（一） | 521 性能優(yōu)化項(xiàng)目揭秘

6、短連方案一、域名合并方案

該方案的核心思想在于：保持客戶端業(yè)務(wù)層代碼編寫的網(wǎng)絡(luò)請求與后端業(yè)務(wù)服務(wù)器收到的請求保持一致，請求發(fā)出前，在客戶端網(wǎng)絡(luò)層對域名收編，請求送入后端，在SLB(Server Load Balancing)中對域名進(jìn)行還原。
參考：美團(tuán)點(diǎn)評移動(dòng)網(wǎng)絡(luò)優(yōu)化實(shí)踐中的短連方案一、域名合并方案

7、短連方案二、IP直連方案

程序啟動(dòng)的時(shí)候拉取短連方案一中統(tǒng)一的域名對應(yīng)的所有的IP列表；對所有IP進(jìn)行跑馬測試，找到速度最快的IP。后續(xù)所有的HTTPS請求都將域名更換為跑馬最快的IP即可。
參考：美團(tuán)點(diǎn)評移動(dòng)網(wǎng)絡(luò)優(yōu)化實(shí)踐中的短連方案二、IP直連方案

7、長連通道建設(shè)

使用騰訊的WNS服務(wù)
參考：美團(tuán)點(diǎn)評移動(dòng)網(wǎng)絡(luò)優(yōu)化實(shí)踐中的長連通道建設(shè)

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

推薦閱讀更多精彩內(nèi)容