1 前言

上文講到 HTTPS 對用戶訪問速度的影響。

本文就為大傢介紹 HTTPS 在訪問速度，計算性能，安全等方面基於協議和配置的優化。

2 HTTPS 訪問速度優化

2.1 Tcp fast open

HTTPS 和 HTTP 使用 TCP 協議進行傳輸，也就意味著必須通過三次握手建立 TCP 連接，但一個 RTT 的時間內隻傳輸一個 syn 包是不是太浪費？能不能在 syn 包發出的同時捎上應用層的數據？其實是可以的，這也是 tcp fast open 的思路，簡稱 TFO。具體原理可以參考 rfc7413。

遺憾的是 TFO 需要高版本內核的支持，linux 從 3.7 以後支持 TFO，但是目前的 windows 系統還不支持 TFO，所以隻能在公司內部服務器之間發揮作用。

2.2 HSTS

前面提到過將用戶 HTTP 請求 302 跳轉到 HTTPS，這會有兩個影響：

1、不安全，302 跳轉不僅暴露瞭用戶的訪問站點，也很容易被中間者支持。

2、降低訪問速度，302 跳轉不僅需要一個 RTT，瀏覽器執行跳轉也需要執行時間。

由於 302 跳轉事實上是由瀏覽器觸發的，服務器無法完全控制，這個需求導致瞭 HSTS 的誕生：

HSTS(HTTP Strict Transport Security)。服務端返回一個 HSTS 的 http header，瀏覽器獲取到 HSTS 頭部之後，在一段時間內，不管用戶輸入還是，都會默認將請求內部跳轉成https://。

Chrome, firefox, ie 都支持瞭 HSTS（/#feat=stricttransportsecurity）。

2.3 Session resume

Session resume 顧名思義就是復用 session，實現簡化握手。復用 session 的好處有兩個：

1、減少瞭 CPU 消耗，因為不需要進行非對稱密鑰交換的計算。

2、提升訪問速度，不需要進行完全握手階段二，節省瞭一個 RTT 和計算耗時。

TLS 協議目前提供兩種機制實現 session resume，分別介紹一下。

2.3.1 Session cache

Session cache 的原理是使用 client hello 中的 session id 查詢服務端的 session cache, 如果服務端有對應的緩存，則直接使用已有的 session 信息提前完成握手，稱為簡化握手。

Session cache 有兩個缺點：

1、需要消耗服務端內存來存儲 session 內容。

2、目前的開源軟件包括 nginx,apache 隻支持單機多進程間共享緩存，不支持多機間分佈式緩存，對於百度或者其他大型互聯網公司而言，單機 session cache 幾乎沒有作用。

Session cache 也有一個非常大的優點：

session id 是 TLS 協議的標準字段，市面上的瀏覽器全部都支持 session cache。

百度通過對 TLS 握手協議及服務器端實現的優化，已經支持全局的 session cache，能夠明顯提升用戶的訪問速度，節省服務器計算資源。

2.3.2 Session ticket

上節提到瞭 session cache 的兩個缺點，session ticket 能夠彌補這些不足。

Session ticket 的原理參考 RFC4507。簡述如下：

server 將 session 信息加密成 ticket 發送給瀏覽器，瀏覽器後續握手請求時會發送 ticket，server 端如果能成功解密和處理 ticket，就能完成簡化握手。

顯然，session ticket 的優點是不需要服務端消耗大量資源來存儲 session 內容。

Session ticket 的缺點：

1、session ticket 隻是 TLS 協議的一個擴展特性，目前的支持率不是很廣泛，隻有 60% 左右。

2、session ticket 需要維護一個全局的 key 來加解密，需要考慮 KEY 的安全性和部署效率。

總體來講，session ticket 的功能特性明顯優於 session cache。希望客戶端實現優先支持 session ticket。

2.4 Ocsp stapling

Ocsp 全稱在線證書狀態檢查協議 (rfc6960)，用來向 CA 站點查詢證書狀態，比如是否撤銷。通常情況下，瀏覽器使用 OCSP 協議發起查詢請求，CA 返回證書狀態內容，然後瀏覽器接受證書是否可信的狀態。

這個過程非常消耗時間，因為 CA 站點有可能在國外，網絡不穩定，RTT 也比較大。那有沒有辦法不直接向 CA 站點請求 OCSP 內容呢？ocsp stapling 就能實現這個功能。

詳細介紹參考 RFC6066 第 8 節。簡述原理就是瀏覽器發起 client hello 時會攜帶一個 certificate status request 的擴展，服務端看到這個擴展後將 OCSP 內容直接返回給瀏覽器，完成證書狀態檢查。

由於瀏覽器不需要直接向 CA 站點查詢證書狀態，這個功能對訪問速度的提升非常明顯。

Nginx 目前已經支持這個 ocsp stapling file，隻需要配置 ocsp stapling file 的指令就能開啟這個功能：

• ssl_stapling on;ssl_stapling_file ocsp.staple;

2.5 False start

通常情況下，應用層數據必須等完全握手全部結束之後才能傳輸。這個其實比較浪費時間，那能不能類似 TFO 一樣，在完全握手的第二個階段將應用數據一起發出來呢？google 提出瞭 false start 來實現這個功能。詳細介紹參考https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00。

簡單概括 False start 的原理就是在 client_key_exchange 發出時將應用層數據一起發出來，能夠節省一個 RTT。

False start 依賴於 PFS（perfect forward secrecy 完美前向加密），而 PFS 又依賴於 DHE 密鑰交換系列算法（DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA），所以盡量優先支持 ECDHE 密鑰交換算法實現 false start。

2.6 使用 SPDY 或者 HTTP2

SPDY 是 google 推出的優化 HTTP 傳輸效率的協議（https:///spdy），它基本上沿用瞭 HTTP 協議的語義, 但是通過使用幀控制實現瞭多個特性，顯著提升瞭 HTTP 協議的傳輸效率。

SPDY 最大的特性就是多路復用，能將多個 HTTP 請求在同一個連接上一起發出去，不像目前的 HTTP 協議一樣，隻能串行地逐個發送請求。Pipeline 雖然支持多個請求一起發送，但是接收時依然得按照順序接收，本質上無法解決並發的問題。

HTTP2 是 IETF 2015 年 2 月份通過的 HTTP 下一代協議，它以 SPDY 為原型，經過兩年多的討論和完善最終確定。

本文就不過多介紹 SPDY 和 HTTP2 的收益，需要說明兩點：

1、SPDY 和 HTTP2 目前的實現默認使用 HTTPS 協議。

2、SPDY 和 HTTP2 都支持現有的 HTTP 語義和 API，對 WEB 應用幾乎是透明的。

Google 宣佈 chrome 瀏覽器 2016 年將放棄 SPDY 協議，全面支持 HTTP2，但是目前國內部分瀏覽器廠商進度非常慢，不僅不支持 HTTP2，連 SPDY 都沒有支持過。

百度服務端和百度手機瀏覽器現在都已經支持 SPDY3.1 協議。