HTTP與HTTPS對訪問速度（性能）的影響

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 對速度有什麼影響。影響主要來自兩方面：

1. 協議交互所增長的網絡 RTT(round trip time)。
2. 加解密相關的計算耗時。

下面分別介紹一下。

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 以上。