上海網(wǎng)站優(yōu)化公司
上海網(wǎng)站優(yōu)化公司
百度于2015年完成全站HTTPS改造，標志著大型網(wǎng)站對安全與性能協(xié)同優(yōu)化的高度重視。作為HTTPS實踐系列的核心篇章，本文聚焦于協(xié)議層深度優(yōu)化與配置策略精細調(diào)整，系統(tǒng)剖析訪問速度提升、計算性能優(yōu)化及安全加固的關(guān)鍵實踐。基于百度運維團隊的實戰(zhàn)經(jīng)驗，本文從技術(shù)原理、工程實現(xiàn)及效果驗證三個維度，為大型網(wǎng)站的HTTPS部署提供可落地的優(yōu)化路徑。
HTTPS的性能瓶頸常源于TCP握手、TLS握手及證書校驗的時延疊加。為突破這一限制，需從協(xié)議機制與配置層面進行系統(tǒng)性優(yōu)化。
HTTPS與HTTP均依賴TCP協(xié)議進行數(shù)據(jù)傳輸，傳統(tǒng)三次握手需1個RTT（Round-Trip Time）僅完成SYN包交互，造成資源浪費。TFO技術(shù)通過在SYN包中攜帶應(yīng)用層數(shù)據(jù)，實現(xiàn)“握手-數(shù)據(jù)傳輸”并行化，顯著降低連接建立時延。其核心原理符合RFC7413標準，但受限于系統(tǒng)版本——Linux 3.7+內(nèi)核支持，而Windows系統(tǒng)尚未兼容，因此目前主要適用于內(nèi)部服務(wù)器間通信，對公網(wǎng)訪問的優(yōu)化有限。
HTTP請求向HTTPS的302跳轉(zhuǎn)存在兩大缺陷：一是暴露用戶訪問路徑，易受中間人攻擊；二是增加1個RTT時延及瀏覽器解析時間。HSTS（HTTP Strict Transport Security）通過服務(wù)端響應(yīng)頭（`Strict-Transport-Security`）指令，強制瀏覽器在指定周期內(nèi)將所有HTTP請求自動升級為HTTPS。主流瀏覽器（Chrome、Firefox、IE）已全面支持HSTS，通過預置策略，徹底跳過302跳轉(zhuǎn)環(huán)節(jié)，實現(xiàn)“輸入即加密”的用戶體驗。
TLS握手過程中的非對稱密鑰交換計算密集，完全握手需2個RTT且消耗大量CPU資源。Session Resume技術(shù)通過復用已有會話信息，將完全握手簡化為1個RTT的“簡化握手”。當前主流實現(xiàn)包括Session Cache與Session Ticket兩種模式：
- Session Cache：基于Client Hello中的Session ID查詢服務(wù)端緩存，若命中則直接復用會話。其優(yōu)勢在于兼容所有瀏覽器，但受限于單機內(nèi)存存儲及開源軟件（如Nginx、Apache）缺乏分布式緩存能力，難以滿足大型網(wǎng)站的高并發(fā)需求。百度通過優(yōu)化TLS協(xié)議棧與分布式緩存架構(gòu)，已實現(xiàn)全局Session Cache，顯著提升訪問速度并降低服務(wù)器計算負載。
- Session Ticket：服務(wù)端將會話信息加密為Ticket發(fā)送至客戶端，后續(xù)握手時客戶端攜帶Ticket，服務(wù)端解密后完成簡化握手。該模式無需服務(wù)端存儲會話，支持分布式擴展，但依賴客戶端支持（當前支持率約60%）且需維護全局密鑰安全?？傮w而言，Session Ticket在擴展性與資源消耗上更具優(yōu)勢，是未來客戶端優(yōu)化的重點方向。
傳統(tǒng)OCSP（Online Certificate Status Protocol）校驗需瀏覽器直接向CA站點查詢證書狀態(tài)，因CA站點地理位置分散、網(wǎng)絡(luò)不穩(wěn)定，易導致RTT增加。OCSP Stapling（RFC6066）通過服務(wù)端在TLS握手時主動返回OCSP響應(yīng)，避免瀏覽器直接查詢CA。Nginx等服務(wù)器已通過`ocsp_stapling_file`指令支持該功能，將證書狀態(tài)校驗時延降低至毫秒級，顯著提升HTTPS響應(yīng)速度。
常規(guī)TLS握手需完成全部四個階段（Client Hello、Server Hello、Certificate交換、Finished）后才能傳輸應(yīng)用數(shù)據(jù)，F(xiàn)alse Start技術(shù)借鑒TFO思路，在Client Hello階段攜帶部分應(yīng)用數(shù)據(jù)，節(jié)省1個RTT。該技術(shù)依賴PFS（Perfect Forward Secrecy）及ECDHE密鑰交換算法，需優(yōu)先部署ECDHE以實現(xiàn)安全與性能的平衡。
SPDY（Google主導）與HTTP2（IETF標準化）通過幀控制與多路復用技術(shù)，突破HTTP1.x的串行請求限制，支持單一連接上的并發(fā)請求傳輸。二者默認強制HTTPS，且兼容現(xiàn)有HTTP語義，對Web應(yīng)用透明。雖然Google已宣布Chrome 2016年棄用SPDY并全面轉(zhuǎn)向HTTP2，但國內(nèi)瀏覽器支持進度滯后，百度服務(wù)端與手機瀏覽器已實現(xiàn)SPDY3.1協(xié)議支持，為協(xié)議演進提供過渡方案。
HTTPS的加解密計算是服務(wù)器CPU的主要負載來源，需通過算法優(yōu)化、工具升級及架構(gòu)創(chuàng)新提升計算效率。
RSA算法需2048位密鑰才能滿足安全需求，而ECC（橢圓曲線加密）僅需224位密鑰即可達到同等安全強度。在模指數(shù)運算中，ECC的計算效率顯著優(yōu)于RSA，尤其適用于高并發(fā)場景。NIST密鑰長度對照表明確顯示，ECC在安全性與性能上具有明顯優(yōu)勢，應(yīng)優(yōu)先部署。
新版本OpenSSL在性能優(yōu)化與漏洞修復上持續(xù)迭代。例如OpenSSL 1.0.2通過Intel指令集優(yōu)化，使橢圓曲線P256計算性能提升4倍；同時，頻繁的版本更新（如2014年5次升級）有效修復了實現(xiàn)層漏洞（如Heartbleed）。因此，保持OpenSSL版本最新是保障安全性與性能的基礎(chǔ)。
傳統(tǒng)SSL加速卡與GPU加速雖能分擔計算負載，但存在明顯缺陷：算法支持有限（如不支持ECC、GCM）、升級成本高（新協(xié)議/漏洞響應(yīng)滯后）、IO開銷導致性能無法充分利用、維護依賴第三方廠商?；诖?，百度創(chuàng)新性地構(gòu)建了TLS遠程代理計算集群：剝離RSA加解密、ECC密鑰生成等高負載計算任務(wù)，通過異步非阻塞架構(gòu)將計算任務(wù)分散至專用集群，實現(xiàn)計算資源與Web服務(wù)的解耦，顯著提升整體性能。
安全是HTTPS的核心目標，需通過協(xié)議版本禁用、加密套件優(yōu)先級設(shè)置及攻擊防護策略構(gòu)建縱深防御體系。
SSL2.0已證實存在嚴重漏洞且無客戶端支持，可全面禁用；SSL3.0因POODLE攻擊存在安全風險，但仍有0.5%客戶端僅支持該版本，需“有選擇保留”；TLS1.1及以上版本尚未發(fā)現(xiàn)漏洞，應(yīng)優(yōu)先支持。
加密套件包含四個核心組件，需按以下策略配置：
- 非對稱密鑰交換算法：優(yōu)先ECDHE（支持PFS），禁用DHE（性能差），次選RSA；
- 證書簽名算法：默認RSA簽名，禁用SHA1（Chrome、微軟已棄用），優(yōu)先SHA2及以上；
- 對稱加解密算法：優(yōu)先AES-GCM（兼顧性能與認證），禁用RC4（RFC7465明確風險）；
- 內(nèi)容一致性校驗算法：禁用MD5、SHA1，優(yōu)先SHA2及以上安全哈希函數(shù)。
- 降級攻擊防護：通過SCSV（TLS_SCSV）機制，阻止客戶端與服務(wù)端協(xié)商低于服務(wù)端最高支持版本的協(xié)議，避免攻擊者強制使用弱協(xié)議（如SSL3.0）。
- 重協(xié)商攻擊防護：禁止客戶端主動發(fā)起重協(xié)商（易導致弱算法或拒絕服務(wù)攻擊），允許服務(wù)端在特定場景下主動重協(xié)商，兼顧安全與靈活性。
HTTPS的優(yōu)化是一項系統(tǒng)工程，需平衡協(xié)議特性、計算資源與業(yè)務(wù)需求。大型網(wǎng)站的HTTPS部署不僅要實現(xiàn)基礎(chǔ)的加密傳輸，更需通過協(xié)議棧深度優(yōu)化、配置策略精細調(diào)整及架構(gòu)創(chuàng)新，實現(xiàn)速度、性能與安全的協(xié)同提升。百度運維團隊的實踐表明，極致的HTTPS優(yōu)化需結(jié)合產(chǎn)品架構(gòu)與基礎(chǔ)設(shè)施進行全局設(shè)計，其工程經(jīng)驗可為同類網(wǎng)站提供重要參考。
