在上一節(jié)我們介紹了 OCSP stapling。本節(jié)我們介紹另一種 HTTPS 性能優(yōu)化的技巧，TLS session resumption。

一個完整的 TLS 握手需要兩次：

1. Client 發(fā)送 ClientHello；Server 回復(fù) ServerHello
2. Client 回復(fù)最終確定的 Key，F(xiàn)inished；Server 回復(fù) Finished
3. 握手完畢，Client 發(fā)送加密后的 HTTP 請求；Server 回復(fù)加密后的 HTTP 響應(yīng)

這一過程的花費是 2RTT（Round-Trip-Time）。意味著僅僅部署了 HTTPS，就會讓你的 Web 應(yīng)用的響應(yīng)都慢上 2RTT。 花在信息傳遞過程中的延遲在整個響應(yīng)時間的占比不容小覷，看看國內(nèi)有多少 CDN 廠商就知道了。

為什么強調(diào)是“完整的”呢？因為通過 TLS session resumption，我們可以復(fù)用未過期的會話，把 RTT 減低到 1，甚至更低。

Session ID

Session ID 是最早的 TLS session resumption 方案。除了某些上古瀏覽器，大部分客戶端都支持它。 Client 發(fā)送的 ClientHello 當(dāng)中，就包含了一個 Session ID。服務(wù)器接收到 Session ID 之后，會返回之前存儲的 SSL 會話。這么一來， 重建連接就只需一次 TLS 握手。

1. Client 發(fā)送 ClientHello（包含 Session ID）；Server 回復(fù) ServerHello 和 Finished
2. 握手完畢，Client 發(fā)送加密后的 HTTP 請求；Server 回復(fù)加密后的 HTTP 響應(yīng)

Nginx 自身支持 Session ID，但有個問題，它的會話最多只能存儲在共享內(nèi)存里面。服務(wù)器和客戶端上次握手建立的會話，只有某個服務(wù)器自己 認(rèn)得，換個服務(wù)器就忘光光了。當(dāng)然你也可以要求負(fù)載均衡的時候只用 IP hash，盡管在實際情況中這么做不太現(xiàn)實。

OpenResty 提供了 ?ssl_session_fetch_by_lua*? 和 ?ssl_session_store_by_lua*? 這兩個支持協(xié)程的階段， 以及跟 Session id 相關(guān)的 ?ngx.ssl.session? 模塊， 把存儲的決定權(quán)交給開發(fā)者手中。 你可以把 session 放到獨立的 Redis 或 Memcached 服務(wù)器上。

Session Tickets

不過你可能已經(jīng)不需要額外折騰 ?ssl_session_*? 的代碼。因為 Session ID 已經(jīng)過時了。 TLSv1.1 提供了名為 Session Tickets 的拓展，用來代替之前的 Session ID 方案。

Session ID 方案要求服務(wù)端記住會話狀態(tài)，有違于 HTTP 服務(wù)無狀態(tài)的特點。Session Tickets 方案旨在解決這個問題。

Session Tickets 跟 Session ID 差不多，只是有點關(guān)鍵上的不同：現(xiàn)在輪到由客戶端記住會話狀態(tài)。

1. Client 發(fā)送 ClientHello（包含 Session Ticket）；Server 回復(fù) ServerHello 和 Finished
2. 握手完畢，Client 發(fā)送加密后的 HTTP 請求；Server 回復(fù)加密后的 HTTP 響應(yīng)

服務(wù)端僅需記住當(dāng)初用于加密返回給客戶端的 Ticket 的密鑰，以解密客戶端握手時發(fā)送的 Session Ticket。 這么一來，只要在不同的服務(wù)器間共享同一個密鑰，就能避免會話丟失的問題，不再需要獨立的 Redis 或 Memcached 服務(wù)器來存儲會話信息。

在高興之余看下兩個壞消息：

1. Session Tickets 不具有前向安全性，所以你需要定期輪換服務(wù)端用于加密的密鑰。
2. 只有現(xiàn)代瀏覽器才支持這一 TLS 拓展。比如 Win7 下的 IE 就不支持。

對于 Nginx，你需要關(guān)注兩個指令：?ssl_session_tickets? 和 ?ssl_session_ticket_file?。 前者啟用 Session Tickers 支持，后者決定具體用到的密鑰。如果不配置后者，則使用隨機(jī)生成的密鑰。這意味著每臺服務(wù)器返回的 session ticket 會不一樣。

如果你需要管理一整套 OpenResty 集群，可以看下 lua-ssl-nginx-module 這個模塊，它可以實現(xiàn)集群層面上的密鑰輪換（且無需重啟 Worker 進(jìn)程）。 盡管 lua-ssl-nginx-module 只提供了跟 memcache 配套使用的接口，但是參照 ?lualib/ngx/ssl/session/ticket/key_rotation.lua?，實現(xiàn)自己的一套密鑰存儲/同步方案不過是照葫蘆畫瓢。 關(guān)鍵在于 ?lualib/ngx/ssl/session/ticket.lua? 其中的這兩個函數(shù)：

1. ?update_ticket_encryption_key(key, nkeys)?：插入新的密鑰，之前的密鑰會被輪轉(zhuǎn)成解密密鑰，最多保留 nkeys 個密鑰。
2. ?update_last_ticket_decryption_key(key)?：替換當(dāng)前的解密密鑰。

0 RTT!?

既然通過 Session ID/Tickets，我們已經(jīng)把 RTT 減到了 1，能不能更進(jìn)一步，減到 0？ 初看像是天方夜譚，但最新的 TLSv1.3 確實允許做到這一點。

在繼續(xù)之前先看下 TLSv1.3 的支持情況：Nginx 需要 1.13+ 的版本，外加 OpenSSL 1.1.1?？蛻舳朔矫妫刂沟綄懽鞅疚牡臅r間，F(xiàn)irefox 和 Chrome 的 nightly build 版本均支持。

0 RTT 是 TLSv1.3 的可選功能?？蛻舳撕头?wù)器第一次建立會話時，會生成一個 PSK（pre-shared key）。服務(wù)器會用 ticket key 去加密 PSK，作為 Session Ticket 返回。 客戶端再次和服務(wù)器建立會話時，會先用 PSK 去加密 HTTP 請求，然后把加密后的內(nèi)容發(fā)給服務(wù)器。服務(wù)器解密 PSK，然后再用 PSK 去解密 HTTP 請求，并加密 HTTP 響應(yīng)。

1. Client 發(fā)送 ClientHello（包含 PSK）和加密后的 HTTP 請求；Server 回復(fù) ServerHello 和 Finished 和加密后的 HTTP 響應(yīng)。

這就完事了。

由于 HTTPS 握手已經(jīng)跟 HTTP 請求合并到一起，確實是當(dāng)之無愧的 0 RTT 呢。

在高興之余看下兩個壞消息：

1. PSK 不具有前向安全性，所以你依然需要定期輪換服務(wù)端用于加密的 ticket key。
2. 0 RTT 不提供 non-replayable 的保障，所以需要更上層的 HTTP 協(xié)議提供防重放的保障。比如只在冪等的 HTTP 方法中啟用 0 RTT，或者實現(xiàn)額外的時序標(biāo)記。