久草中文在线观看_久久精品中文字幕一区_亚洲日本欧美日韩中文字幕_熟妇人妻无乱码中文字幕真矢织江

    1 前言

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

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

    2 HTTPS 對訪問速度的影響

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

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

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

    下面分別介紹一下。

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

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

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

    圖 1 HTTP 首個(gè)請求的網(wǎng)絡(luò)耗時(shí)

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

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

    圖 2 HTTPS 首次請求對訪問速度的影響

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

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

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

    a） 大部分情況下用戶不會(huì)手動(dòng)輸入 https://www.baidu.com 來訪問 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é)商出相同的密鑰交換算法、對稱加密算法、內(nèi)容一致性校驗(yàn)算法、證書簽名算法、橢圓曲線（非 ECC 算法不需要）等。

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

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

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

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

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

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

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

    7， 發(fā)起 OCSP 請求，獲取響應(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è)請求都需要增加 7 個(gè) RTT 才能完成 HTTPS 首次請求交互。大概只有不到 0.01% 的請求才有可能需要經(jīng)歷上述步驟，它們需要滿足如下條件：

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

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

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

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

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

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

    上節(jié)還只是簡單描述了 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ā)過來的 ECC 公鑰。

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

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

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

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

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

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

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

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

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

    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 證書私鑰長度遠(yuǎn)大于客戶端，所以服務(wù)端的計(jì)算延遲也會(huì)在 5ms 以上。