在上一節(jié)我們介紹了 OCSP stapling。本節(jié)我們介紹另一種 HTTPS 性能優(yōu)化的技巧,TLS session resumption。
一個(gè)完整的 TLS 握手需要兩次:
這一過(guò)程的花費(fèi)是 2RTT(Round-Trip-Time)。意味著僅僅部署了 HTTPS,就會(huì)讓你的 Web 應(yīng)用的響應(yīng)都慢上 2RTT。 花在信息傳遞過(guò)程中的延遲在整個(gè)響應(yīng)時(shí)間的占比不容小覷,看看國(guó)內(nèi)有多少 CDN 廠商就知道了。
為什么強(qiáng)調(diào)是“完整的”呢?因?yàn)橥ㄟ^(guò) TLS session resumption,我們可以復(fù)用未過(guò)期的會(huì)話,把 RTT 減低到 1,甚至更低。
Session ID 是最早的 TLS session resumption 方案。除了某些上古瀏覽器,大部分客戶端都支持它。 Client 發(fā)送的 ClientHello 當(dāng)中,就包含了一個(gè) Session ID。服務(wù)器接收到 Session ID 之后,會(huì)返回之前存儲(chǔ)的 SSL 會(huì)話。這么一來(lái), 重建連接就只需一次 TLS 握手。
Nginx 自身支持 Session ID,但有個(gè)問(wèn)題,它的會(huì)話最多只能存儲(chǔ)在共享內(nèi)存里面。服務(wù)器和客戶端上次握手建立的會(huì)話,只有某個(gè)服務(wù)器自己 認(rèn)得,換個(gè)服務(wù)器就忘光光了。當(dāng)然你也可以要求負(fù)載均衡的時(shí)候只用 IP hash,盡管在實(shí)際情況中這么做不太現(xiàn)實(shí)。
OpenResty 提供了 ssl_session_fetch_by_lua*
和 ssl_session_store_by_lua*
這兩個(gè)支持協(xié)程的階段,
以及跟 Session id 相關(guān)的 ngx.ssl.session
模塊,
把存儲(chǔ)的決定權(quán)交給開發(fā)者手中。
你可以把 session 放到獨(dú)立的 Redis 或 Memcached 服務(wù)器上。
不過(guò)你可能已經(jīng)不需要額外折騰 ssl_session_*
的代碼。因?yàn)?Session ID 已經(jīng)過(guò)時(shí)了。
TLSv1.2 提供了名為 Session Tickets 的拓展,用來(lái)代替之前的 Session ID 方案。
Session ID 方案要求服務(wù)端記住會(huì)話狀態(tài),有違于 HTTP 服務(wù)無(wú)狀態(tài)的特點(diǎn)。Session Tickets 方案旨在解決這個(gè)問(wèn)題。
Session Tickets 跟 Session ID 差不多,只是有點(diǎn)關(guān)鍵上的不同:現(xiàn)在輪到由客戶端記住會(huì)話狀態(tài)。 服務(wù)端僅需記住當(dāng)初用于加密返回給客戶端的 Ticket 的密鑰,以。 這么一來(lái),只要在不同的服務(wù)器間共享同一個(gè)密鑰,就能避免會(huì)話丟失的問(wèn)題,不再需要獨(dú)立的 Redis 或 Memcached 服務(wù)器。
對(duì)于 Nginx,你需要關(guān)注兩個(gè)指令:ssl_session_tickets
和 ssl_session_ticket_file
。
在高興之余看下兩個(gè)壞消息:
既然通過(guò) Session ID/Tickets,我們已經(jīng)把 RTT 減到了 1,能不能更進(jìn)一步,減到 0? 初看像是天方夜譚,但最新的 TLSv1.3 確實(shí)允許做到這一點(diǎn)。
在繼續(xù)之前先看下 TLSv1.3 的支持情況:Nginx 需要 1.13+ 的版本,外加 OpenSSL 1.1.1??蛻舳朔矫?,截止到寫作本文的時(shí)間,F(xiàn)irefox 和 Chrome 的 nightly build 版本均支持。
0 RTT 是 TLSv1.3 的可選功能??蛻舳撕头?wù)器第一次建立會(huì)話時(shí),會(huì)生成一個(gè) PSK(pre-shared key)。服務(wù)器會(huì)用 ticket key 去加密 PSK,作為 Session Ticket 返回。 客戶端再次和服務(wù)器建立會(huì)話時(shí),會(huì)先用 PSK 去加密 HTTP 請(qǐng)求,然后把加密后的內(nèi)容發(fā)給服務(wù)器。服務(wù)器解密 PSK,然后再用 PSK 去解密 HTTP 請(qǐng)求,并加密 HTTP 響應(yīng)。
這就完事了。
由于 HTTPS 握手已經(jīng)跟 HTTP 請(qǐng)求合并到一起,確實(shí)是當(dāng)之無(wú)愧的 0 RTT 呢。
在高興之余看下兩個(gè)壞消息: