HTTPS對網站(zhàn)性能SEO有哪些影(yǐng)響？

1 前言

HTTPS在保護用戶隐私，防止流量劫持方面發揮着非常關鍵的作(zuò)用，但(dàn)與此同時，HTTPS也會降低用戶訪問(wèn)速度，增加網站(zhàn)服務器的計(jì)算資源消耗。

本文主要介紹https對用戶體(tǐ)驗的影(yǐng)響。

本文最早發表于百度運維部官方博客

2 HTTPS對訪問(wèn)速度的影(yǐng)響

在介紹速度優化策略之前，先來(lái)看(kàn)下HTTPS對速度有什麽影(yǐng)響。影(yǐng)響主要來(lái)自(zì)兩方面：

1. 協議(yì)交互所增加的網絡RTT(round trip time)。

2. 加解密相(xiàng)關的計(jì)算耗時。

下面分(fēn)别介紹一下。

2.1 網絡耗時增加

由于 HTTP和HTTPS都(dōu)需要DNS解析，并且大(dà)部分(fēn)情況下使用了DNS緩存，爲了突出對比效果，忽略主域名的DNS解析時間。

用戶使用HTTP協議(yì)訪問(wèn)http://www.baidu.com(或者www.baidu.com)時會有如(rú)下網絡上的交互耗時：

,

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

接下來(lái)看(kàn)HTTPS的訪問(wèn)過程，相(xiàng)比HTTP要複雜很多，在部分(fēn)場景下，使用HTTPS訪問(wèn)有可(kě)能增加7個RTT。如(rú)下圖：

,

HTTPS首次請(qǐng)求需要的網絡耗時解釋如(rú)下：

1. 三次握手建立TCP連接。耗時一個RTT。

2. 使用HTTP發起GET請(qǐng)求，服務端返回302跳(tiào)轉到https://www.baidu.com。需要一個RTT以及302跳(tiào)轉延時。

a) 大(dà)部分(fēn)情況下用戶不會手動輸入https://www.baidu.com來(lái)訪問(wèn)HTTPS，服務端隻能返回302強制浏覽器跳(tiào)轉到https。

b) 浏覽器處理(lǐ)302跳(tiào)轉也需要耗時。

3. 三次握手重新建立TCP連接。耗時一個RTT。

a) 302跳(tiào)轉到HTTPS服務器之後，由于端口和服務器不同，需要重新完成三次握手，建立TCP連接。

4. TLS完全握手階段一。耗時至少一個RTT。

a) 這個階段主要是完成加密套件(jiàn)的協商和證書(shū)的身(shēn)份認證。

b) 服務端和浏覽器會協商出相(xiàng)同的密鑰交換算法、對稱加密算法、内容一緻性校(xiào)驗算法、證書(shū)簽名算法、橢圓曲線(非ECC算法不需要)等。

c) 浏覽器獲取到證書(shū)後需要校(xiào)驗證書(shū)的有效性，比如(rú)是否過期，是否撤銷。

5. 解析CA站(zhàn)點的DNS。耗時一個RTT。

a) 浏覽器獲取到證書(shū)後，有可(kě)能需要發起OCSP或者CRL請(qǐng)求，查詢證書(shū)狀态。

b) 浏覽器首先獲取證書(shū)裡(lǐ)的CA域名。

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

6. 三次握手建立CA站(zhàn)點的TCP連接。耗時一個RTT。

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

7. 發起OCSP請(qǐng)求，獲取響應。耗時一個RTT。

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

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

9. 完全握手結束後，浏覽器和服務器之間進行應用層(也就(jiù)是HTTP)數據傳輸。

當然不是每個請(qǐng)求都(dōu)需要增加7個RTT才能完成HTTPS首次請(qǐng)求交互。大(dà)概隻有不到0.01%的請(qǐng)求才有可(kě)能需要經曆上述步驟，它們需要滿足如(rú)下條件(jiàn)：

1. 必須是首次請(qǐng)求。即建立TCP連接後發起的**個請(qǐng)求，該連接上的後續請(qǐng)求都(dōu)不需要再發生(shēng)上述行爲。

2. 必須要發生(shēng)完全握手，而正常情況下80%的請(qǐng)求能實現簡化握手。

3. 浏覽器需要開啓OCSP或者CRL功能。Chrome默認關閉了ocsp功能，firefox和IE都(dōu)默認開啓。

4. 浏覽器沒有命中OCSP緩存。Ocsp一般的更新周期是7天，firefox的查詢周期也是7天，也就(jiù)說(shuō)是7天中才會發生(shēng)一次ocsp的查詢。

5. 浏覽器沒有命中CA站(zhàn)點的DNS緩存。隻有沒命中DNS緩存的情況下才會解析CA的DNS。

2.2 計(jì)算耗時增加

上節還(hái)隻是簡單描述了HTTPS關鍵路(lù)徑上必須消耗的純網絡耗時，沒有包括非常消耗CPU資源的計(jì)算耗時，事(shì)實上計(jì)算耗時也不小(30ms以上)，從(cóng)浏覽器和服務器的角度分(fēn)别介紹一下：

1， 浏覽器計(jì)算耗時

a) RSA證書(shū)簽名校(xiào)驗，浏覽器需要解密簽名，計(jì)算證書(shū)哈希值。如(rú)果有多個證書(shū)鏈，浏覽器需要校(xiào)驗多個證書(shū)。

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

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

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

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

f) 應用層數據對稱加解密。

g) 應用層數據一緻性校(xiào)驗。

2， 服務端計(jì)算耗時

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

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

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

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

e) 應用層數據對稱加解密。

f) 應用層數據一緻性校(xiào)驗。

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

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