• 系統(tǒng)改造。原有系統(tǒng)想要支持 HTTPS，必須進行改造，首先要建立 HTTPS 接入層，也就是開通 443 端口，讓所有的應(yīng)用系統(tǒng)支持 HTTPS 訪問。

  在此基礎(chǔ)上做頁面資源替換，解決當一個 HTTPS 頁面出現(xiàn) HTTP 請求時就會出現(xiàn)錯誤的問題。做完這兩件事，CDN 上證書的處理、HTTPS 測試方案等問題也就迎刃而解。

• 性能優(yōu)化。做系統(tǒng)改造，增加兩次 TLS 握手，必然會對性能造成一定的開銷和損失，如何去彌補性能的損失，達到性能和安全兼顧呢？性能優(yōu)化部分包含若干優(yōu)化點，下文會詳細展開。

• 灰度上線。這部分是時間花費最多的，HTTPS 一步步上線的過程中，踩坑最多，其中部分是前面沒有發(fā)現(xiàn)的問題。

  這證明不能一次性將整個全站、全地區(qū)、全用戶一次性堆成 HTTPS，可以根據(jù)流量所處的運營商和城市及用戶級別去做灰度上線。

01、HTTPS 接入層定義

系統(tǒng)改造的頭等大事是開通 443 端口，成熟的網(wǎng)絡(luò)系統(tǒng)會包含 CDN、硬件負載均衡、應(yīng)用防火墻、Web 服務(wù)器、應(yīng)用服務(wù)器，最后到數(shù)據(jù)層。難道整個鏈路都要做 HTTPS？在每層都增加 SSL 握手消耗嗎？答案是否定的。

所以，應(yīng)該盡早完成 SSL 握手，做 SSL 過程中首要考慮的是 HTTPS 接入層的定位。

02、頁面資源替換

第一步，理解 Mixed Content

對于一個頁面而言，請求頁面的請求是用 HTTPS 加載，一旦內(nèi)部頁面元素有 HTTP 的性質(zhì)，這時 RFC 標準里就會出現(xiàn)一個錯誤，叫 Mixed Content（混淆錯誤）。

所以，如果要加載一個安全的 HTTPS 頁面，就不應(yīng)該在其中混淆 HTTP 請求。

第二步，// 替換 http://

用 // 替換 http://，這樣就可以讓頁面所有的元素做一個適配，去遵循原來的請求。