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

01背景

為什么要在移動端花費這么多精力？移動端因為設備性質以及網絡環境因素等，導致新鏈接、以及鏈接復用問題放大。

HTTPS 請求花費的時間？一個全新的 HTTPS 鏈接，從發起請求到數據返回經過幾個 RTT？假設沒有任何緩存，一個 HTTPS 請求得經過 10 個 RTT 才能返回內容。

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

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

現實情況會有各種緩存，減少不必要的消耗，所以很少發生上面這種極端的 10 個 RTT 情況。

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

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

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

02  HTTPS流程分析和優化的策略

使用 WireShark 抓包， 根據 TCP 包，我們畫了下面流程圖，一步步分析流程，并確定中間可優化的點。（TLS1.2 協議 ECDHE 算法）

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

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

TLS Hello階段的分析與應用先看看 Clienthello 的幾個主要的參數?

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

上面的抓包 Version 是 TLS1.2，擴展中帶有 TLS1.3。如果服務端支持 1.3 ，將改為 1.3 協議。

服務端先要進行對應的支持配置，如下。

ssl_protocols  TLSv1.2 TLSv1.3

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

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

Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA256

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

這個階段優化的幾個思路：

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

優化 ECDHE 算法實現，優先選擇效率最高的橢圓曲線實現 x25519。在 Nginx 后臺使用 ssl_ecdh_curve 配置橢圓曲線優先級。

ssl_ecdh_curve X25519:secp384r1;

同時 ECDHE 支持 False Start。

啟用了 False Start，在 Client 發送完 ChangeCipher Spec 就可以發送加密的應用數據，減少1個 RTT 等待時間。

服務端配置 Cipher Suites 的優先級。把性能最高的算法放在前面。?

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

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

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

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

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

證書驗證客戶端在驗證證書時，會走證書鏈逐級驗證，而且為了知道證書是否被 CA 吊銷，客戶端會訪問 CA 下載 OCSP 數據，確認證書是否有效。

OCSP 需要向 CA 查詢，因此也是要發生網絡請求，如果CA服務器的延遲過大，會導致客戶端在校驗證書這一環節的延時變大。

OCSP Stapling為了解決證書有效性驗證的問題，出現了 OCSP Stapling。

服務器向 CA 周期性地查詢證書狀態，獲得一個帶有時間戳和簽名的響應并緩存，當客戶端來請求證書，在 TLS 握手階段，服務器將該結果給客戶端。

因為結果帶有 CA 私鑰的簽名，所有結果可信，客戶端在本地就可以判斷證書的有效性。

在Nginx中開啟OCSP Stapling?

ssl_stapling  on;
ssl_stapling_verify  on;
ssl_trusted_certificate    xx.pem

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

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

密鑰交換和驗證的階段

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

?加解密雙方驗證Change Cipher Spec/Encrypted Handshake Message

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

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

以上兩個階段是否可以優化？是的，我們可以采用鏈接復用的方式跳過該階段。

鏈接復用優化復用有兩個方式：SessionID 和 SessionTicket，實現不同但目標一致。（一個服務端實現，一個客戶端實現）

SessionID

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

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

SessionTicket

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

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

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

在服務端開啟 Session ticket

ssl_session_tickets on;ssl_session_ticket_key xx.key;

用了鏈接重用技術，當再次重連 HTTPS 時，只需要 1 RTT 就可以恢復會話。對于 TLS1.3 使用 Pre-shared Key 重用技術，可以實現 0RTT 恢復鏈接。

采用鏈接重用，當然不可避免的產生重放攻擊風險。

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

03總結

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