1 前言

HTTPS在保護(hù)用戶隱私，防止流量劫持方面發(fā)揮著非常關(guān)鍵的作用，但與此同時(shí)，HTTPS也會(huì)降低用戶訪問(wèn)速度，增加網(wǎng)站服務(wù)器的計(jì)算資源消耗。

本文主要介紹https對(duì)用戶體驗(yàn)的影響。

本文最早發(fā)表于百度運(yùn)維部官方博客

2 HTTPS對(duì)訪問(wèn)速度的影響

在介紹速度優(yōu)化策略之前，先來(lái)看下HTTPS對(duì)速度有什么影響。影響主要來(lái)自兩方面：

1. 協(xié)議交互所增加的網(wǎng)絡(luò)RTT(round trip time)。

2. 加解密相關(guān)的計(jì)算耗時(shí)。

下面分別介紹一下。

2.1 網(wǎng)絡(luò)耗時(shí)增加

由于 HTTP和HTTPS都需要DNS解析，并且大部分情況下使用了DNS緩存，為了突出對(duì)比效果，忽略主域名的DNS解析時(shí)間。

用戶使用HTTP協(xié)議訪問(wèn)http://www.baidu.com(或者www.baidu.com)時(shí)會(huì)有如下網(wǎng)絡(luò)上的交互耗時(shí)：

可見，用戶只需要完成TCP三次握手建立TCP連接就能夠直接發(fā)送HTTP請(qǐng)求獲取應(yīng)用層數(shù)據(jù)，此外在整個(gè)訪問(wèn)過(guò)程中也沒有需要消耗計(jì)算資源的地方。

接下來(lái)看HTTPS的訪問(wèn)過(guò)程，相比HTTP要復(fù)雜很多，在部分場(chǎng)景下，使用HTTPS訪問(wèn)有可能增加7個(gè)RTT。如下圖：

HTTPS***請(qǐng)求需要的網(wǎng)絡(luò)耗時(shí)解釋如下：

1. 三次握手建立TCP連接。耗時(shí)一個(gè)RTT。

2. 使用HTTP發(fā)起GET請(qǐng)求，服務(wù)端返回302跳轉(zhuǎn)到https://www.baidu.com。需要一個(gè)RTT以及302跳轉(zhuǎn)延時(shí)。

a) 大部分情況下用戶不會(huì)手動(dòng)輸入https://www.baidu.com來(lái)訪問(wèn)HTTPS，服務(wù)端只能返回302強(qiáng)制瀏覽器跳轉(zhuǎn)到https。

b) 瀏覽器處理302跳轉(zhuǎn)也需要耗時(shí)。

3. 三次握手重新建立TCP連接。耗時(shí)一個(gè)RTT。

a) 302跳轉(zhuǎn)到HTTPS服務(wù)器之后，由于端口和服務(wù)器不同，需要重新完成三次握手，建立TCP連接。

4. TLS完全握手階段一。耗時(shí)至少一個(gè)RTT。

a) 這個(gè)階段主要是完成加密套件的協(xié)商和證書的身份認(rèn)證。

b) 服務(wù)端和瀏覽器會(huì)協(xié)商出相同的密鑰交換算法、對(duì)稱加密算法、內(nèi)容一致性校驗(yàn)算法、證書簽名算法、橢圓曲線(非ECC算法不需要)等。

c) 瀏覽器獲取到證書后需要校驗(yàn)證書的有效性，比如是否過(guò)期，是否撤銷。#p#

5. 解析CA站點(diǎn)的DNS。耗時(shí)一個(gè)RTT。

a) 瀏覽器獲取到證書后，有可能需要發(fā)起OCSP或者CRL請(qǐng)求，查詢證書狀態(tài)。

b) 瀏覽器首先獲取證書里的CA域名。

c) 如果沒有命中緩存，瀏覽器需要解析CA域名的DNS。

6. 三次握手建立CA站點(diǎn)的TCP連接。耗時(shí)一個(gè)RTT。

a) DNS解析到IP后，需要完成三次握手建立TCP連接。

7. 發(fā)起OCSP請(qǐng)求，獲取響應(yīng)。耗時(shí)一個(gè)RTT。

8. 完全握手階段二，耗時(shí)一個(gè)RTT及計(jì)算時(shí)間。

a) 完全握手階段二主要是密鑰協(xié)商。

9. 完全握手結(jié)束后，瀏覽器和服務(wù)器之間進(jìn)行應(yīng)用層(也就是HTTP)數(shù)據(jù)傳輸。

當(dāng)然不是每個(gè)請(qǐng)求都需要增加7個(gè)RTT才能完成HTTPS***請(qǐng)求交互。大概只有不到0.01%的請(qǐng)求才有可能需要經(jīng)歷上述步驟，它們需要滿足如下條件：

1. 必須是***請(qǐng)求。即建立TCP連接后發(fā)起的***個(gè)請(qǐng)求，該連接上的后續(xù)請(qǐng)求都不需要再發(fā)生上述行為。

2. 必須要發(fā)生完全握手，而正常情況下80%的請(qǐng)求能實(shí)現(xiàn)簡(jiǎn)化握手。

3. 瀏覽器需要開啟OCSP或者CRL功能。Chrome默認(rèn)關(guān)閉了ocsp功能，firefox和IE都默認(rèn)開啟。

4. 瀏覽器沒有命中OCSP緩存。Ocsp一般的更新周期是7天，firefox的查詢周期也是7天，也就說(shuō)是7天中才會(huì)發(fā)生一次ocsp的查詢。

5. 瀏覽器沒有命中CA站點(diǎn)的DNS緩存。只有沒命中DNS緩存的情況下才會(huì)解析CA的DNS。

2.2 計(jì)算耗時(shí)增加

上節(jié)還只是簡(jiǎn)單描述了HTTPS關(guān)鍵路徑上必須消耗的純網(wǎng)絡(luò)耗時(shí)，沒有包括非常消耗CPU資源的計(jì)算耗時(shí)，事實(shí)上計(jì)算耗時(shí)也不小(30ms以上)，從瀏覽器和服務(wù)器的角度分別介紹一下：

1， 瀏覽器計(jì)算耗時(shí)

a) RSA證書簽名校驗(yàn)，瀏覽器需要解密簽名，計(jì)算證書哈希值。如果有多個(gè)證書鏈，瀏覽器需要校驗(yàn)多個(gè)證書。

b) RSA密鑰交換時(shí)，需要使用證書公鑰加密premaster。耗時(shí)比較小，但如果手機(jī)性能比較差，可能也需要1ms的時(shí)間。

c) ECC密鑰交換時(shí)，需要計(jì)算橢圓曲線的公私鑰。

d) ECC密鑰交換時(shí)，需要使用證書公鑰解密獲取服務(wù)端發(fā)過(guò)來(lái)的ECC公鑰。

e) ECC密鑰交換時(shí)，需要根據(jù)服務(wù)端公鑰計(jì)算master key。

f) 應(yīng)用層數(shù)據(jù)對(duì)稱加解密。

g) 應(yīng)用層數(shù)據(jù)一致性校驗(yàn)。

2， 服務(wù)端計(jì)算耗時(shí)

a) RSA密鑰交換時(shí)需要使用證書私鑰解密premaster。這個(gè)過(guò)程非常消耗性能。

b) ECC密鑰交換時(shí)，需要計(jì)算橢圓曲線的公私鑰。

c) ECC密鑰交換時(shí)，需要使用證書私鑰加密ECC的公鑰。

d) ECC密鑰交換時(shí)，需要根據(jù)瀏覽器公鑰計(jì)算共享的master key。

e) 應(yīng)用層數(shù)據(jù)對(duì)稱加解密。

f) 應(yīng)用層數(shù)據(jù)一致性校驗(yàn)。

由于客戶端的CPU和操作系統(tǒng)種類比較多，所以計(jì)算耗時(shí)不能一概而論。手機(jī)端的HTTPS計(jì)算會(huì)比較消耗性能，單純計(jì)算增加的延遲至少在50ms以上。PC端也會(huì)增加至少10ms以上的計(jì)算延遲。

服務(wù)器的性能一般比較強(qiáng)，但由于RSA證書私鑰長(zhǎng)度遠(yuǎn)大于客戶端，所以服務(wù)端的計(jì)算延遲也會(huì)在5ms以上。

3 結(jié)束語(yǔ)

本系列的后續(xù)文章將進(jìn)一步解釋針對(duì)性的優(yōu)化措施。