Web 性能之 TLS

SSL/TLS

SSL（ Secure Sockets Layer，安全套接字層）協議最初是網景公司爲了保障網上交易安全而開發的，該協議經過加密來保護客戶我的資料，經過認證和完整性檢查來確保交易安全。SSL 不會影響上層協議（如 HTTP、電子郵件、即時通信），但可以保證上層協議的網絡通訊安全。

鑑於 SSL 協議是網景公司專有的， IETF 成立了一個小組負責標準化該協議，後來就有了 RFC 2246，即 TLS 1.0，也就是 SSL 3.0 的升級版。

TLS 協議的目標是爲在它之上運行的應用提供三個基本服務：

1. 加密：非對稱加密、對稱加密
2. 身份驗證：驗證機構信任鏈
3. 數據完整性：TLS 使用 MAC（Message Authentication Code，消息認證碼）簽署每一條消息，MAC 算法是一個單向加密的散列函數（本質上是一個校驗和），密鑰由鏈接雙方協商肯定。接收端經過計算和驗證這個MAC 值來判斷消息的完整性和可靠性。

TLS 握手

客戶端與服務器在經過 TLS 交換數據以前，必須協商創建加密信道。協商內容包括 TLS 版本、加密套件，必要時還會驗證證書。

上圖的關鍵點有：

1. 三次握手
2. 協商使用的 TLS 版本、加密套件等內容，驗證證書
3. 使用非對稱密鑰交換對稱密鑰，驗證 MAC
4. 使用對稱密鑰開始通訊

應用層協議協商

雖然使用 TLS 保障了可靠性，但咱們還須要一種機制來協商協議。做爲 HTTPS 會話，固然能夠利用 HTTP 的 Upgrade 機制來協商，但這會致使一次額外的往返，形成延遲。顧名思義，應用層協議協商（ALPN， Application Layer Protocol Negotiation）做爲TLS 擴展，讓咱們能在 TLS 握手的同時協商應用協議，從而省掉了 HTTP的 Upgrade 機制所需的額外往返時間。

服務器名稱指示

網絡上能夠創建 TCP 鏈接的任意兩端均可以創建加密 TLS 信道，客戶端只需知道另外一端的 IP 地址便可創建鏈接並進行 TLS 握手。然而，若是服務器想在一個 IP 地址爲多個站點提供服務，而每一個站點都擁有本身的 TLS 證書，那怎麼辦？爲了解決這個問題， SNI（Server Name Indication，服務器名稱指示）擴展被引入 TLS 協議，該擴展容許客戶端在握手之初就指明要鏈接的主機名。

TLS 會話恢復

完整 TLS 握手會帶來額外的延遲和計算量，從而給全部依賴安全通訊的應用形成嚴重的性能損失。爲了挽回某些損失，TLS 提供了恢復功能，即在多個鏈接間共享協商後的安全密鑰。

會話標識符

會話標識符：服務器會爲每一個客戶端保存一個會話 ID 和協商後的會話參數。相應地，客戶端也能夠保存會話 ID 信息，並將該 ID 包含在後續會話的消息中，從而告訴服務器本身還記着上次握手協商後的加密套件和密鑰，能夠重用這些數據。

假設客戶端和服務器均可以在本身的緩存中找到共享的會話 ID 參數，那麼就能夠進行簡短握手。不然，就要從新啓動一次全新的會話協商，生成新的會話 ID。

藉助會話標識符能夠節省一次往返，還能夠省掉用於協商共享加密密鑰的公鑰加密計算。

但因爲服務器必須爲每一個客戶端都建立和維護一段會話緩存，所以「會話標識符」機制在實踐中也會遇到問題，特別是對那些天天都要接待幾萬甚至幾百萬獨立鏈接的服務器來講，問題就更多了。因爲每一個打開的 TLS 鏈接都要佔用內存，所以須要一套會話 ID 緩存和清除策略，對於擁有不少服務器並且爲得到最佳性能必須使用共享 TLS 會話緩存的熱門站點而言，部署這些策略絕非易事。

會話記錄單

爲了解決上述服務器端部署 TLS 會話緩存的問題，可使用「會話記錄單」機制。它的原理很簡單：既然保存會話數據對服務器負擔很大，那麼把它存放在客戶端便可。具體過程以下：若是客戶端代表其支持會話記錄單，則服務器能夠在完整 TLS 握手的最後一次交換中添加一條「新會話記錄單」（New Session Ticket）記錄，包含只有服務器知道的安全密鑰加密過的全部會話數據，而後，客戶端將這個會話記錄單保存起來，在後續會話的 ClientHello 消息中，能夠將其包含在 SessionTicket 擴展中。這樣，全部會話數據只保存在客戶端，而因爲數據被加密過，且密鑰只有服務器知道，所以仍然是安全的。

這裏所說的會話標識符和會話記錄單機制，也常常被人稱爲「會話緩存」或「無狀態恢復」機制。

信任鏈與證書頒發機構

所謂信任鏈，即：A 信任 B，B 信任 C，那麼 A 也能夠信任 C。

對於 Web 以及瀏覽器而言，它們能夠信任的有：

1. 手動指定/導入的證書
2. 證書頒發機構（CA，Certificate Authority）
3. 瀏覽器和操做系統。每一個操做系統和大多數瀏覽器都會內置一個知名證書頒發機構的名單。

證書撤銷

有時候，出於種種緣由，證書頒發者須要撤銷或做廢證書，好比證書的私鑰再也不安全、證書頒發機構自己被冒名頂替，或者其它緣由。

證書撤銷名單

CRL（Certificate Revocation List，證書撤銷名單）是一種檢查全部證書狀態的機制：每一個證書頒發機構維護並按期發佈已撤銷證書的序列號名單。這樣，任何想驗證證書的人均可如下載撤銷名單，檢查相應證書是否榜上有名。若是有，說明證書已經被撤銷了。

但 CRL 也存在一些問題：

1. CRL 名單會隨着要撤銷的證書增多而變長，每一個客戶端都必須取得包含全部序列號的完整名單
2. 沒有辦法當即更新剛剛被撤銷的證書序列號，好比客戶端先緩存了 CRL，以後某證書被撤銷，那到緩存過時以前，該證書將一直被視爲有效

在線證書狀態協議

爲解決 CRL 機制的上述問題，OCSP（Online Certificate StatusProtocol，在線證書狀態協議）提供了一種實時檢查證書狀態的機制。與 CRL 不一樣，OCSP 支持驗證端直接查詢證書數據庫中的序列號，從而驗證證書鏈是否有效。總之，OCSP 佔用帶寬更少，支持實時驗證。

但 OCSP 也存在問題：

1. 證書頒發機構必須處理實時查詢；
2. 證書頒發機構必須確保隨時隨地能夠訪問；
3. 客戶端在進一步協商以前阻塞 OCSP 請求；
4. 因爲證書頒發機構知道客戶端要訪問哪一個站點，所以實時 OCSP 請求可能會泄露客戶端的隱私

所以，實踐中， CRL 和 OCSP 機制是互補存在的，大多數證書既提供指令也支持查詢。

TLS 結構

與位於其下的 IP 或 TCP 層沒有什麼不一樣， TLS 會話中交換的全部數據一樣使用規格明確的協議進行分幀：

交付應用數據的典型流程以下：

1. 記錄協議接收應用數據
2. 接收到的數據被切分爲塊：最大爲每條記錄 2^14 字節，即 16 KB
3. 壓縮應用數據（可選）
4. 添加 MAC（ Message Authentication Code）或 HMAC
5. 使用商定的加密套件加密數據

以上幾步完成後，加密數據就會被交給 TCP 層傳輸，接收到拿到數據後再進行解密等操做。

參考：《Web 性能權威指南》