引言

百度于2015年完成全站HTTPS改造，標志著大型網站對安全與性能協同優化的高度重視。作為HTTPS實踐系列的核心篇章，本文聚焦于協議層深度優化與配置策略精細調整，系統剖析訪問速度提升、計算性能優化及安全加固的關鍵實踐。基于百度運維團隊的實戰經驗，本文從技術原理、工程實現及效果驗證三個維度，為大型網站的HTTPS部署提供可落地的優化路徑。

一、HTTPS訪問速度優化：協議層創新與機制重構

HTTPS的性能瓶頸常源于TCP握手、TLS握手及證書校驗的時延疊加。為突破這一限制，需從協議機制與配置層面進行系統性優化。

1.1 TCP Fast Open（TFO）：減少握手時延

HTTPS與HTTP均依賴TCP協議進行數據傳輸，傳統三次握手需1個RTT（Round-Trip Time）僅完成SYN包交互，造成資源浪費。TFO技術通過在SYN包中攜帶應用層數據，實現“握手-數據傳輸”并行化，顯著降低連接建立時延。其核心原理符合RFC7413標準，但受限于系統版本——Linux 3.7+內核支持，而Windows系統尚未兼容，因此目前主要適用于內部服務器間通信，對公網訪問的優化有限。

1.2 HSTS：強制HTTPS與跳轉時延消除

HTTP請求向HTTPS的302跳轉存在兩大缺陷：一是暴露用戶訪問路徑，易受中間人攻擊；二是增加1個RTT時延及瀏覽器解析時間。HSTS（HTTP Strict Transport Security）通過服務端響應頭（`Strict-Transport-Security`）指令，強制瀏覽器在指定周期內將所有HTTP請求自動升級為HTTPS。主流瀏覽器（Chrome、Firefox、IE）已全面支持HSTS，通過預置策略，徹底跳過302跳轉環節，實現“輸入即加密”的用戶體驗。

1.3 Session Resume：會話復用與資源節約

TLS握手過程中的非對稱密鑰交換計算密集，完全握手需2個RTT且消耗大量CPU資源。Session Resume技術通過復用已有會話信息，將完全握手簡化為1個RTT的“簡化握手”。當前主流實現包括Session Cache與Session Ticket兩種模式：

- Session Cache：基于Client Hello中的Session ID查詢服務端緩存，若命中則直接復用會話。其優勢在于兼容所有瀏覽器，但受限于單機內存存儲及開源軟件（如Nginx、Apache）缺乏分布式緩存能力，難以滿足大型網站的高并發需求。百度通過優化TLS協議棧與分布式緩存架構，已實現全局Session Cache，顯著提升訪問速度并降低服務器計算負載。

- Session Ticket：服務端將會話信息加密為Ticket發送至客戶端，后續握手時客戶端攜帶Ticket，服務端解密后完成簡化握手。該模式無需服務端存儲會話，支持分布式擴展，但依賴客戶端支持（當前支持率約60%）且需維護全局密鑰安全。總體而言，Session Ticket在擴展性與資源消耗上更具優勢，是未來客戶端優化的重點方向。

1.4 OCSP Stapling：證書狀態校驗時延優化

傳統OCSP（Online Certificate Status Protocol）校驗需瀏覽器直接向CA站點查詢證書狀態，因CA站點地理位置分散、網絡不穩定，易導致RTT增加。OCSP Stapling（RFC6066）通過服務端在TLS握手時主動返回OCSP響應，避免瀏覽器直接查詢CA。Nginx等服務器已通過`ocsp_stapling_file`指令支持該功能，將證書狀態校驗時延降低至毫秒級，顯著提升HTTPS響應速度。

1.5 False Start：應用層數據提前傳輸

常規TLS握手需完成全部四個階段（Client Hello、Server Hello、Certificate交換、Finished）后才能傳輸應用數據，False Start技術借鑒TFO思路，在Client Hello階段攜帶部分應用數據，節省1個RTT。該技術依賴PFS（Perfect Forward Secrecy）及ECDHE密鑰交換算法，需優先部署ECDHE以實現安全與性能的平衡。

1.6 SPDY/HTTP2：多路復用與協議革新

SPDY（Google主導）與HTTP2（IETF標準化）通過幀控制與多路復用技術，突破HTTP1.x的串行請求限制，支持單一連接上的并發請求傳輸。二者默認強制HTTPS，且兼容現有HTTP語義，對Web應用透明。雖然Google已宣布Chrome 2016年棄用SPDY并全面轉向HTTP2，但國內瀏覽器支持進度滯后，百度服務端與手機瀏覽器已實現SPDY3.1協議支持，為協議演進提供過渡方案。

二、HTTPS計算性能優化：算法選擇與架構升級

HTTPS的加解密計算是服務器CPU的主要負載來源，需通過算法優化、工具升級及架構創新提升計算效率。

2.1 ECC算法：密鑰長度與性能的平衡

RSA算法需2048位密鑰才能滿足安全需求，而ECC（橢圓曲線加密）僅需224位密鑰即可達到同等安全強度。在模指數運算中，ECC的計算效率顯著優于RSA，尤其適用于高并發場景。NIST密鑰長度對照表明確顯示，ECC在安全性與性能上具有明顯優勢，應優先部署。

2.2 OpenSSL版本升級：安全與性能雙提升

新版本OpenSSL在性能優化與漏洞修復上持續迭代。例如OpenSSL 1.0.2通過Intel指令集優化，使橢圓曲線P256計算性能提升4倍；同時，頻繁的版本更新（如2014年5次升級）有效修復了實現層漏洞（如Heartbleed）。因此，保持OpenSSL版本最新是保障安全性與性能的基礎。

2.3 硬件加速方案的局限性與替代路徑

傳統SSL加速卡與GPU加速雖能分擔計算負載，但存在明顯缺陷：算法支持有限（如不支持ECC、GCM）、升級成本高（新協議/漏洞響應滯后）、IO開銷導致性能無法充分利用、維護依賴第三方廠商。基于此，百度創新性地構建了TLS遠程代理計算集群：剝離RSA加解密、ECC密鑰生成等高負載計算任務，通過異步非阻塞架構將計算任務分散至專用集群，實現計算資源與Web服務的解耦，顯著提升整體性能。

三、HTTPS安全配置：協議版本與加密套件精細化

安全是HTTPS的核心目標，需通過協議版本禁用、加密套件優先級設置及攻擊防護策略構建縱深防御體系。

3.1 協議版本選擇：淘汰弱協議，保留兼容性

SSL2.0已證實存在嚴重漏洞且無客戶端支持，可全面禁用；SSL3.0因POODLE攻擊存在安全風險，但仍有0.5%客戶端僅支持該版本，需“有選擇保留”；TLS1.1及以上版本尚未發現漏洞，應優先支持。

3.2 加密套件配置：算法優先級與安全基線

加密套件包含四個核心組件，需按以下策略配置：

- 非對稱密鑰交換算法：優先ECDHE（支持PFS），禁用DHE（性能差），次選RSA；

- 證書簽名算法：默認RSA簽名，禁用SHA1（Chrome、微軟已棄用），優先SHA2及以上；

- 對稱加解密算法：優先AES-GCM（兼顧性能與認證），禁用RC4（RFC7465明確風險）；

- 內容一致性校驗算法：禁用MD5、SHA1，優先SHA2及以上安全哈希函數。

3.3 防攻擊策略：降級攻擊與重協商攻擊防護

- 降級攻擊防護：通過SCSV（TLS_SCSV）機制，阻止客戶端與服務端協商低于服務端最高支持版本的協議，避免攻擊者強制使用弱協議（如SSL3.0）。

- 重協商攻擊防護：禁止客戶端主動發起重協商（易導致弱算法或拒絕服務攻擊），允許服務端在特定場景下主動重協商，兼顧安全與靈活性。

四、結語

HTTPS的優化是一項系統工程，需平衡協議特性、計算資源與業務需求。大型網站的HTTPS部署不僅要實現基礎的加密傳輸，更需通過協議棧深度優化、配置策略精細調整及架構創新，實現速度、性能與安全的協同提升。百度運維團隊的實踐表明，極致的HTTPS優化需結合產品架構與基礎設施進行全局設計，其工程經驗可為同類網站提供重要參考。