本文摘自 騰訊bugly 的文章《全站 HTTPS 來(lái)了》，內(nèi)容有修改。

大家在使用百度、谷歌或淘寶的時(shí)候，是否注意到瀏覽器地址欄中出現(xiàn)了一把 綠鎖。下圖示為 Safari 瀏覽器訪問(wèn)水果官網(wǎng)，點(diǎn)擊綠鎖查看信息，可以看到水果網(wǎng)站證書(shū)由 Symantec 提供（準(zhǔn)確的說(shuō)是 VeriSign，Symantec 于 2010年將其收購(gòu)）。

一把小綠鎖

這把鎖表明該網(wǎng)站已經(jīng)使用了 HTTPS 進(jìn)行保護(hù)。點(diǎn)擊該網(wǎng)站首頁(yè)中的鏈接，或者訪問(wèn)某個(gè)二級(jí)域名會(huì)發(fā)現(xiàn)這些網(wǎng)站已經(jīng)全站使用 HTTPS。

IOS 9 引入了新特性 ATS (App Transport Security)，要求 App 內(nèi)訪問(wèn)的網(wǎng)絡(luò)必須使用 HTTPS 協(xié)議。但在 IOS 9 中有變通途徑，可以在 Info.plist 中添加 NSAppTransportSecurity 字典，并且將 NSAllowsArbitraryLoads 設(shè)置為 YES 來(lái)禁用 ATS，這個(gè)途徑在 WWDC 16 上也被水果干掉了。17年后所有新提交 app 默認(rèn)是不允許使用 NSAllowsArbitraryLoads 來(lái)繞過(guò) ATS 限制。霸特，原定于 2017年1月1日后提交 App Store 的應(yīng)用強(qiáng)制要求支持 ATS 的計(jì)劃不得不被延期，因?yàn)槟壳爸挥?5% 的應(yīng)用合規(guī)。

隨著互聯(lián)網(wǎng)的發(fā)展，現(xiàn)代互聯(lián)網(wǎng)正在逐漸進(jìn)入全站 HTTPS 時(shí)代，即便條件再艱苦的小站也應(yīng)該盡早考慮將賬戶(hù)、支付等要命的環(huán)節(jié)升級(jí)為 HTTPS。目前還在觀望的同學(xué)一定會(huì)關(guān)注諸如下面的問(wèn)題，全站 HTTPS 能夠帶來(lái)怎樣的優(yōu)勢(shì)？HTTPS 的原理又是什么？同時(shí)，阻礙 HTTPS 普及的困難是什么？

下面就綜合參考多種資料并經(jīng)過(guò)實(shí)踐驗(yàn)證，探究 HTTPS 的基礎(chǔ)原理，分析基本的 HTTPS 通信過(guò)程，為全站 HTTPS 的來(lái)臨做好準(zhǔn)備。

HTTPS 基礎(chǔ)

HTTPS（Secure Hypertext Transfer Protocol，安全超文本傳輸協(xié)議），是一個(gè)安全通信通道。它基于 HTTP 開(kāi)發(fā)，用于在客戶(hù)計(jì)算機(jī)和服務(wù)器之間交換信息，它使用安全套接字層（SSL）進(jìn)行信息交換。簡(jiǎn)單來(lái)說(shuō)，它是 HTTP 的安全版，是使用 TLS/SSL 加密的 HTTP 協(xié)議。

HTTP 協(xié)議采用明文傳輸信息，存在信息竊聽(tīng)、信息篡改和信息劫持的風(fēng)險(xiǎn)，而協(xié)議 TLS/SSL 具有身份驗(yàn)證、信息加密和完整性校驗(yàn)的功能，可以避免上述問(wèn)題的發(fā)生。

TLS/SSL 全稱(chēng)為安全傳輸層協(xié)議，即 Transport Layer Security。它是介于 TCP 和 HTTP 之間的一層安全協(xié)議，不影響原有的 TCP 協(xié)議和 HTTP 協(xié)議，所以使用 HTTPS 基本上不需要對(duì) HTTP 頁(yè)面進(jìn)行太多的改造。

HTTPS 協(xié)議介紹

TLS/SSL 原理

HTTPS 協(xié)議的主要功能基本都依賴(lài)于 TLS/SSL 協(xié)議，本節(jié)分析安全協(xié)議的實(shí)現(xiàn)原理。

TLS/SSL 的功能實(shí)現(xiàn)主要依賴(lài)于三類(lèi)基本算法：散列函數(shù) Hash、對(duì)稱(chēng)加密 和 非對(duì)稱(chēng)加密。利用非對(duì)稱(chēng)加密實(shí)現(xiàn)身份認(rèn)證和密鑰協(xié)商，對(duì)稱(chēng)加密算法采用協(xié)商的密鑰對(duì)數(shù)據(jù)加密，基于散列函數(shù)驗(yàn)證信息的完整性。

TLS/SSL 協(xié)議結(jié)構(gòu)

• 散列函數(shù) Hash，常見(jiàn)的算法有 MD5、SHA1、SHA256。該類(lèi)函數(shù)特點(diǎn)是：
• 函數(shù)單向不可逆
• 對(duì)輸入非常敏感
• 輸出長(zhǎng)度固定

針對(duì)數(shù)據(jù)的任何修改都會(huì)改變散列函數(shù)結(jié)果的特點(diǎn)，用于防止信息篡改并驗(yàn)證數(shù)據(jù)的完整性。在信息傳輸過(guò)程中，散列函數(shù)不能單獨(dú)實(shí)現(xiàn)信息防篡改。因?yàn)槊魑膫鬏敚虚g人可以修改信息之后重新計(jì)算信息摘要，因此需要對(duì)傳輸?shù)男畔⒁约靶畔⒄M(jìn)行加密。

• 對(duì)稱(chēng)加密，常見(jiàn)的算法有 AES-CBC、DES、3DES、AES-GCM。它的優(yōu)勢(shì)在于一對(duì)一的信息傳輸方式，雙方需要共享相同的密碼，因?yàn)槊艽a的安全是保證信息安全的基礎(chǔ)。相同的密鑰可以用于信息的加密和解密，掌握密鑰才能獲取信息。但這樣的機(jī)制帶來(lái)的問(wèn)題是，服務(wù)器和 N 個(gè)客戶(hù)端通信，需要維持 N 個(gè)密碼記錄，且缺少修改密碼的機(jī)制。

• 非對(duì)稱(chēng)加密，最常見(jiàn)的是 RSA 算法，還有 ECC、DH 等算法。非對(duì)稱(chēng)加密的算法特點(diǎn)是：密鑰成對(duì)出現(xiàn)，一般稱(chēng)為公鑰（公開(kāi)）和私鑰（保密）。公鑰加密的信息只能被私鑰解開(kāi)，私鑰加密的信息也只能公鑰解開(kāi)。因此掌握公鑰的不同客戶(hù)端之間不能互相解密信息，只能和掌握私鑰的服務(wù)器進(jìn)行加密通信。服務(wù)器可以實(shí)現(xiàn)一對(duì)多的通信，客戶(hù)端也可以驗(yàn)證掌握私鑰的服務(wù)器身份。由于非對(duì)稱(chēng)加密是一對(duì)多的信息傳輸，服務(wù)器只需要維持一個(gè)私鑰就能夠和多個(gè)客戶(hù)端進(jìn)行加密通信，但服務(wù)器發(fā)出的信息能夠被所有的客戶(hù)端解密，并且該算法的計(jì)算復(fù)雜，加密速度慢。

綜上所述，結(jié)合三類(lèi)算法的特點(diǎn)，TLS 的基本工作方式是：客戶(hù)端使用非對(duì)稱(chēng)加密與服務(wù)器進(jìn)行通信，實(shí)現(xiàn)身份驗(yàn)證并協(xié)商對(duì)稱(chēng)加密使用的密鑰。然后對(duì)稱(chēng)加密算法采用協(xié)商密鑰對(duì)信息以及信息摘要進(jìn)行加密通信，不同的節(jié)點(diǎn)之間采用的對(duì)稱(chēng)密鑰不同（因?yàn)樵谏擅荑€時(shí)變量并不同），從而可以保證信息只能通信雙方獲取。

PKI 體系

RSA 身份驗(yàn)證的隱患

身份驗(yàn)證和密鑰協(xié)商是 TLS 的基礎(chǔ)功能，要求的前提是合法的服務(wù)器掌握著對(duì)應(yīng)的私鑰。但 RSA 算法無(wú)法確保服務(wù)器身份的合法性，因?yàn)?公鑰并不包含服務(wù)器的信息，這樣實(shí)際存在很大的安全隱患。

1. 客戶(hù)端 C 和服務(wù)器 S 進(jìn)行通信，中間節(jié)點(diǎn) M 截獲了二者的通信。
2. 節(jié)點(diǎn) M 自己計(jì)算產(chǎn)生一對(duì)公鑰 pub_M 和私鑰 pri_M。
3. C 向 S 請(qǐng)求公鑰時(shí)，M 把自己的公鑰 pub_M 發(fā)給了 C。
4. C 使用公鑰 pub_M 加密的數(shù)據(jù)能夠被 M 解密，因?yàn)?M 掌握對(duì)應(yīng)的私鑰 pri_M。而 C 無(wú)法根據(jù)公鑰信息判斷服務(wù)器的身份，從而 C 和 M 之間建立了 可信 的加密連接。
5. 中間節(jié)點(diǎn) M 和服務(wù)器 S 之間再建立合法的連接，因此 C 和 S 之間通信被 M 完全掌握，M 可以進(jìn)行信息的竊聽(tīng)、篡改等操作。
6. 服務(wù)器 S 也可以對(duì)自己的發(fā)出的信息進(jìn)行否認(rèn)，不承認(rèn)相關(guān)信息是自己發(fā)出。

因此該方案下至少存在兩類(lèi)問(wèn)題：中間人攻擊 和 信息抵賴(lài)。

RSA 算法隱患

身份驗(yàn)證 - CA 和證書(shū)

為了解決上述身份驗(yàn)證問(wèn)題，關(guān)鍵是確保獲取的公鑰途徑是合法的。要驗(yàn)證服務(wù)器的身份信息，需要引入權(quán)威的第三方機(jī)構(gòu) CA。CA 負(fù)責(zé)核實(shí)公鑰的擁有者信息，并頒發(fā) 認(rèn)證證書(shū)，同時(shí)能夠?yàn)槭褂谜咛峁┳C書(shū)驗(yàn)證服務(wù)，即 PKI 體系（PKI - Public Key Infrastructure，公鑰基礎(chǔ)設(shè)施）。它的基本的原理為：CA 負(fù)責(zé)審核信息，然后對(duì)關(guān)鍵信息利用私鑰進(jìn)行 簽名。CA 公開(kāi)對(duì)應(yīng)的公鑰，客戶(hù)端可以利用公鑰驗(yàn)證簽名（簽名就是對(duì)摘要信息進(jìn)行加密）。同時(shí) CA 也可以吊銷(xiāo)已經(jīng)簽發(fā)的證書(shū)，基本的方式包括 CRL 和 OCSP 兩類(lèi)。

CA 的使用流程

1. 服務(wù)方 S 向第三方機(jī)構(gòu) CA 提交公鑰、組織信息、個(gè)人信息（域名）等信息并申請(qǐng)認(rèn)證。

CSR 是證書(shū)請(qǐng)求文件(Cerificate Signing Request)，它是公鑰證書(shū)原始文件。服務(wù)方 S 需要生成 .csr 文件，并將其提交給 CA。一般來(lái)說(shuō)，CA 并不直接對(duì)服務(wù)方 S 提供服務(wù)，由第三方服務(wù)商專(zhuān)門(mén)提供代理證書(shū)申請(qǐng)認(rèn)證的服務(wù)。生成 .csr 文件需要使用 OpenSSL，代理商會(huì)提供相應(yīng)的工具生成。服務(wù)方 S 填寫(xiě)好自身相關(guān)的信息后用工具生成 .csr 文件，并將 .csr 文件發(fā)給代理商進(jìn)行后續(xù)的簽發(fā)工作。

2. CA 通過(guò)線上線下多種手段驗(yàn)證申請(qǐng)者提供信息的真實(shí)性，如組織是否存在、企業(yè)是否合法、是否擁有域名的所有權(quán)等。

3. 如信息審核通過(guò)，CA 會(huì)向申請(qǐng)者簽發(fā)認(rèn)證文件 - 證書(shū)。證書(shū)包含以下 明文 信息：

• 申請(qǐng)者公鑰
• 申請(qǐng)者的組織信息和個(gè)人信息
• 簽發(fā)機(jī)構(gòu) CA 的信息
• 有效時(shí)間
• 證書(shū)序列號(hào)等信息的明文

同時(shí)包含一個(gè)簽名，簽名的產(chǎn)生算法：首先，使用散列函數(shù)計(jì)算公開(kāi)的明文信息的信息摘要。然后，采用 CA 的私鑰對(duì)信息摘要進(jìn)行加密，密文即簽名。

4. 客戶(hù)端 C 向服務(wù)器 S 發(fā)出請(qǐng)求時(shí)，S 返回證書(shū)文件。

5. 客戶(hù)端 C 讀取證書(shū)中的相關(guān)的明文信息，采用相同的散列函數(shù)計(jì)算得到信息摘要，然后，利用對(duì)應(yīng) CA 的公鑰解密簽名數(shù)據(jù)，對(duì)比證書(shū)的信息摘要，如果一致，則可以確認(rèn)證書(shū)的合法性，即公鑰合法（服務(wù)方 S 的公鑰）。

6. 驗(yàn)證完證書(shū)合法性后，客戶(hù)端繼續(xù)驗(yàn)證證書(shū)相關(guān)的域名信息、有效時(shí)間等信息。

7. 客戶(hù)端會(huì)內(nèi)置信任 CA 的證書(shū)信息，包含公鑰。如果 CA 不被信任，則找不到對(duì)應(yīng) CA 的證書(shū)，證書(shū)也會(huì)被判定非法。例如，一些企業(yè)或個(gè)人創(chuàng)建的 CA 頒發(fā)的證書(shū)會(huì)在瀏覽器中彈出 **私密連接警告 ?? **，如果人為確認(rèn)證書(shū)的合法性，可以點(diǎn)擊忽略警告并繼續(xù)前往加密站點(diǎn)。

注意以下幾點(diǎn)：

• 申請(qǐng)證書(shū)（指服務(wù)器 S 向 CA 申請(qǐng)證書(shū)）不需要提供私鑰，確保私鑰永遠(yuǎn)只能服務(wù)器掌握。
• 證書(shū)的合法性仍然依賴(lài)于非對(duì)稱(chēng)加密算法，證書(shū)主要是增加了服務(wù)器信息以及簽名。
• 內(nèi)置 CA 對(duì)應(yīng)的證書(shū)稱(chēng)為根證書(shū)，頒發(fā)者和使用者相同，自己為自己簽名，即自簽名證書(shū)。
• 證書(shū) = 公鑰 + 申請(qǐng)者與頒發(fā)者信息 + 簽名。

證書(shū)鏈

如 CA 根證書(shū)和服務(wù)器證書(shū)中間增加一級(jí)證書(shū)機(jī)構(gòu)，即中間證書(shū)，證書(shū)的產(chǎn)生和驗(yàn)證原理不變，只是增加一層驗(yàn)證，只要最后能夠被任何信任的CA根證書(shū)驗(yàn)證合法即可。

1. 服務(wù)器證書(shū) server.pem 的簽發(fā)者為中間證書(shū)機(jī)構(gòu) inter，inter 根據(jù)證書(shū) inter.pem 驗(yàn)證 server.pem 確實(shí)為自己簽發(fā)的有效證書(shū)。
2. 中間證書(shū) inter.pem 的簽發(fā) CA 為 root，root 根據(jù)證書(shū) root.pem 驗(yàn)證 inter.pem 為自己簽發(fā)的合法證書(shū)。
3. 客戶(hù)端內(nèi)置信任 CA 的 root.pem 證書(shū)，因此服務(wù)器證書(shū) server.pem 的被信任。

中間證書(shū)

服務(wù)器證書(shū)、中間證書(shū)與根證書(shū)在一起組合成一條合法的證書(shū)鏈，證書(shū)鏈的驗(yàn)證是自下而上的信任傳遞的過(guò)程。二級(jí)證書(shū)結(jié)構(gòu)存在的優(yōu)勢(shì)：

1. 減少根證書(shū)結(jié)構(gòu)的管理工作量，可以更高效的進(jìn)行證書(shū)的審核與簽發(fā)。
2. 根證書(shū)一般內(nèi)置在客戶(hù)端中，私鑰一般離線存儲(chǔ)，一旦私鑰泄露，則吊銷(xiāo)過(guò)程非常困難，無(wú)法及時(shí)補(bǔ)救。
3. 中間證書(shū)結(jié)構(gòu)的私鑰泄露，則可以快速在線吊銷(xiāo)，并重新為用戶(hù)簽發(fā)新的證書(shū)。
4. 證書(shū)鏈四級(jí)以?xún)?nèi)一般不會(huì)對(duì) HTTPS 的性能造成明顯影響。

證書(shū)鏈

證書(shū)鏈有以下特點(diǎn)：

• 同一本服務(wù)器證書(shū)可能存在多條合法的證書(shū)鏈。
  因?yàn)樽C書(shū)的生成和驗(yàn)證基礎(chǔ)是公鑰和私鑰對(duì)，如果采用相同的公鑰和私鑰生成不同的中間證書(shū)，針對(duì)被簽發(fā)者而言，該簽發(fā)機(jī)構(gòu)都是合法的 CA，不同的是中間證書(shū)的簽發(fā)機(jī)構(gòu)不同。
• 不同證書(shū)鏈的層級(jí)不一定相同，可能二級(jí)、三級(jí)或四級(jí)證書(shū)鏈。
  中間證書(shū)的簽發(fā)機(jī)構(gòu)可能是根證書(shū)機(jī)構(gòu)也可能是另一個(gè)中間證書(shū)機(jī)構(gòu)，所以證書(shū)鏈層級(jí)不一定相同。

證書(shū)吊銷(xiāo)

CA 機(jī)構(gòu)能夠簽發(fā)證書(shū)，同樣也存在機(jī)制宣布以往簽發(fā)的證書(shū)無(wú)效。為何會(huì)有吊銷(xiāo)證書(shū)的需求呢？

• 證書(shū)使用者不合法，CA 需要廢棄該證書(shū)。
• 私鑰丟失，使用者申請(qǐng)讓證書(shū)無(wú)效。

那么，證書(shū)的吊銷(xiāo)有兩種機(jī)制：CRL 與 OCSP。

• CRL
  Certificate Revocation List，證書(shū)吊銷(xiāo)列表，一個(gè)單獨(dú)的文件。該文件包含了 CA 已經(jīng)吊銷(xiāo)的證書(shū)序列號(hào)（唯一）與吊銷(xiāo)日期，同時(shí)該文件包含生效日期并通知下次更新該文件的時(shí)間，當(dāng)然該文件必然包含 CA 私鑰的簽名以驗(yàn)證文件的合法性。
  證書(shū)中一般會(huì)包含一個(gè) URL 地址 CRL Distribution Point，通知使用者去哪里下載對(duì)應(yīng)的 CRL 以校驗(yàn)證書(shū)是否吊銷(xiāo)。該吊銷(xiāo)方式的優(yōu)點(diǎn)是不需要頻繁更新，但是不能及時(shí)吊銷(xiāo)證書(shū)。因?yàn)?CRL 更新時(shí)間一般是幾天，這期間可能已經(jīng)造成了極大損失。

• OCSP
  Online Certificate Status Protocol，證書(shū)狀態(tài)在線查詢(xún)協(xié)議，一個(gè)實(shí)時(shí)查詢(xún)證書(shū)是否吊銷(xiāo)的方式。請(qǐng)求者發(fā)送證書(shū)的信息并請(qǐng)求查詢(xún)，服務(wù)器返回正常、吊銷(xiāo)或未知中的任何一個(gè)狀態(tài)。證書(shū)中一般也會(huì)包含一個(gè) OCSP 的 URL 地址，要求查詢(xún)服務(wù)器具有良好的性能。

部分 CA 或大部分的自簽 CA 的根證書(shū)都未提供 CRL 或 OCSP 地址，對(duì)于吊銷(xiāo)證書(shū)會(huì)是一件非常麻煩的事情。

TLS/SSL 握手過(guò)程

1. 握手與密鑰協(xié)商過(guò)程

基于 RSA 握手和密鑰交換的客戶(hù)端驗(yàn)證服務(wù)器為示例，詳解握手過(guò)程。

握手與密鑰協(xié)商

• client_hello
  客戶(hù)端發(fā)起請(qǐng)求，以明文傳輸請(qǐng)求信息。請(qǐng)求包含 version (版本信息) ，cipher suites (加密套件候選列表) ，compression methods (壓縮算法候選列表) ，random_C (隨機(jī)數(shù)) ，extensions (擴(kuò)展字段) 等信息，相關(guān)信息如下：

• 支持的最高TSL協(xié)議版本version，從低到高依次 SSLv2 > SSLv3 > TLSv1 > TLSv1.1 > TLSv1.2，當(dāng)前基本不再使用低于 TLSv1 的版本。
• 客戶(hù)端支持的加密套件 cipher suites 列表， 每個(gè)加密套件對(duì)應(yīng)前面 TLS 原理中的四個(gè)功能的組合：認(rèn)證算法 Au (身份驗(yàn)證)、密鑰交換算法 KeyExchange (密鑰協(xié)商)、對(duì)稱(chēng)加密算法 Enc (信息加密) 和信息摘要 Mac (完整性校驗(yàn))。
• 支持的壓縮算法 compression methods 列表，用于后續(xù)的信息壓縮傳輸。
• 隨機(jī)數(shù) random_C，用于后續(xù)的密鑰的生成。
• 擴(kuò)展字段 extensions，支持協(xié)議與算法的相關(guān)參數(shù)以及其它輔助信息等，常見(jiàn)的 SNI 就屬于擴(kuò)展字段，后續(xù)單獨(dú)討論該字段作用。

• server_hello → server_certificate → sever_hello_done

• server_hello，服務(wù)端返回協(xié)商的信息結(jié)果，包括選擇使用的協(xié)議版本 version，選擇的加密套件 cipher suite，選擇的壓縮算法 compression method、隨機(jī)數(shù) random_S 等，其中隨機(jī)數(shù)用于后續(xù)的密鑰協(xié)商。
• server_certificates，服務(wù)器端配置對(duì)應(yīng)的證書(shū)鏈，用于身份驗(yàn)證與密鑰交換。
• server_hello_done，通知客戶(hù)端 server_hello 信息發(fā)送結(jié)束。

• 證書(shū)校驗(yàn)
  客戶(hù)端驗(yàn)證證書(shū)的合法性，如果驗(yàn)證通過(guò)才會(huì)進(jìn)行后續(xù)通信，否則根據(jù)錯(cuò)誤情況不同做出提示和操作。合法性驗(yàn)證包括如下：

• 證書(shū)鏈的可信性 trusted certificate path，方法如前文所述。
• 證書(shū)是否吊銷(xiāo) revocation，有兩類(lèi)方式 離線 CRL 與 在線 OCSP，不同的客戶(hù)端行為會(huì)不同。
• 有效期 expiry date，證書(shū)是否在有效時(shí)間范圍。
• 域名 domain，核查證書(shū)域名是否與當(dāng)前的訪問(wèn)域名匹配，匹配規(guī)則后續(xù)分析。

證書(shū)校驗(yàn)的作用是確保客戶(hù)端獲取到 正確可信 的 服務(wù)器公鑰。對(duì)此，客戶(hù)端要做一系列的工作：驗(yàn)證證書(shū)鏈，驗(yàn)證吊銷(xiāo)狀態(tài)，驗(yàn)證有效期，驗(yàn)證域名。只有通過(guò)全部驗(yàn)證才能保證獲取到的 服務(wù)器公鑰 → 正確可信。

• client_key_exchange → change_cipher_spec → encrypted_handshake_message

• client_key_exchange，合法性驗(yàn)證通過(guò)之后，客戶(hù)端計(jì)算產(chǎn)生隨機(jī)數(shù)字 Pre-master，并用證書(shū)公鑰加密（用服務(wù)器公鑰加密的隨機(jī)數(shù) Pre-master 只能服務(wù)器用自己的私鑰解開(kāi)），發(fā)送給服務(wù)器。
• 客戶(hù)端已經(jīng)獲取全部的計(jì)算協(xié)商密鑰需要的信息，兩個(gè)明文隨機(jī)數(shù) random_C 和 random_S 與自己計(jì)算產(chǎn)生的 Pre-master，計(jì)算得到協(xié)商密鑰：enc_key = Fuc (random_C, random_S, Pre-Master) 。
• change_cipher_spec，客戶(hù)端通知服務(wù)器后續(xù)的通信都采用協(xié)商的通信密鑰和加密算法進(jìn)行加密通信。
• encrypted_handshake_message，結(jié)合之前所有通信參數(shù)的 hash 值與其它相關(guān)信息生成一段數(shù)據(jù)，采用協(xié)商密鑰 session secret 與算法進(jìn)行加密，然后發(fā)送給服務(wù)器用于數(shù)據(jù)與握手驗(yàn)證。

• change_cipher_spec → encrypted_handshake_message

• 服務(wù)器用私鑰解密加密的 Pre-master 數(shù)據(jù)，基于之前交換的兩個(gè)明文隨機(jī)數(shù) random_C 和 random_S，計(jì)算得到協(xié)商密鑰：enc_key = Fuc (random_C, random_S, Pre-Master) 。
• 計(jì)算之前所有接收信息的 hash 值，然后解密客戶(hù)端發(fā)送的encrypted_handshake_message，驗(yàn)證數(shù)據(jù)和密鑰正確性。
• change_cipher_spec，驗(yàn)證通過(guò)之后，服務(wù)器同樣發(fā)送 change_cipher_spec 以告知客戶(hù)端后續(xù)的通信都采用協(xié)商的密鑰與算法進(jìn)行加密通信。
• encrypted_handshake_message，服務(wù)器也結(jié)合所有當(dāng)前的通信參數(shù)信息生成一段數(shù)據(jù)并采用協(xié)商密鑰 session secret 與算法加密并發(fā)送到客戶(hù)端。

客戶(hù)端計(jì)算生成隨機(jī)數(shù) Pre-master，用服務(wù)器公鑰加密后發(fā)給服務(wù)器。服務(wù)器獲得加密信息后用私鑰解密獲得 Pre-master。客戶(hù)端和服務(wù)器分別計(jì)算協(xié)商秘鑰 enc_key，該秘鑰用于雙方對(duì)稱(chēng)加密通信使用。這里需要注意的是，在客戶(hù)端獲取到服務(wù)器公鑰并加密 Pre-master 發(fā)給服務(wù)器之前，客戶(hù)端發(fā)給服務(wù)器的隨機(jī)數(shù) random_C 和服務(wù)器回給客戶(hù)端的隨機(jī)數(shù) random_S 都是明文。但由于算法和 Pre-master 的存在，并不影響計(jì)算出來(lái)的 enc_key 只有客戶(hù)端和服務(wù)器持有。

客戶(hù)端發(fā)給服務(wù)器的加密信息：

• 用服務(wù)器的公鑰加密的隨機(jī)數(shù) Pre-master 發(fā)給服務(wù)器，服務(wù)器收到后計(jì)算協(xié)商秘鑰 enc_key。

• 用協(xié)商秘鑰（對(duì)稱(chēng)秘鑰）enc_key 對(duì) client_hello 和 server_hello 中協(xié)商的相關(guān)通信參數(shù)和信息做 數(shù)字簽名（對(duì)這些信息生成摘要并加密）并發(fā)給服務(wù)器，服務(wù)器收到后用之前計(jì)算出的 enc_key 解密客戶(hù)端發(fā)來(lái)的 數(shù)字簽名 以驗(yàn)證 enc_key 的正確性，如果能解開(kāi)則說(shuō)明協(xié)商秘鑰正確。服務(wù)器對(duì) client_hello 和 server_hello 中的信息做哈希生成摘要，對(duì)比解密的簽名信息以驗(yàn)證 雙方通信參數(shù) 的正確性。

• 握手結(jié)束
  客戶(hù)端計(jì)算所有接收信息的 hash 值，并采用協(xié)商密鑰解密 encrypted_handshake_message，驗(yàn)證服務(wù)器發(fā)送的數(shù)據(jù)和密鑰，驗(yàn)證通過(guò)則握手完成。

在（對(duì)稱(chēng)）加密通信之前，準(zhǔn)備工作（非對(duì)稱(chēng)加密）中，

• 明文傳輸
  • client_hello
  • server_hello
  • change_cipher_spec

• 密文傳輸

• client_key_exchange：用服務(wù)器公鑰加密用于計(jì)算對(duì)稱(chēng)秘鑰的隨機(jī)數(shù) Pre-master 且只有擁有私鑰的服務(wù)器能解開(kāi)
• encrypted_handshake_message：用協(xié)商秘鑰加密 client_hello 和 server_hello 中的信息摘要便于驗(yàn)證協(xié)商秘鑰的正確性以及比對(duì)信息摘要

• 加密通信
  開(kāi)始使用協(xié)商密鑰與算法進(jìn)行加密通信。

注意：

• 服務(wù)器也可以要求驗(yàn)證客戶(hù)端，即雙向認(rèn)證，可以在過(guò)程2要發(fā)送 client_certificate_request 信息，客戶(hù)端在過(guò)程4中先發(fā)送 client_certificate與certificate_verify_message 信息，證書(shū)的驗(yàn)證方式基本相同，certificate_verify_message 是采用client的私鑰加密的一段基于已經(jīng)協(xié)商的通信信息得到數(shù)據(jù)，服務(wù)器可以采用對(duì)應(yīng)的公鑰解密并驗(yàn)證。
• 根據(jù)使用的密鑰交換算法的不同，如 ECC 等，協(xié)商細(xì)節(jié)略有不同，總體相似。
• sever key exchange 的作用是 server certificate 沒(méi)有攜帶足夠的信息時(shí)，發(fā)送給客戶(hù)端以計(jì)算 pre-master，如基于 DH 的證書(shū)，公鑰不被證書(shū)中包含，需要單獨(dú)發(fā)送。
• change cipher spec 實(shí)際可用于通知對(duì)端改版當(dāng)前使用的加密通信方式，當(dāng)前沒(méi)有深入解析。
• alter message 用于指明在握手或通信過(guò)程中的狀態(tài)改變或錯(cuò)誤信息，一般告警信息觸發(fā)條件是連接關(guān)閉，收到不合法的信息，信息解密失敗，用戶(hù)取消操作等，收到告警信息之后，通信會(huì)被斷開(kāi)或者由接收方?jīng)Q定是否斷開(kāi)連接。

2. 會(huì)話緩存握手過(guò)程

為了加快建立握手的速度，減少協(xié)議帶來(lái)的性能降低和資源消耗（具體分析在后文），TLS 協(xié)議有兩類(lèi)會(huì)話緩存機(jī)制：會(huì)話標(biāo)識(shí) session ID 與會(huì)話記錄 session ticket。

• session ID 由服務(wù)器端支持，協(xié)議中的標(biāo)準(zhǔn)字段，因此基本所有服務(wù)器都支持。服務(wù)器端保存會(huì)話 ID 以及協(xié)商的通信信息，Nginx 中 1M 內(nèi)存約可以保存 4000 個(gè) session ID 機(jī)器相關(guān)信息，占用服務(wù)器資源較多。

• session ticket 需要服務(wù)器和客戶(hù)端都支持，屬于一個(gè)擴(kuò)展字段，支持范圍約 60%（無(wú)可靠統(tǒng)計(jì)與來(lái)源），將協(xié)商的通信信息加密之后發(fā)送給客戶(hù)端保存，密鑰只有服務(wù)器知道，占用服務(wù)器資源很少。

二者對(duì)比，主要是保存協(xié)商信息的位置與方式不同，類(lèi)似于 http 中的 session 與 cookie。二者都存在的情況下，Nginx 優(yōu)先使用 session_ticket。

握手過(guò)程如下圖：

回話緩存

注意：雖然握手過(guò)程有 1.5 個(gè)來(lái)回，但是最后客戶(hù)端向服務(wù)器發(fā)送的第一條應(yīng)用數(shù)據(jù)不需要等待服務(wù)器返回的信息，因此握手延時(shí)是 1*RTT。

RTT ( Round-Trip Time )：往返時(shí)延。指從發(fā)送端發(fā)送數(shù)據(jù)開(kāi)始，到發(fā)送端收到來(lái)自接收端的確認(rèn)（接收端收到數(shù)據(jù)后便立即發(fā)送確認(rèn)），總共經(jīng)歷的時(shí)延。

會(huì)話標(biāo)識(shí) session ID

• 如果客戶(hù)端和服務(wù)器之間曾經(jīng)建立了連接，服務(wù)器會(huì)在握手成功后返回 session ID，并保存對(duì)應(yīng)的通信參數(shù)在服務(wù)器中。
• 如果客戶(hù)端再次需要和該服務(wù)器建立連接，則在 client_hello 中的 session ID 中攜帶記錄的信息，發(fā)送給服務(wù)器。
• 服務(wù)器根據(jù)收到的 session ID 檢索緩存記錄，如果沒(méi)有檢索到或者緩存過(guò)期，則按照正常的握手過(guò)程進(jìn)行。
• 如果檢索到對(duì)應(yīng)的緩存記錄，則返回 change_cipher_spec 與 encrypted_handshake_message 信息。兩者作用類(lèi)似，encrypted_handshake_message 是當(dāng)前的通信參數(shù)與 master_secret 的 hash 值。
• 如果客戶(hù)端能夠驗(yàn)證通過(guò)服務(wù)器加密數(shù)據(jù)，則客戶(hù)端向服務(wù)器同樣發(fā)送 change_cipher_spec 與 encrypted_handshake_message 信息。
• 服務(wù)器驗(yàn)證數(shù)據(jù)通過(guò)，則握手建立成功，開(kāi)始進(jìn)行正常的加密數(shù)據(jù)通信。

會(huì)話記錄 session ticket

• 如果客戶(hù)端和服務(wù)器之間曾經(jīng)建立了連接，服務(wù)器會(huì)在 new_session_ticket 數(shù)據(jù)中攜帶加密的 session_ticket 信息，客戶(hù)端保存。
• 如果客戶(hù)端再次需要和該服務(wù)器建立連接，則在 client_hello 中擴(kuò)展字段 session_ticket 中攜帶加密信息，一起發(fā)送給服務(wù)器。
• 服務(wù)器解密 sesssion_ticket 數(shù)據(jù)，如果能夠解密失敗，則按照正常的握手過(guò)程進(jìn)行。
• 如果解密成功，則返回 change_cipher_spec 與 encrypted_handshake_message 信息，兩個(gè)信息作用與 session ID 中類(lèi)似。
• 如果客戶(hù)端能夠驗(yàn)證通過(guò)服務(wù)器加密數(shù)據(jù)，則客戶(hù)端同樣發(fā)送 change_cipher_spec 與encrypted_handshake_message 信息。
• 服務(wù)器驗(yàn)證數(shù)據(jù)通過(guò)，則握手建立成功，開(kāi)始進(jìn)行正常的加密數(shù)據(jù)通信。

3. 重建連接

重建連接 (SSL Renegotiation)，即放棄正在使用的 TLS 連接，重新進(jìn)行身份認(rèn)證和密鑰協(xié)商的過(guò)程。特點(diǎn)是不需要斷開(kāi)當(dāng)前的數(shù)據(jù)傳輸就可以重新身份認(rèn)證、更新密鑰或算法，因此服務(wù)器端存儲(chǔ)和緩存的信息都可以保持。客戶(hù)端和服務(wù)器都能夠發(fā)起重建連接的過(guò)程（目前 Windows 2000 & XP 與 SSL 2.0不支持）。

• 服務(wù)器重建連接，服務(wù)器端重建連接一般情況是客戶(hù)端訪問(wèn)受保護(hù)的數(shù)據(jù)時(shí)發(fā)生。

• 客戶(hù)端和服務(wù)器之間建立了有效 TLS 連接并通信。
• 客戶(hù)端訪問(wèn)受保護(hù)的信息。
• 服務(wù)器端返回 hello_request 信息。
• 客戶(hù)端收到 hello_request 信息之后發(fā)送 client_hello 信息，開(kāi)始重新建立連接。

服務(wù)器重建連接

• 客戶(hù)端重建連接，客戶(hù)端重建連接一般是為了更新通信密鑰。

• 客戶(hù)端和服務(wù)器之間建立了有效 TLS 連接并通信。
• 客戶(hù)端需要更新密鑰，主動(dòng)發(fā)出 client_hello 信息。
• 服務(wù)器端收到 client_hello 信息之后無(wú)法立即識(shí)別出該信息非應(yīng)用數(shù)據(jù)，因此會(huì)提交給下一步處理，處理完之后會(huì)返回通知該信息為要求重建連接。
• 在確定重建連接之前，服務(wù)器不會(huì)立即停止向客戶(hù)端發(fā)送數(shù)據(jù)，可能恰好同時(shí)或有緩存數(shù)據(jù)需要發(fā)送給客戶(hù)端，但是客戶(hù)端不會(huì)再發(fā)送任何信息給服務(wù)器。
• 服務(wù)器識(shí)別出重建連接請(qǐng)求之后，發(fā)送 server_hello 信息至客戶(hù)端。
• 客戶(hù)端也同樣無(wú)法立即判斷出該信息非應(yīng)用數(shù)據(jù)，同樣提交給下一步處理，處理之后會(huì)返回通知該信息為要求重建連接。
• 客戶(hù)端和服務(wù)器開(kāi)始新的重建連接的過(guò)程。

客戶(hù)端重建連接

4. 密鑰計(jì)算

上節(jié)提到了兩個(gè)明文傳輸?shù)碾S機(jī)數(shù) random_C 和 random_S 與通過(guò)加密在服務(wù)器和客戶(hù)端之間交換的 Pre-master，三個(gè)參數(shù)作為密鑰協(xié)商的基礎(chǔ)。本節(jié)討論說(shuō)明密鑰協(xié)商的基本計(jì)算過(guò)程以及通信過(guò)程中的密鑰使用。

計(jì)算 Key

涉及參數(shù) random client 和 random server，Pre-master，Master secret，key materia。計(jì)算密鑰時(shí)，服務(wù)器和客戶(hù)端都具有這些基本信息，交換方式在上節(jié)中有說(shuō)明，計(jì)算流程如下：

• 客戶(hù)端采用 RSA 或 Diffie-Hellman 等加密算法生成 Pre-master。
• Pre-master 結(jié)合 random client 和 random server 兩個(gè)隨機(jī)數(shù)通過(guò) PseudoRandomFunction (PRF) 計(jì)算得到 Master secret。
• Master secret 結(jié)合 random client 和 random server 兩個(gè)隨機(jī)數(shù)通過(guò)迭代計(jì)算得到 key material。

計(jì)算 key

1. PreMaster secret 前兩個(gè)字節(jié)是 TLS 的版本號(hào)，這是一個(gè)比較重要的用來(lái)核對(duì)握手?jǐn)?shù)據(jù)的版本號(hào)，因?yàn)樵?Client Hello 階段，客戶(hù)端會(huì)發(fā)送一份加密套件列表和當(dāng)前支持的 SSL/TLS 的版本號(hào)給服務(wù)端，而且是使用明文傳送的，如果握手的數(shù)據(jù)包被破解之后，攻擊者很有可能串改數(shù)據(jù)包，選擇一個(gè)安全性較低的加密套件和版本給服務(wù)端，從而對(duì)數(shù)據(jù)進(jìn)行破解。所以，服務(wù)端需要對(duì)密文中解密出來(lái)對(duì)的 PreMaster 版本號(hào)跟之前 Client Hello 階段的版本號(hào)進(jìn)行對(duì)比，如果版本號(hào)變低，則說(shuō)明被串改，則立即停止發(fā)送任何消息。

2. 不管是客戶(hù)端還是服務(wù)器，都需要隨機(jī)數(shù)，這樣生成的密鑰才不會(huì)每次都一樣。由于 SSL 協(xié)議中證書(shū)是靜態(tài)的，因此十分有必要引入一種隨機(jī)因素來(lái)保證協(xié)商出來(lái)的密鑰的隨機(jī)性。

對(duì)于 RSA 密鑰交換算法來(lái)說(shuō)，pre-master-key 本身就是一個(gè)隨機(jī)數(shù)，再加上 hello 消息中的隨機(jī)，三個(gè)隨機(jī)數(shù)通過(guò)一個(gè)密鑰導(dǎo)出器最終導(dǎo)出一個(gè)對(duì)稱(chēng)密鑰。
pre master 的存在在于 SSL 協(xié)議不信任每個(gè)主機(jī)都能產(chǎn)生完全隨機(jī)的隨機(jī)數(shù)，如果隨機(jī)數(shù)不隨機(jī)，那么 pre master secret 就有可能被猜出來(lái)，那么僅適用 pre master secret 作為密鑰就不合適了，因此必須引入新的隨機(jī)因素，那么客戶(hù)端和服務(wù)器加上 pre master secret 三個(gè)隨機(jī)數(shù)一同生成的密鑰就不容易被猜出了，一個(gè)偽隨機(jī)可能完全不隨機(jī)，可是三個(gè)偽隨機(jī)就十分接近隨機(jī)了，每增加一個(gè)自由度，隨機(jī)性增加的可不是一。

密鑰使用

Key 經(jīng)過(guò) 12 輪迭代計(jì)算會(huì)獲取到 12個(gè) hash 值，分組成為6個(gè)元素，列表如下：

密鑰使用

• mac key、encryption key 和 IV 是一組加密元素，分別被客戶(hù)端和服務(wù)器使用，但是這兩組元素都被兩邊同時(shí)獲取。
• 客戶(hù)端使用 client 組元素加密數(shù)據(jù)，服務(wù)器使用 client 元素解密；服務(wù)器使用 server 元素加密，client 使用 server 元素解密。
• 雙向通信的不同方向使用的密鑰不同，破解通信至少需要破解兩次。
• encryption key 用于對(duì)稱(chēng)加密數(shù)據(jù)。
• IV 作為很多加密算法的初始化向量使用，具體可以研究對(duì)稱(chēng)加密算法。
• Mac key 用于數(shù)據(jù)的完整性校驗(yàn)。

5. 數(shù)據(jù)加密通信過(guò)程

• 對(duì)應(yīng)用層數(shù)據(jù)進(jìn)行分片成合適的 block。
• 為分片數(shù)據(jù)編號(hào)，防止重放攻擊。
• 使用協(xié)商的壓縮算法壓縮數(shù)據(jù)。
• 計(jì)算 MAC 值和壓縮數(shù)據(jù)組成傳輸數(shù)據(jù)。
• 使用 client encryption key 加密數(shù)據(jù)，發(fā)送給服務(wù)器 server。
• server 收到數(shù)據(jù)之后使用 client encrytion key 解密，校驗(yàn)數(shù)據(jù)，解壓縮數(shù)據(jù)，重新組裝。

注：MAC 值的計(jì)算包括兩個(gè) Hash 值：client Mac key 和 Hash (編號(hào)、包類(lèi)型、長(zhǎng)度、壓縮數(shù)據(jù))。

6. 抓包分析

關(guān)于抓包不再詳細(xì)分析，按照前面的分析，基本的情況都能夠匹配，根據(jù)平常定位問(wèn)題的過(guò)程，個(gè)人提些認(rèn)為需要注意的地方：

• 抓包 HTTP 通信，能夠清晰的看到通信的頭部和信息的明文，但是 HTTPS 是加密通信，無(wú)法看到 HTTP 協(xié)議的相關(guān)頭部和數(shù)據(jù)的明文信息。

• 抓包 HTTPS 通信主要包括三個(gè)過(guò)程：TCP 建立連接、TLS 握手、TLS 加密通信，主要分析 HTTPS 通信的握手建立和狀態(tài)等信息。

• client_hello

• 根據(jù) version 信息能夠知道客戶(hù)端支持的最高的協(xié)議版本號(hào)，如果是 SSL 3.0 或 TLS 1.0 等低版本協(xié)議，非常注意可能因?yàn)榘姹镜鸵鹨恍┪帐质〉那闆r。
• 根據(jù) extension 字段中的 server_name 字段判斷是否支持 SNI，存在則支持，否則不支持，對(duì)于定位握手失敗或證書(shū)返回錯(cuò)誤非常有用。
• 會(huì)話標(biāo)識(shí) session ID 是標(biāo)準(zhǔn)協(xié)議部分，如果沒(méi)有建立過(guò)連接則對(duì)應(yīng)值為空，不為空則說(shuō)明之前建立過(guò)對(duì)應(yīng)的連接并緩存。
• 會(huì)話記錄 session ticket 是擴(kuò)展協(xié)議部分，存在該字段說(shuō)明協(xié)議支持 sesssion ticket，否則不支持，存在且值為空，說(shuō)明之前未建立并緩存連接，存在且值不為空，說(shuō)明有緩存連接。

• server_hello

• 根據(jù) TLS version 字段能夠推測(cè)出服務(wù)器支持的協(xié)議的最高版本，版本不同可能造成握手失敗。
• 基于 cipher_suite 信息判斷出服務(wù)器優(yōu)先支持的加密協(xié)議。

• ceritficate
  服務(wù)器配置并返回的證書(shū)鏈，根據(jù)證書(shū)信息并與服務(wù)器配置文件對(duì)比，判斷請(qǐng)求與期望是否一致，如果不一致，是否返回的默認(rèn)證書(shū)。

• alert
  告警信息 alert 會(huì)說(shuō)明建立連接失敗的原因即告警類(lèi)型，對(duì)于定位問(wèn)題非常重要。

HTTPS 性能與優(yōu)化

1. HTTPS 性能損耗

前文討論了 HTTPS 原理與優(yōu)勢(shì)：身份驗(yàn)證、信息加密與完整性校驗(yàn)等，并且未對(duì) TCP 和 HTTP 協(xié)議做任何修改。但通過(guò)增加新協(xié)議以實(shí)現(xiàn)更安全的通信必然需要付出代價(jià)，HTTPS 協(xié)議的性能損耗主要體現(xiàn)在以下兩點(diǎn)：

• 增加延時(shí)
  分析前面的握手過(guò)程，一次完整的握手至少需要兩端依次來(lái)回兩次通信，至少增加延時(shí) 2*RTT，利用會(huì)話緩存從而復(fù)用連接，延時(shí)也至少 1*RTT。

• 消耗較多的 CPU 資源
  除數(shù)據(jù)傳輸之外，HTTPS 通信主要包括對(duì)對(duì)稱(chēng)加解密、非對(duì)稱(chēng)加解密（服務(wù)器主要采用私鑰解密數(shù)據(jù)）。
  壓測(cè) TS8 機(jī)型的單核 CPU：對(duì)稱(chēng)加密算法 AES-CBC-256 吞吐量 600Mbps，非對(duì)稱(chēng) RSA 私鑰解密 200次/s。不考慮其它軟件層面的開(kāi)銷(xiāo)，10G 網(wǎng)卡為對(duì)稱(chēng)加密需要消耗 CPU 約 17核，24 核 CPU 最多接入 HTTPS 連接 4800。
  靜態(tài)節(jié)點(diǎn)當(dāng)前 10G 網(wǎng)卡的 TS8 機(jī)型的 HTTP 單機(jī)接入能力約為 10w/s，如果將所有的 HTTP 連接變?yōu)?HTTPS 連接，則明顯 RSA 的解密最先成為瓶頸。因此，RSA 的解密能力是當(dāng)前困擾 HTTPS 接入的主要難題。

2. HTTPS 接入優(yōu)化

• CDN 接入
  HTTPS 增加的延時(shí)主要是傳輸延時(shí) RTT，RTT 的特點(diǎn)是節(jié)點(diǎn)越近延時(shí)越小。CDN 基于就近訪問(wèn)的原則，天然離用戶(hù)最近，因此選擇使用 CDN 作為 HTTPS 接入的入口，將能夠極大減少接入延時(shí)。CDN 節(jié)點(diǎn)通過(guò)和業(yè)務(wù)服務(wù)器維持長(zhǎng)連接、會(huì)話復(fù)用和鏈路質(zhì)量?jī)?yōu)化等可控方法，極大減少 HTTPS 帶來(lái)的延時(shí)。

• 會(huì)話緩存
  雖然前文提到 HTTPS 即使采用會(huì)話緩存也要至少 1*RTT 的延時(shí)，但是至少延時(shí)已經(jīng)減少為原來(lái)的一半，明顯的延時(shí)優(yōu)化。同時(shí)，基于會(huì)話緩存建立的 HTTPS 連接不需要服務(wù)器使用 RSA 私鑰解密獲取 Pre-master 信息，可以節(jié)省 CPU 的消耗。如果業(yè)務(wù)訪問(wèn)連接集中，緩存命中率高，則 HTTPS 的接入能力將明顯提升。當(dāng)前 TRP 平臺(tái)的緩存命中率高峰時(shí)期大于 30%，10k/s 的接入資源實(shí)際可以承載 13k/s 的接入，收效非常可觀。

• 硬件加速
  為接入服務(wù)器安裝專(zhuān)用的 SSL 硬件加速卡，作用類(lèi)似 GPU，釋放 CPU，能夠具有更高的 HTTPS 接入能力并且不影響業(yè)務(wù)程序。測(cè)試某硬件加速卡單卡可以提供 35k 的解密能力，相當(dāng)于 175 核 CPU，至少相當(dāng)于 7 臺(tái) 24 核的服務(wù)器。考慮到接入服務(wù)器其它程序的開(kāi)銷(xiāo)，一張硬件卡可以實(shí)現(xiàn)接近 10 臺(tái)服務(wù)器的接入能力。

• 遠(yuǎn)程解密（自用且規(guī)模不大不建議使用）
  采用本地接入方式消耗過(guò)多的 CPU 資源，浪費(fèi)了網(wǎng)卡和硬盤(pán)等資源。考慮將最消耗 CPU 資源的 RSA 解密計(jì)算任務(wù)轉(zhuǎn)移到其它服務(wù)器，如此則可以充分發(fā)揮服務(wù)器的接入能力，充分利用帶寬與網(wǎng)卡資源。遠(yuǎn)程解密服務(wù)器可以選擇 CPU 負(fù)載較低的機(jī)器充當(dāng)，實(shí)現(xiàn)機(jī)器資源復(fù)用，也可以是專(zhuān)門(mén)優(yōu)化的高計(jì)算性能的服務(wù)器。遠(yuǎn)程解密的方式也是 CDN 提供大規(guī)模 HTTPS 接入的解決方案之一。

• SPDY/HTTP2
  前面的方法分別從減少傳輸延時(shí)和單機(jī)負(fù)載的方法提高 HTTPS 接入性能，但是方法都基于不改變 HTTP 協(xié)議的基礎(chǔ)上提出的優(yōu)化方法，SPDY/HTTP2 利用 TLS/SSL 帶來(lái)的優(yōu)勢(shì)，通過(guò)修改協(xié)議的方法來(lái)提升 HTTPS 的性能，提高下載速度等。

- END -