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 頭部之後，在一段時間內，不管用戶輸入www.baidu.com還是http://www.baidu.com，都會默認將請求內部跳轉成https://www.baidu.com。
Chrome, firefox, ie 都支持了 HSTS（http://caniuse.com/#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 內容直接返回給浏覽器，完成證書狀態檢