百度在2015年即完成HTTPS改造，大型的HS對的影那大型網(wǎng)站的網(wǎng)站HTTPS改造中都有哪些實(shí)踐經(jīng)驗，學(xué)院( ?ω?)君特分析這ヽ(′▽?zhuān)?ノ篇干貨滿(mǎn)滿(mǎn)系列內容，實(shí)踐轉自百度運維博客。性能響
1 前言
2 HTTPS 對訪(fǎng)問(wèn)速度的實(shí)踐影響
加解密相關(guān)的網(wǎng)站計算耗時(shí)。
下面分別介紹一下。實(shí)踐(′?_?`)
2.1 網(wǎng)絡(luò )???耗時(shí)增加
由于 HTTP 和 HTTPS 都需要 DNS 解析，并且大部分情況下使用了 DNS 緩存，為了突出對比效果，忽( ?ヮ?)略主域名的 DNSヽ(′▽?zhuān)?ノ 解析時(shí)間。
用戶(hù)使用 HTTP 協(xié)議訪(fǎng)問(wèn)(或者 www.baidu.com) 時(shí)會(huì )有如下網(wǎng)絡(luò )上的交互耗時(shí)：
圖 1 HTTP 首個(gè)請求的網(wǎng)絡(luò )耗時(shí)
可見(jiàn)，用戶(hù)只需要完成 TCP 三次握手建立 TCP 連接就能夠直接發(fā)送 HTTP 請求獲取應用層數據，此外在整個(gè)訪(fǎng)問(wèn)過(guò)程中也沒(méi)有需要消耗計算資源的地方。
接下來(lái)看 HTTPS 的訪(fǎng)問(wèn)過(guò)程，相比 HTTP 要復雜很多，在部分場(chǎng)景下，使用 HTTPS 訪(fǎng)問(wèn)有可能增加 7 個(gè) RTT。如下圖：
圖 2 HTTPS 首次請┐(′?｀)┌求對訪(fǎng)問(wèn)速度的影響
HTTP??S 首次請求需要的網(wǎng)絡(luò )耗時(shí)解釋如下：
1， 三次握手建立 TCP 連接。耗時(shí)一個(gè) RTT。
2， 使用 HTTP 發(fā)起? GE?T 請求，服務(wù)端返回 302 跳轉(′?_?`)到 。需要一個(gè) RTT 以及 302 跳轉延時(shí)。
a) 大部分情況下用戶(hù)不會(huì )手動(dòng)輸入 來(lái)訪(fǎng)問(wèn) HTTPS，服務(wù)端只能返回 302 強制瀏覽器跳轉到 https。
b) 瀏覽器處理 302 跳轉也需要耗時(shí)。
3， 三次握手重新建立 TCP 連接。???耗時(shí)一個(gè)?? RTT。
a) 302 跳轉到 HTTPS 服務(wù)器之(zhi)后，由ヾ(＾-＾)ノ于端??口和服務(wù)器不同，需要重新完成三次握手，建立 TCP 連接。
4， TLS 完全握手階段一。耗??時(shí)至少一個(gè) RTT。
a) 這個(gè)階段主( ???)要是完成加密套件的協(xié)商和證書(shū)的身份認證。
b) 服務(wù)端和瀏覽器會(huì )協(xié)商出相同的密鑰交換算法、對稱(chēng)加??密算法、內容一致性校驗算法、證書(shū)簽名算法、橢圓曲線(xiàn)(非 ECC 算法不需要)等。
c) 瀏覽器獲取到證書(shū)后需要校驗證書(shū)的有效性，比如是否過(guò)期，是否撤銷(xiāo)。
5， 解析 CA 站點(diǎn)的 DNS。耗時(shí)一個(gè) RTT。
a) 瀏覽器獲取到證書(shū)后，有可能需要發(fā)起 OCSP 或者 CRL 請求，查詢(xún)證書(shū)狀態(tài)。
b) 瀏覽器( ???)首先獲取證書(shū)里的 CA 域名(ming)。
c) 如果沒(méi)有命中緩存，瀏覽器需要解析 CA 域名的 DNS。
6， 三次握手建立 CA 站點(diǎn)的 TCP 連接。耗時(shí)一個(gè) RTT。
7， 發(fā)起 OCSP 請求(′ω｀)，獲取??響應。耗時(shí)一個(gè) RTT。
8， 完全握手階段二，耗(′ω｀*)時(shí)一個(gè) RTT 及計算時(shí)間。
a) 完全握手階段二主要是密鑰協(xié)(╯°□°）╯︵ ┻━┻商。
9， 完全握手結束后，瀏覽器和服??務(wù)器之間進(jìn)行應用層(也就是 HTTP)數據傳輸。
1， 必須是首次請ヽ(′▽?zhuān)?ノ求。即建立 TCP 連接后發(fā)起的第一個(gè)請求，該連接上的后續請求都不需要再發(fā)生上述行為。
2， 必須要發(fā)生完全握手，而(er)正(′ω｀)常情況下 80% 的請求能實(shí)現簡(jiǎn)化握手。
3， 瀏覽器需要開(kāi)啟 OCSP 或者 CRL 功能。Chrome 默認關(guān)閉了 ocsp 功能，firefox 和 IE 都默認開(kāi)啟。
4， 瀏覽器沒(méi)有命中 OCSP 緩存。Ocsヽ(′ー｀)ノp 一般的更新周期是 7 天，firefox 的查詢(xún)周期也(╬?益?)是 7 天，也就說(shuō)是 7 天中才會(huì )發(fā)生一次 ocsp 的查詢(xún)。
5， 瀏覽器沒(méi)有命中 CA 站點(diǎn)的 DNS 緩存。只有沒(méi)命中 DNS?? 緩存的情況下才會(huì )解析 CA 的 DNS。
2.2 計算耗時(shí)增加
上節還只是簡(jiǎn)單描述了 HTTPS 關(guān)鍵路徑上必須消耗的純網(wǎng)絡(luò )??耗時(shí)，沒(méi)有包括非常消耗 CPU 資源的計算耗時(shí)，事實(shí)上計??算耗時(shí)也不小(3??0ms 以上)，從瀏覽器和服務(wù)器的角度分別介紹一下：
1， 瀏覽器(qi)計算耗時(shí)
a) RSA 證書(shū)簽名校驗，瀏覽器需要解密簽名，計算證書(shū)哈希值?。如果有多個(gè)證書(shū)鏈，瀏覽器需要校驗多個(gè)證書(shū)。
b) RSA 密鑰交換時(shí)，需要使用證書(shū)公鑰加密 premaster。耗時(shí)比較小，但(′▽?zhuān)?)如果手機性能比較差，可能也需要 1ms 的時(shí)間。
c) ECC 密鑰交換時(shí)，需要(′ω｀)計算橢圓曲線(xiàn)的?公私鑰。
d) ECC 密鑰交換時(shí)，需要使用證書(shū)公鑰解密獲取服務(wù)端發(fā)過(guò)來(lái)的 ECC 公鑰。
e) ECC 密鑰交換時(shí)，需要根據服務(wù)端公鑰計算 master key。
f) 應用層數據對稱(chēng)加解密。
g) 應用層數據一致性校驗。
a) RSA 密鑰交換時(shí)需要使用證書(shū)私鑰解密 premaster。這個(gè)過(guò)程非常消耗性能。
b) ECC 密鑰交換(?Д?)時(shí)，需要計算橢圓曲線(xiàn)的公私鑰。
c) ECC 密鑰交(???)換時(shí)，需要使用證書(shū)私鑰加密 ECC 的公鑰。
d) ECC 密鑰交換時(shí)，需要根據瀏覽器公鑰計算共享的 master key。
e) 應用層數據對稱(chēng)加解密。
f) 應用層數據一致性校驗。
由于客戶(hù)端的 CPU 和操作系統種類(lèi)比較多，所以計算耗時(shí)不能一概而論。手機端的 HTTPS 計算會(huì )比較消耗性能，單純計算(suan)增加的延遲至少在 50ms 以上。PC 端也會(huì )增加至少 10m(?_?;)s 以上的計算延遲。
服務(wù)器的性能一般比較強，但由于 RSA 證書(shū)私鑰長(cháng)度遠大于客戶(hù)端，所以服務(wù)端的計算延遲也會(huì )在 5ms 以上。
3 結束語(yǔ)
