京東金融私有雲HTTPS性能優化實踐">京東金融私有雲HTTPS性能優化實踐

HTTPS 協議因其具有安全屬性，完全有將 HTTP 取而代之的趨勢。然而這個進程並沒有很順利，因為 HTTPS 實施起來有幾個難點，其中有一個是它的性能問題。本文分享了京東金融私有雲在 HTTPS 性能優化上的實踐，希望對有意切換 HTTP 到 HTTPS 的你有所幫助。

隨著智能手機普及、WIFI 接入常態化，互聯網占我們日常生活的比重日漸變大。我們在網上搜索、社交和購物，看似方便快捷，但是有可能你的數據正在被竊聽篡改，被黑客組織利用。

造成這種問題的原因是我們平常最為廣泛使用的超文本傳輸協議（HTTP，HyperText Transfer Protolcol）在設計之初並沒有考慮安全性問題，導致如今大量數據在網絡上明文傳輸。

HTTPS 是什麽

HTTPS（HTTP over TLS）是超文本傳輸安全協議（HyperText Transfer Protocol Secure），是一種通過計算機網絡進行安全通信的傳輸協議，最初由網景公司（Netscape）於 1994 年提出。

HTTPS 在不安全的網絡上創建一條安全信道，通過數據加密、數據完整性校驗、身份認證等手段，對竊聽和中間人攻擊進行合理的防護。

• 數據加密，就像我們郵寄包裹，任何的中間人都無法知道裏面裝了什麽

• 身份認證，確保包裹一定是包裹單上的收件人簽收的。

HTTPS 是大勢所趨

如今，全世界都對 HTTPS 拋出了橄欖枝：

• 微信小程序要求所有的請求必須是 HTTPS 請求

• 蘋果要求所有 IOS App 2016 年底強制使用 HTTPS 加密，雖然該計劃暫時被延期

• 百度、谷歌優先收錄 HTTPS 站點，相同權值的站點 HTTPS 排名靠前

• chrome 瀏覽器對 HTTP 頁面提出警告，如下圖，當前為中性警告，即默認情況下只有當 HTTP 頁面檢測到密碼或信用卡字段時才會提示不安全，但同時 Chrome 也明確表示，該計劃將會越來越嚴格，最終會對所有 HTTP 頁面提示不安全。

(點擊放大圖像)

HTTPS 存在的問題

HTTPS 是大勢所趨，但是 HTTPS 的覆蓋率並不廣，只有像 BATJ 等大型互聯網企業才在最近幾年完成了全站 HTTPS 的遷移，究其原因主要是 HTTPS 的實施成本過高：

• 延時增加，普遍增加二到四個 RTT，最嚴重情況下可能會增加七個 RTT

• 吞吐率下降，服務端消耗 CPU 嚴重，完全握手下，整體性能會下降到 HTTP 的 10% 甚至更低

用戶訪問延時的增加，給公司產品、服務質量造成不利的影響。從另外一個層面來講，由於服務端性能驟降，可能需要原本接入集群基礎上數倍的機器數量才能支撐當前用戶訪問。

而且證書的選擇、後期運維如私鑰存儲都具有一定的技術門檻，比如如何在安全性和兼容性層面達到相對平衡，這使得許多公司望而生畏。

本文不涉及 HTTPS 的實現原理以及最佳運維實踐，主要談談京東金融私有雲在 HTTPS 性能提升上的一些經驗。

優化經驗

京東金融私有雲 HTTPS 卸載服務基於 Nginx 和 Openssl 深度定制，性能優化主要從 延時 和 吞吐率 兩個維度考慮。

TLS Record Size 動態調整

TLS Record 協議工作在表示層，在傳輸層和應用層之間提供諸如數據封包，加解密，HMAC 校驗等功能，如下圖：

(點擊放大圖像)

Nginx 在建立 TLS 連接時會為每個連接分配 Buffer 用於發送原數據（TLS Record Size，默認 16KB），當服務端發送數據時，數據會被切分成 16KB 的多個塊，每個塊用 MAC 簽名，加上協議的元數據以及被加密後的原數據形成一個 TLS Record 結構發送到客戶端，在客戶端只有當協議棧接收到完整的 TLS Record 時才能夠解密驗證，才會向應用層提交。

由於 16KB 的包大小以及丟包等因素的影響，相對於 TCP，HTTPS 的 TTFB( Time To First Byte ) 延時較大。

TTFB 是判斷網站性能的重要指標，主流瀏覽器都是邊下載邊解析渲染的，延時較大最直觀的影響就是最終用戶在瀏覽器端看到內容的速度較慢。

當然 TLS Record Size 也不能一味地變小，比如當它等於 MSS 時，變小就會有較大的頭部負擔，導致整體吞吐量下降。

我們當前使用的是 TLS Record Size 動態調整 算法，隨著 CWND 從 Initcwnd 增長到 16K，在延時和吞吐量之間達到相對平衡。

False Start

通過啟用 False Start，客戶端可以在 Change Cipher Spec 和 Finished 報文後立即發送應用數據，使得原本需要兩次 RTT 的完全握手變更為一次 RTT。

國內南北網絡的平均延時是 50ms，這也就意味著每一個地處南方的用戶訪問地處北方的站點，人均可節省 50ms，效果顯著。

根據 RFC7918 文檔，只有使用具有前向安全的秘鑰交換算法以及足夠強度的對稱加解密算法時 False Start 才會啟動。

需要註意的是，Chrome 瀏覽器為了解決一些特殊 SSL 服務如 SSL Terminator 硬件設備的不兼容性，要求只有和支持 NPN/ALPN 的服務端通信才會開啟 False Start。

NPN 隨著 SPDY 被 HTTP/2 代替已被 Chrome 移除，而 ALPN 只在 Openssl-1.0.2 後才開始支持，加之 Openssl 新版本的 Bug 修復以及性能優化，所以如果有條件建議在服務端部署較新版本的 Openssl。

OCSP Stapling

OCSP 設計之初是 CRL(Certificate Revocation List) 的替代品，希望通過在線實時的網絡交互檢查證書吊銷狀態，但是這個功能有點雞肋：

• 暴露用戶隱私，Https 旨在提高安全性和保護隱私，OCSP 顯得有點背道而馳

• OCSP Responder 基本在國外，而且服務能力未知，假設訪問 OCSP Responder 的延時很大，或者是客戶端和 OCSP Responder 的鏈路主動或被動地斷開，客戶端無法很好地確定是否應該接受證書。

OCSP Stapling 通過服務端對 OCSP 結果的預取並把結果隨著證書一起發給客戶端，從而繞過客戶端的在線驗證過程，可以很好地解決上邊兩個問題。

我們在自己的網站中都應該配置使用 OCSP Stapling，但是需要註意的是 OCSP Stapling 也並非完全能起到檢查證書吊銷的作用，以至於像 Chrome 瀏覽器就已經完全不做證書吊銷檢查了。

HSTS

HSTS（HTTP Strict Transport Security）通過在 HTTPS Response Header 中攜帶 Strict-Transport-Security 來告知瀏覽器：以後請直接通過 HTTPS 訪問我，當第二次用戶在瀏覽器端訪問 HTTP 站點，瀏覽器會在內部做 307 重定向，直接通過 HTTPS 訪問。如下圖：

(點擊放大圖像)

通過 HSTS 能有效地避免 SSL 剝離攻擊，並能減少 2 個 RTT，強烈建議配置使用。但同時也需關註首次訪問的中間人攻擊，以及準備回滾措施以防 HTTPS 回滾。

會話復用

常見的會話復用有 Session ID 和 Session Ticket 兩種形式，其中 Session ID 是 TLS 協議的標準字段，而 Ticket 是擴展字段，根據相關統計，Ticket 的客戶端支持率只有 40% 左右。

通過會話復用，把完全握手變更為簡單握手，避免最耗時的秘鑰協商階段，能顯著提升性能，如下圖，客戶端在發起連接時攜帶上一次完全握手時服務端返回的 SessionID，服務端收到後在內存中查找緩存的會話信息並恢復加密通信。

(點擊放大圖像)

但是原生 Nginx 只實現了單機版本的會話復用（SSL_SESSION_CACHE 關鍵字），而當前我們都習慣以集群方式部署 Nginx 來達到高可用，所以我們通過新增 Nginx 模塊以及對 Nginx 源碼的少量改造，支持分布式會話復用，如下圖，無論請求落到哪一臺 Nginx 機器，都可以復用已緩存的會話信息。

(點擊放大圖像)

該 Nginx 模塊

（ngx_ssl_session_cache_module）

已經開源，支持 Redis 和 Memcached 兩種分布式緩存系統，且對 Openssl 沒有任何代碼依賴，歡迎使用， 詳見 .

雙證書

256 位 ECC 秘鑰加密強度等同於 3072 位 RSA 秘鑰水平且性能更高，而且秘鑰更短意味著更少的存儲空間，更低的帶寬占用，所以對於有條件的企業建議開啟 ECC & RSA 雙證書支持。

對比 ECDHE_RSA、ECDHE_ECDSA 秘鑰交換認證算法所需的 RSA_SIGN、ECDSA_SIGN 算法，以下是我們在普通工作站上通過 OPENSSL SPEED 測試的性能數據，可以明顯看到 ECDSA_SIGN 性能提升。

(點擊放大圖像)

對稱加密優化

AES-GCM 是目前常用的分組加密算法，缺點是性能低以及移動端耗電量大，所以谷歌在 2014 年推出了一種新的流式加密算法 CHACHA20-POLY1350，在 ARM 平臺上性能是 AES-GCM 的 3-4 倍。

Intel 從 Westmere 處理器開始支持一種新的 x86 指令擴展集 AES-NI，AES-NI 能從硬件上加速 AES 的性能，在支持 AES-NI 指令集的主機上實測 AES-GCM 性能是 CHACHA20 的 5 倍左右。

原先我們為權衡兼容性和安全性，所以參考 Mozilla 的推薦 .

默認采用中檔配置，該配置假設客戶端不支持 AES-NI，所以 CHACHA20 優先於 AES-GCM，然而隨著底層技術的發展，移動端從 ARMV8-A 架構開始逐漸支持 AES 指令集。

像常用的 iPhone 5S，Galaxy Note 4(Exynos)，紅米 2，錘子 T2，榮耀 5X 等都是基於的 ARMV8 架構，考慮到當前互聯網企業的用戶都以年輕群體為主，所以我們改變策略優先使用 AES-GCM。

HTTP/2

HTTP/2 是 HTTP/1.1 在 1999 年發布後的首次更新，HTTP/2 帶來了諸如多路復用、頭部壓縮、二進制分幀等特性，能大幅提升 Web 性能。

使用時可以讓客戶端選擇或通過 NPN/ALPN 動態協商是采用 HTTP/1.X over TLS 還是 HTTP/2 over TLS，而且後端服務無需修改代碼進行適配，具有比較大的靈活性。

但是也需要註意 HTTP/2 並不是萬能的解藥，使用時需對網站本身的情況做充分評估，需規避諸如為 HTTP/1.X 調優而提出的域名散列等問題。

加速卡

以上所有的優化都是 軟加速 範疇，主要目的是減少 RTT，但是對於無法避免的完全握手，服務端還是會進行大量的加解密運算，以 ECDHE_RSA 為例，像 RSA_Sign 函數在 Intel E5-2650 V2 主機上每秒只能執行 1.2W 次左右，而此時 24 個核已全是滿載狀態。

CPU 向來都不適合處理大規模的浮點運算，解決這類問題性價比最高的方式無疑是采用硬件加速卡（GPU 就是其中一種），通過把加解密運算轉移到加速卡來替換 Openssl 的加解密處理。

加速卡安裝在主機的 PCIE 插槽內，受限於主機 PCIE 插槽數量，支持線性擴容，根據加速卡類型不同，像 RSA_Sign 計算性能在單卡狀態下都能提升 3-6 倍左右。

算法分離

利用軟優化以及硬件加速卡，基本能滿足大部分的業務場景，但這卻不是最優解，我們發現：

• 不同廠家不同型號的加速卡存在性能差異，同型號的加速卡不同算法也存在性能差異，像我們測試的一款 Cavium 卡，ECDHP256 和 RSA2048_Sign 存在 20% 的性能差距

• Openssl-1.0.2 版本實現了更快速以及更安全的 EC_GFp_nistz256_method 方法用於 P256 曲線操作，該方法利用了 Intel AVX 擴展，性能提升顯著。

在老舊的 Intel E5-2620 主機測試 Openssl-1.0.2 單核 ECDH 性能達到 8040，4 倍於 Openssl-1.0.1u，24 核全開時性能達到 9.7W，在 E5-2650 V2 上，極限性能更是達到 17.5W，遠高於加速卡單卡的 5-8W。

正是由於這種差異性，我們提出算法分離的架構，希望充分利用硬件性能。

(點擊放大圖像)

如上圖，通過這種架構我們把接入集群從 CPU 密集型 轉換成 IO 密集型 ，具體的算法運算，私鑰存儲等都在專有集群完成，極大地增強了接入集群的可擴展性。

另外通過這種架構我們不僅可以充分利用閑置的計算資源，也可以最優化 HTTPS 卸載服務的吞吐率，而且對於計算集群的增刪改，我們支持在 Web 管控端上批量修改，卸載服務會實時拉取並應用修改，此外再輔以計算集群的整體監控，極大地簡化了運維復雜度。

性能指標

以上優化總結起來就是面向延時和吞吐率的優化，以下是我們在測試環境測試的一組單機性能數據（Intel E5-2650 V2），僅供參考。

(點擊放大圖像)

由於無法優化瀏覽器端代碼，當前延時只能優化到一個 RTT，若客戶端私有，可參考 TLS V1.3 開發 0-RTT 協議。

總結

HTTPS 是個系統性工程，而性能優化只是其中一塊，還需要解決諸如證書、運維、網絡等問題，但是好消息是，隨著國內一些大企業實施 HTTPS 已經有一些最佳實踐被探索，以及諸如 Let's Encrypt 等免費 DV 證書推出，HTTPS 的成本正在逐漸降低，所以在此呼籲各企業盡快上線 HTTPS，保障網站的信息數據安全。

作者介紹

吳建苗，京東金融研發工程師，關註負載均衡，消息隊列，網絡等方向。

感謝雨多田光對本文的審校。

給InfoQ中文站投稿或者參與內容翻譯工作，請郵件至[email protected]。也歡迎大家通過新浪微博（@InfoQ，@丁曉昀），微信（微信號： InfoQChina ）關註我們。

文章來源：