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) (HTTP-Hypertext transfer protocol) 是一種詳細規定了瀏覽器和全球資訊網伺服器之間互相通訊的規則，通過網際網路傳送全球資訊網文檔的資料傳送協議。

（3）https協議需要到ca申請認證，一般免費認證很少，需要交費。

       http是超文字傳輸通訊協定 (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 以上。

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