?視頻內(nèi)容類的業(yè)務(wù)對延遲比較敏感，而在海外運(yùn)營場景下，這種延遲敏感更為突出，愛奇藝海外版項(xiàng)目在初期技術(shù)要求就是秒開，除了 CDN、邊緣節(jié)點(diǎn)的部署外，海外后端團(tuán)更是對 HTTPS 的請求做過一系列的優(yōu)化，現(xiàn)總結(jié)之前工作中的一些技術(shù)性探索和優(yōu)化，分享給大家。

01背景

為什么要在移動端花費(fèi)這么多精力？移動端因?yàn)樵O(shè)備性質(zhì)以及網(wǎng)絡(luò)環(huán)境因素等，導(dǎo)致新鏈接、以及鏈接復(fù)用問題放大。

HTTPS 請求花費(fèi)的時間？一個全新的 HTTPS 鏈接，從發(fā)起請求到數(shù)據(jù)返回經(jīng)過幾個 RTT？假設(shè)沒有任何緩存，一個 HTTPS 請求得經(jīng)過 10 個 RTT 才能返回內(nèi)容。

一個 RTT 如果是 50ms，這個全新的請求至少花費(fèi) 50*10=500ms。這還沒有算后端業(yè)務(wù)處理的時間。HTTPS 請求延遲確實(shí)比較高。

通常情況下業(yè)務(wù) HTTP 的延遲容忍度較差，Server To Client 的模式，效率總歸是越高越好。

現(xiàn)實(shí)情況會有各種緩存，減少不必要的消耗，所以很少發(fā)生上面這種極端的 10 個 RTT 情況。

• DNS 有本地緩存或者用了 HTTPDNS 預(yù)解析，第1步可以省掉。
• 如果瀏覽器聲明了 HSTS ，可以省略 302 轉(zhuǎn)向，第3步可以省掉。
• 如果本地已經(jīng)有主流的 CA DNS 緩存  第6步可以省掉
• 如果 CA 本地有驗(yàn)證緩存或者啟用 OCSP Stapling 的本地驗(yàn)證 7、8步可以省掉

在有各類緩存情況下，一個常規(guī)的 HTTPS 請求會保留下面 4 個 RTT 流程。

除了 HTTPS 內(nèi)容請求外，握手的階段或者 TLS 層是否還可以再繼續(xù)優(yōu)化一下，讓我們的 APP 或者視頻播放再快那么一點(diǎn)？答案：肯定是的！對于 HTTP 這種協(xié)議，我們可以從這幾方面入手：提升加解密效率、減少內(nèi)容傳輸量、鏈接復(fù)用...

02  HTTPS流程分析和優(yōu)化的策略

使用 WireShark 抓包， 根據(jù) TCP 包，我們畫了下面流程圖，一步步分析流程，并確定中間可優(yōu)化的點(diǎn)。（TLS1.2 協(xié)議 ECDHE 算法）

整個流程有以下幾個階段：

• TLS Hello 確定協(xié)議版本、密碼套件、對稱密鑰隨機(jī)數(shù)
• Server Certificate  服務(wù)器發(fā)送證書鏈
• Client/Server Key Exchange (DH 算法，協(xié)商交換加密算法)
• ChangeCipher Spec 對稱加密雙向校驗(yàn)

TLS Hello階段的分析與應(yīng)用先看看 Clienthello 的幾個主要的參數(shù)?

struct
hello {
Version // TLS版本號
Random // 客戶端隨機(jī)數(shù)
Session id
Cipher Suites // 客戶端支持的加密套件
Extension: support version; // 擴(kuò)展TLS版本支持
}

上面的抓包 Version 是 TLS1.2，擴(kuò)展中帶有 TLS1.3。如果服務(wù)端支持 1.3 ，將改為 1.3 協(xié)議。

服務(wù)端先要進(jìn)行對應(yīng)的支持配置，如下。

ssl_protocols  TLSv1.2 TLSv1.3

Cipher Suites 是個數(shù)組，會包含新舊一堆加密算法支持，優(yōu)先級從上到下。

服務(wù)端 Server Hello 返回 Cipher Suite，根據(jù) Client 的請求匹配一個合適的加密套件。如下服務(wù)器返回支持的套件。

Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA256

上面什么意思？握手時對稱加密參數(shù)交換使用 RSA。通信加密使用 256 位長度對稱 AES 算法，GCM 和 SHA256 是 AES 的分組模式和摘要算法。

這個階段優(yōu)化的幾個思路：

密鑰交換算法改進(jìn)：RSA 可以改為 DH 類算法(Diffie-Hellman)，如 ECDHE。在同等復(fù)雜度下，計算效率更高，證書體積也更小。

優(yōu)化 ECDHE 算法實(shí)現(xiàn)，優(yōu)先選擇效率最高的橢圓曲線實(shí)現(xiàn) x25519。在 Nginx 后臺使用 ssl_ecdh_curve 配置橢圓曲線優(yōu)先級。

ssl_ecdh_curve X25519:secp384r1;

同時 ECDHE 支持 False Start。

啟用了 False Start，在 Client 發(fā)送完 ChangeCipher Spec 就可以發(fā)送加密的應(yīng)用數(shù)據(jù)，減少1個 RTT 等待時間。

服務(wù)端配置 Cipher Suites 的優(yōu)先級。把性能最高的算法放在前面。?

ssl_prefer_server_ciphers on; 
ssl_ciphers EECDH+ECDSA+AES128+SHA:RSA+AES128+SHA...

盡管 AES 的效率很高，但在一些安全性沒那么高的業(yè)務(wù)下，AES 密鑰的長度可以小一些，256位改為128位。Server Certificate階段Certificate 階段會將自身公鑰和證書CA中間公鑰發(fā)給客戶端。本地驗(yàn)證證書合法后繼續(xù) Client Key Exchange 流程。在這個階段，有兩個方向可以優(yōu)化：證書傳輸+證書驗(yàn)證。

證書傳輸?證書的大小當(dāng)然越小越好，在生成證書階段選擇 ECDSA，而不是 RSA 證書，安全不變的條件下，密鑰長度更小，運(yùn)算量也更小。

比如用類似下面生成 ECDSA 證書

openssl ecparam -genkey -name prime256v1 -out key.pem

證書驗(yàn)證客戶端在驗(yàn)證證書時，會走證書鏈逐級驗(yàn)證，而且為了知道證書是否被 CA 吊銷，客戶端會訪問 CA 下載 OCSP 數(shù)據(jù)，確認(rèn)證書是否有效。

OCSP 需要向 CA 查詢，因此也是要發(fā)生網(wǎng)絡(luò)請求，如果CA服務(wù)器的延遲過大，會導(dǎo)致客戶端在校驗(yàn)證書這一環(huán)節(jié)的延時變大。

OCSP Stapling為了解決證書有效性驗(yàn)證的問題，出現(xiàn)了 OCSP Stapling。

服務(wù)器向 CA 周期性地查詢證書狀態(tài)，獲得一個帶有時間戳和簽名的響應(yīng)并緩存，當(dāng)客戶端來請求證書，在 TLS 握手階段，服務(wù)器將該結(jié)果給客戶端。

因?yàn)榻Y(jié)果帶有 CA 私鑰的簽名，所有結(jié)果可信，客戶端在本地就可以判斷證書的有效性。

在Nginx中開啟OCSP Stapling?

ssl_stapling  on;
ssl_stapling_verify  on;
ssl_trusted_certificate    xx.pem

使用以下命令測試服務(wù)器是否開啟 ocspstaping?

openssl s_client -connect ip:443 -status
OCSP response: no response sent //出現(xiàn)以下 則沒配置

密鑰交換和驗(yàn)證的階段

Client/ServerKey Exchange 階段在這一階段主要是交換 DH 加密公鑰，如選定橢圓曲線，生成橢圓曲線公鑰，公鑰簽名，與客戶端的 ClientKey Exchange 呼應(yīng)，最終獲取對方的公鑰，用來加密 AES 的密鑰。

?加解密雙方驗(yàn)證Change Cipher Spec/Encrypted Handshake Message

在 Key Change 階段，加密的參數(shù)均已生成，雙方有了交換密鑰的公鑰，也有對稱密鑰的參數(shù)。可以進(jìn)行數(shù)據(jù)傳輸了

如果雙方都驗(yàn)證加密和解密沒問題，那么握手正式完成。于是，就可以正常收發(fā)加密的 HTTP 請求和響應(yīng)了。

以上兩個階段是否可以優(yōu)化？是的，我們可以采用鏈接復(fù)用的方式跳過該階段。

鏈接復(fù)用優(yōu)化復(fù)用有兩個方式：SessionID 和 SessionTicket，實(shí)現(xiàn)不同但目標(biāo)一致。（一個服務(wù)端實(shí)現(xiàn)，一個客戶端實(shí)現(xiàn)）

SessionID

客戶端和服務(wù)器首次 TLS 握手連接后，雙方會在內(nèi)存緩存會話密鑰，并用唯一的 Session ID 來標(biāo)識。在下一次鏈接時，服務(wù)端可以知道一個進(jìn)來的連接是否在之前已經(jīng)建立過連接，如果在服務(wù)器中也存在這個 session 的 key，那么它就能重用。??在服務(wù)端開啟 SessionID?

ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;

SessionTicket

為了解決 Session ID 的問題，就出現(xiàn)了 Session Ticket，服務(wù)器不再緩存每個客戶端的會話密鑰，而是把緩存的工作交給了客戶端，類似于 HTTP 的 Cookie。

客戶端與服務(wù)器首次建立連接時，服務(wù)器會加密「會話密鑰」作為 Ticket 發(fā)給客戶端，交給客戶端緩存該 Ticket。

客戶端再次連接服務(wù)器時，客戶端會發(fā)送 Ticket，服務(wù)器解密后就可以獲取上一次的會話密鑰，然后驗(yàn)證有效期，如果沒問題，就可以恢復(fù)會話了。

在服務(wù)端開啟 Session ticket

ssl_session_tickets on;ssl_session_ticket_key xx.key;

用了鏈接重用技術(shù)，當(dāng)再次重連 HTTPS 時，只需要 1 RTT 就可以恢復(fù)會話。對于 TLS1.3 使用 Pre-shared Key 重用技術(shù)，可以實(shí)現(xiàn) 0RTT 恢復(fù)鏈接。

采用鏈接重用，當(dāng)然不可避免的產(chǎn)生重放攻擊風(fēng)險。

對于安全性要求非常高的業(yè)務(wù)要慎重的使用鏈接重用， 當(dāng)然如果衡量好重用過期時間，同時業(yè)務(wù)端做好安全防范，獲得的收益也不會小。

03總結(jié)

從 HTTP/1.0 到 HTTP/2，HTTP 協(xié)議基礎(chǔ)一直是可靠連接 TCP。TCP 的對頭阻塞、握手流程等機(jī)制問題，導(dǎo)致無論如何優(yōu)化，HTTP 延遲始終過高。另外 TCP 協(xié)議作為互聯(lián)網(wǎng)最為廣泛應(yīng)用的協(xié)議之一，涉及無數(shù)的中間設(shè)備、操作系統(tǒng)，協(xié)議僵化問題導(dǎo)致 IETF 標(biāo)準(zhǔn)化制定的許多 TCP 新特性難以執(zhí)行。所以下一階段的 HTTP/3 完全放棄了 TCP，經(jīng)歷七年之久。從 QUIC 被提交給 IETF 進(jìn)行標(biāo)準(zhǔn)化，QUIC 協(xié)議的 HTTP/3 在今年終于正式發(fā)布。基于 QUIC 更能簡單的實(shí)現(xiàn) 0-RTT,1-RTT 的連接建立，愛奇藝海外也早早開始嘗試使用 QUIC 改善用戶服務(wù)，后續(xù)技術(shù)團(tuán)隊(duì)也將基于數(shù)據(jù)分享我們使用 QUIC 的實(shí)踐。最后，不論阻礙如何，HTTP/3 的時代已經(jīng)到來，讓我們拭目以待。?