1 前言
HTTPS 在保護用戶隱私，防止流量劫持方面發揮著非常關鍵的作用，但與此同時，HTTPS 也會降低用戶訪問速度，增加網站服務器的計算資源消耗。
本文主要介紹 https 對用戶體驗的影響。
2 HTTP與HTTPS的概念和區別
（1）HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。 它是一個URI scheme（抽象標識符體系），句法類同http:體系。用于安全的HTTP數據傳輸。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默認端口及一個加密/身份驗證層（在HTTP與TCP之間）。這個系統的最初研發由網景公司進行，提供了身份驗證與加密通訊方法，現在它被廣泛用于萬維網上安全敏感的通訊，例如交易支付方面。
（2）超文本傳輸協議 (HTTP-Hypertext transfer protocol) 是一種詳細規定了瀏覽器和萬維網服務器之間互相通信的規則，通過因特網傳送萬維網文檔的數據傳送協議。
（3）https協議需要到ca申請證書，一般免費證書很少，需要交費。
http是超文本傳輸協議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協議
http和https使用的是完全不同的連接方式，用的端口也不一樣,前者是80,后者是443。
http的連接很簡單,是無狀態的，HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議 ，要比http協議安全
3 HTTPS 對訪問速度的影響
在介紹速度優化策略之前，先來看下 HTTPS 對速度有什么影響。影響主要來自兩方面：
協議交互所增加的網絡 RTT(round trip time)。
加解密相關的計算耗時。
下面分別介紹一下。
3.1 網絡耗時增加
由于 HTTP 和 HTTPS 都需要 DNS 解析，并且大部分情況下使用了 DNS 緩存，為了突出對比效果，忽略主域名的 DNS 解析時間。
用戶使用 HTTP 協議訪問http://www.baidu.com(或者 www.baidu.com) 時會有如下網絡上的交互耗時：
圖 1 HTTP 首個請求的網絡耗時
可見，用戶只需要完成 TCP 三次握手建立 TCP 連接就能夠直接發送 HTTP 請求獲取應用層數據，此外在整個訪問過程中也沒有需要消耗計算資源的地方。
接下來看 HTTPS 的訪問過程，相比 HTTP 要復雜很多，在部分場景下，使用 HTTPS 訪問有可能增加 7 個 RTT。如下圖：
圖 2 HTTPS 首次請求對訪問速度的影響
HTTPS 首次請求需要的網絡耗時解釋如下：
1，? ? 三次握手建立 TCP 連接。耗時一個 RTT。
2，? ? 使用 HTTP 發起 GET 請求，服務端返回 302 跳轉到 https://www.baidu.com。需要一個 RTT 以及 302 跳轉延時。
a)? ? ? 大部分情況下用戶不會手動輸入 https://www.baidu.com 來訪問 HTTPS，服務端只能返回 302 強制瀏覽器跳轉到 https。
b)? ? ? 瀏覽器處理 302 跳轉也需要耗時。
3，? ? 三次握手重新建立 TCP 連接。耗時一個 RTT。
a)? ? ? 302 跳轉到 HTTPS 服務器之后，由于端口和服務器不同，需要重新完成三次握手，建立 TCP 連接。
4，? ? TLS 完全握手階段一。耗時至少一個 RTT。
a)? ? ? 這個階段主要是完成加密套件的協商和證書的身份認證。
b)? ? ? 服務端和瀏覽器會協商出相同的密鑰交換算法、對稱加密算法、內容一致性校驗算法、證書簽名算法、橢圓曲線（非 ECC 算法不需要）等。
c)? ? ? 瀏覽器獲取到證書后需要校驗證書的有效性，比如是否過期，是否撤銷。
5，? ? 解析 CA 站點的 DNS。耗時一個 RTT。
a)? ? ? 瀏覽器獲取到證書后，有可能需要發起 OCSP 或者 CRL 請求，查詢證書狀態。
b)? ? ? 瀏覽器首先獲取證書里的 CA 域名。
c)? ? ? 如果沒有命中緩存，瀏覽器需要解析 CA 域名的 DNS。
6，? ? 三次握手建立 CA 站點的 TCP 連接。耗時一個 RTT。
a)? ? ? DNS 解析到 IP 后，需要完成三次握手建立 TCP 連接。
7，? ? 發起 OCSP 請求，獲取響應。耗時一個 RTT。
8，? ? 完全握手階段二，耗時一個 RTT 及計算時間。
a)? ? ? 完全握手階段二主要是密鑰協商。
9，? ? 完全握手結束后，瀏覽器和服務器之間進行應用層（也就是 HTTP）數據傳輸。
當然不是每個請求都需要增加 7 個 RTT 才能完成 HTTPS 首次請求交互。大概只有不到 0.01% 的請求才有可能需要經歷上述步驟，它們需要滿足如下條件：
1，? ? 必須是首次請求。即建立 TCP 連接后發起的第一個請求，該連接上的后續請求都不需要再發生上述行為。
2，? ? 必須要發生完全握手，而正常情況下 80% 的請求能實現簡化握手。
3，? ? 瀏覽器需要開啟 OCSP 或者 CRL 功能。Chrome 默認關閉了 ocsp 功能，firefox 和 IE 都默認開啟。
4，? ? 瀏覽器沒有命中 OCSP 緩存。Ocsp 一般的更新周期是 7 天，firefox 的查詢周期也是 7 天，也就說是 7 天中才會發生一次 ocsp 的查詢。
5，? ? 瀏覽器沒有命中 CA 站點的 DNS 緩存。只有沒命中 DNS 緩存的情況下才會解析 CA 的 DNS。
3.2 計算耗時增加
上節還只是簡單描述了 HTTPS 關鍵路徑上必須消耗的純網絡耗時，沒有包括非常消耗 CPU 資源的計算耗時，事實上計算耗時也不小（30ms 以上），從瀏覽器和服務器的角度分別介紹一下：
1，? ? 瀏覽器計算耗時
a)? ? ? RSA 證書簽名校驗，瀏覽器需要解密簽名，計算證書哈希值。如果有多個證書鏈，瀏覽器需要校驗多個證書。
b)? ? ? RSA 密鑰交換時，需要使用證書公鑰加密 premaster。耗時比較小，但如果手機性能比較差，可能也需要 1ms 的時間。
c)? ? ? ECC 密鑰交換時，需要計算橢圓曲線的公私鑰。
d)? ? ? ECC 密鑰交換時，需要使用證書公鑰解密獲取服務端發過來的 ECC 公鑰。
e)? ? ? ECC 密鑰交換時，需要根據服務端公鑰計算 master key。
f)? ? ? 應用層數據對稱加解密。
g)? ? ? 應用層數據一致性校驗。
2，? ? 服務端計算耗時
a)? ? ? RSA 密鑰交換時需要使用證書私鑰解密 premaster。這個過程非常消耗性能。
b)? ? ? ECC 密鑰交換時，需要計算橢圓曲線的公私鑰。
c)? ? ? ECC 密鑰交換時，需要使用證書私鑰加密 ECC 的公鑰。
d)? ? ? ECC 密鑰交換時，需要根據瀏覽器公鑰計算共享的 master key。
e)? ? ? 應用層數據對稱加解密。
f)? ? ? 應用層數據一致性校驗。
由于客戶端的 CPU 和操作系統種類比較多，所以計算耗時不能一概而論。手機端的 HTTPS 計算會比較消耗性能，單純計算增加的延遲至少在 50ms 以上。PC 端也會增加至少 10ms 以上的計算延遲。
服務器的性能一般比較強，但由于 RSA 證書私鑰長度遠大于客戶端，所以服務端的計算延遲也會在 5ms 以上。
