鍍金池/ 教程/ Java/ TLS session resumption
定時(shí)任務(wù)
函數(shù)的參數(shù)
超時(shí)
一個(gè) openresty 內(nèi)存“泄漏”問(wèn)題
獲取 uri 參數(shù)
局部變量
sleep
灰度發(fā)布
TIME_WAIT
代碼覆蓋率
連接池
CentOS 平臺(tái)安裝
稀疏數(shù)組
如何只啟動(dòng)一個(gè) timer 工作?
變量的共享范圍
break,return 關(guān)鍵字
Nginx
SQL 注入
如何引用第三方 resty 庫(kù)
不同階段共享變量
獲取請(qǐng)求 body
動(dòng)態(tài)生成的 lua-resty-redis 模塊方法
動(dòng)態(tài)加載證書和 OCSP stapling
repeat 控制結(jié)構(gòu)
編碼為 array 還是 object
Nginx 靜態(tài)文件服務(wù)
執(zhí)行階段概念
Lua 函數(shù)
日期時(shí)間函數(shù)
健康監(jiān)測(cè)
與其他 location 配合
for 控制結(jié)構(gòu)
函數(shù)定義
HTTPS 時(shí)代
點(diǎn)號(hào)與冒號(hào)操作符的區(qū)別
String 庫(kù)
文件操作
OpenResty 最佳實(shí)踐
<code>ngx.shared.DICT</code> 非隊(duì)列性質(zhì)
使用動(dòng)態(tài) DNS 來(lái)完成 HTTP 請(qǐng)求
代碼規(guī)范
什么是 JIT?
Windows 平臺(tái)安裝
正確的記錄日志
LuaNginxModule
不用標(biāo)準(zhǔn)庫(kù)
C10K 編程
控制結(jié)構(gòu)
請(qǐng)求中斷后的處理
Lua 環(huán)境搭建
Test::Nginx 能指定現(xiàn)成的 nginx.conf,而不是自動(dòng)生成一個(gè)嗎
Lua 基礎(chǔ)數(shù)據(jù)類型
動(dòng)態(tài)限速
PostgresNginxModule
簡(jiǎn)單API Server框架
API 測(cè)試
location 匹配規(guī)則
虛變量
單元測(cè)試
防止 SQL 注入
select + set_keepalive 組合操作引起的數(shù)據(jù)讀寫錯(cuò)誤
阻塞操作
全動(dòng)態(tài)函數(shù)調(diào)用
Web 服務(wù)
典型應(yīng)用場(chǎng)景
Nginx 新手起步
TLS session resumption
輸出響應(yīng)體
調(diào)用代碼前先定義函數(shù)
module 是邪惡的
怎樣理解 cosocket
模塊
Socket 編程發(fā)展
如何對(duì) Nginx Lua module 添加新 api
如何在后臺(tái)開啟輕量級(jí)線程完成定時(shí)任務(wù)?
如何定位問(wèn)題
table 庫(kù)
json 解析的異常捕獲
如何安裝火焰圖生成工具
lua 中如何 continue
if 是邪惡的
為什么我們的域名不能被解析
抵制使用 module() 定義模塊
測(cè)試
body 在 location 中的傳遞
Lua 入門
子查詢
pipeline 壓縮請(qǐng)求數(shù)量
如何發(fā)起新 HTTP 請(qǐng)求
Lua 簡(jiǎn)介
緩存失效風(fēng)暴
Ubuntu 平臺(tái)安裝
日志輸出
緩存
Lua 面向?qū)ο缶幊?/span>
Nginx 陷阱和常見錯(cuò)誤
Redis 接口的二次封裝(發(fā)布訂閱)
日志
訪問(wèn)有授權(quán)驗(yàn)證的 Redis
正則表達(dá)式
lock
熱裝載代碼
調(diào)用 FFI 出現(xiàn) &quot;table overflow&quot;
數(shù)據(jù)合法性檢測(cè)
禁止某些終端訪問(wèn)
控制結(jié)構(gòu) if-else
調(diào)試
與 Docker 使用的網(wǎng)絡(luò)瓶頸
PostgresNginxModule 模塊的調(diào)用方式
用 do-end 整理你的代碼
FFI
什么時(shí)候使用
簡(jiǎn)介
環(huán)境搭建
Mac OS X 平臺(tái)安裝
火焰圖
負(fù)載均衡
while 型控制結(jié)構(gòu)
如何定位 openresty 崩潰 bug
使用 Nginx 內(nèi)置綁定變量
判斷數(shù)組大小
請(qǐng)求返回后繼續(xù)執(zhí)行
Redis 接口的二次封裝
KeepAlive
反向代理
協(xié)議無(wú)痛升級(jí)
數(shù)學(xué)庫(kù)
元表
Vanilla 介紹
HelloWorld
LuaCjsonLibrary
持續(xù)集成
代碼靜態(tài)分析
網(wǎng)上有大量對(duì) Lua 調(diào)優(yōu)的推薦,我們應(yīng)該如何看待?
script 壓縮復(fù)雜請(qǐng)求
非空判斷
性能測(cè)試
函數(shù)返回值
API 的設(shè)計(jì)
kong 介紹
表達(dá)式
不支持事務(wù)
LuaRestyDNSLibrary 簡(jiǎn)介

TLS session resumption

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

一個(gè)完整的 TLS 握手需要兩次:

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

這一過(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

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

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

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ù)器上。

Session Tickets

不過(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ù)器。

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

對(duì)于 Nginx,你需要關(guān)注兩個(gè)指令:ssl_session_ticketsssl_session_ticket_file。

在高興之余看下兩個(gè)壞消息:

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

0 RTT!?

既然通過(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)。

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

這就完事了。

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

在高興之余看下兩個(gè)壞消息:

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