百度于2015年全面完成HTTPS改造，這一歷程中積累了豐富的實踐經驗。然而，當前行業內關于HTTPS部署的技術文檔多聚焦協議層本身，鮮少涉及大型網站在HTTPS遷移過程中面臨的非協議層挑戰。本文基于百度運維團隊的實戰經驗，系統闡述HTTPS全站部署的實踐邏輯與策略權衡，旨在為同業者提供參考。

1 前言：HTTPS部署的現實困惑

HTTPS作為保障傳輸安全的核心技術，其部署在大型互聯網站點中仍面臨諸多實踐難題。現有技術文獻多局限于協議原理講解，而針對海量用戶、復雜業務場景下的HTTPS落地經驗分享較為匱乏。企業在推進HTTPS改造時，往往因缺乏系統指引而陷入“是否全站覆蓋”“如何兼容第三方資源”“性能如何優化”等困惑。本文將通過梳理百度HTTPS改造的實踐經驗，揭示協議層之外的關鍵工作，以期拋磚引玉，推動行業技術交流。

2 協議層以外的實踐工作

##### 2.1 全站HTTPS覆蓋的必要性

部分初學者認為，僅將主域名升級HTTPS即可滿足安全需求，實則不然。HTTPS的核心價值在于構建端到端的安全傳輸通道，若主域名采用HTTPS，但其加載的JS、CSS、圖片等資源仍通過HTTP傳輸，將導致安全防護形同虛設。此類資源易遭受中間人劫持或篡改，一旦用戶設備被植入惡意腳本，HTTPS的加密意義將蕩然無存。

瀏覽器為應對此類問題，設計了嚴格的安全提示機制：當頁面加載混合資源時，地址欄的鎖形標志可能由綠色變為黃色，部分瀏覽器（如IE）甚至會彈出安全警告，嚴重影響用戶體驗。部分用戶為消除警告而選擇“允許加載”，實則進一步暴露了安全隱患。值得注意的是，移動端瀏覽器對混合資源的限制相對寬松，但這并不意味著可忽視HTTP資源的安全風險。若全站資源未統一HTTPS，輕則導致功能異常，重則引發用戶對平臺安全性的信任危機。

##### 2.2 不同站點的HTTPS部署策略

HTTPS部署并非簡單的“證書配置+Web服務器支持”，其復雜度與站點特性強相關。在大型網站的遷移工作中，協議層優化僅占整體工作的20%-40%，其余精力需投入資源適配、第三方協作、性能優化等環節。針對不同類型站點，HTTPS部署需采取差異化策略：

2.2.1 簡單個人站點

此類站點資源僅從主域或其子域名加載，如axyzblog.com的博客僅調用自身域名的JS與圖片。HTTPS部署相對便捷：在證書完備且Web服務器支持HTTPS的前提下，僅需將主域接入HTTPS，并將資源鏈接修改為https://或協議相對路徑（//）。

2.2.2 復雜個人站點

若資源需從外部域名加載（如CDN、第三方庫），HTTPS部署則面臨額外挑戰。CDN服務商的HTTPS支持能力參差不齊，部分廠商對HTTPS流量收取額外費用。當前主流CDNHTTPS方案包括：

- 網站主提供私鑰，CDN回源采用HTTP；

- CDN使用公共域名及證書，資源域名不可自定義；

- 僅提供動態加速，CDN作為TCP代理不緩存內容；

- CloudFlare的Keyless SSL服務，避免私鑰泄露風險。

2.2.3 簡單大型站點

此類站點資源僅從主域、子域或自建CDN加載，極少依賴第三方資源，如Google、Twitter的范例。其優勢在于HTTPS遷移改造成本較低；但缺點是需放棄部分第三方資源，對業務擴展性形成制約。

2.2.4 復雜且速度容忍度高的大型站點

多見于平臺類、內容聚合型網站（如門戶、視頻、電商平臺），需加載大量第三方資源。此類站點可推動全域名HTTPS升級：流量接入層同時支持HTTP與HTTPS，前端通過協議相對路徑（//）實現資源自動適配。對于第三方資源，需遷移至自建CDN或強制要求對方支持HTTPS。Facebook的實踐表明，若平臺具備足夠影響力，合作方愿意為適配HTTPS投入資源；反之，若接入方為個人開發者且商業價值有限，則需權衡強制HTTPS的可行性。此類方案的優點是前端改動簡單、混合資源風險低，缺點是可能增加訪問延遲（如2.5秒升至3秒），且對第三方要求較高。

2.2.5 復雜且速度要求嚴格的大型站點

此類站點用戶停留時間短，對響應速度敏感（如工具類網站）。HTTPS部署需在安全與性能間尋求平衡，后續章節將深入探討優化策略。

##### 2.3 域名策略的優化邏輯

域名數量對訪問速度的影響具有雙重性：域名過多會增加DNS解析與TCP連接建立時間；域名過少則降低資源下載并發度。在HTTPS場景下，TCP連接重建成本更高，需謹慎控制域名數量。以百度為例，其頁面資源種類豐富，不同類型資源由多域名（子產品或第三方服務）提供，頻繁切換域名會導致SSL握手延遲。通過限制域名范圍、維持長連接，并結合SPDY/HTTP2.0的并發特性，可有效平衡性能與資源加載需求。

##### 2.4 連接復用的技術實踐

連接復用可從TCP與SSL兩個層面分析，其核心目標是減少握手延遲，提升資源加載效率。

2.4.1 連接復用的意義

HTTP協議（RFC2616）曾規定單域名最大并發連接數為2，但現代網頁元素數量激增，此限制已不適用。當前瀏覽器普遍支持單域名6-8個并發連接（如表1所示）。在HTTP場景下，多域名并發可有效提升速度；但在HTTPS場景中，TLS握手成本較高，盲目增加域名數量反而加劇延遲。HTTP2.0的多路復用特性進一步要求優化域名策略，避免多連接對性能的稀釋。

表1 瀏覽器單域名最大并發連接數

| 瀏覽器 | 最大并發連接數 |

|--------------|----------------|

| Chrome | 6 |

| Firefox | 6 |

| Safari | 8 |

2.4.2 預建連接技術

為減少用戶感知的握手延遲，可通過預判用戶行為提前建立連接。例如，在主域請求靜態資源時預建TCP與TLS連接，后續請求直接復用。但實際效果受瀏覽器調度策略影響：若同一域名需加載大量資源（如10張圖片），瀏覽器仍可能新建連接。

2.4.3 SPDY/HTTP2.0的賦能

SPDY協議通過支持單連接并發請求，顯著提升連接復用率。HTTP2.0在此基礎上進一步優化，其多路復用與頭部壓縮特性，使得多域名策略的必要性降低。

##### 2.5 優化效果的量化分析

根據百度實踐，若未開啟HSTS，用戶直接訪問HTTP主域再302跳轉至HTTPS，平均延遲增加400ms以上，其中302跳轉與SSL握手各占50%。但通過預建連接、HTTP2.0優化等技術，后續請求可實現幾乎無感知的加載體驗。目前團隊仍在持續優化首屏加載速度，以進一步降低用戶等待成本。

3 HTTPS遷移的常見問題與應對

##### 3.1 Referrer傳遞的兼容方案

HTTPS站點向HTTP站點傳遞外鏈時，瀏覽器默認屏蔽Referrer信息。可通過meta標簽實現可控傳遞：

```html

```

對于不支持meta標簽的瀏覽器（如IE8），可采用二次跳轉方案：先通過HTTPS跳轉至可控HTTP站點，將Referrer信息嵌入URL參數，再跳轉至目標地址。

##### 3.2 Form提交的安全兼容

若需向HTTP第三方站點提交表單，瀏覽器會彈出安全警告。可采用與Referrer傳遞類似的跳轉邏輯，但需注意此類方案仍存在劫持與隱私泄露風險，根本解決需依賴瀏覽器升級與全站HTTPS普及。

##### 3.3 視頻播放的協議適配

HTTP視頻源會導致瀏覽器安全警告，需選擇HTTPS視頻源或切換至非HTTP協議（如RTMP）。

##### 3.4 用戶異常的排查方向

遷移過程中，用戶反饋的異常問題多源于環境因素：

- 系統時間錯誤導致證書過期；

- 代理工具（如Fiddler）未配置根證書；

- 跨網DNS解析被運營商攔截；

- 特定網絡環境HTTPS失敗率高；

- 基礎網絡連通性問題導致的整體延遲。

4 結束語：安全與體驗的平衡之道

大型網站的HTTPS部署是一項系統工程，需超越協議層本身，統籌資源適配、性能優化、第三方協作等環節。盡管過程中面臨全站覆蓋難度、性能損耗、第三方兼容等挑戰，但HTTPS上線后，劫持導致的用戶功能異常與隱私泄露事件顯著減少。技術團隊的每一點優化，最終都轉化為用戶對平臺安全性的信任。HTTPS并非“高不可攀”，關鍵在于以系統化思維解決實踐問題。愿本文經驗能為同業者提供借鑒，共同推動互聯網安全生態的升級。