HTTPS 的作用是在會話層、表示層引入 TLS/SSL 握手協(xié)議，通過數(shù)據(jù)加密、解密方式，來應(yīng)對數(shù)據(jù)明文傳輸過程中遇到的問題，保障數(shù)據(jù)的完整性、一致性，為用戶帶來更安全的網(wǎng)絡(luò)體驗(yàn)、更好的隱私保護(hù)。

然而，HTTPS 增加了 TLS/SSL 握手環(huán)節(jié)，再加上應(yīng)用數(shù)據(jù)傳輸需要經(jīng)過對稱加密，對性能提出了更大的挑戰(zhàn)。

作為一個(gè)好的架構(gòu)，一定要均衡安全和性能兩方面，如果讓天秤向任何一方傾斜過多，都會影響最終的用戶體驗(yàn)。

因此，為了兼顧安全與性能，蘇寧的全站 HTTPS 改造從 2015 年底開始進(jìn)行，歷時(shí)一年多時(shí)間，主要做了系統(tǒng) HTTPS 改造、HTTPS 性能優(yōu)化和 HTTPS 灰度上線這三方面工作，讓用戶在 HTTPS 下訪問能夠獲得極致體驗(yàn)成為了可能。

網(wǎng)頁制作全站 HTTPS 方案概述

蘇寧易購從 2015 年開始規(guī)劃做 HTTPS 相關(guān)的事情，當(dāng)時(shí)可借鑒的資料非常少，電商類網(wǎng)站相關(guān)的 HTTPS 改造的詳盡案例更是難求。

如下圖，是蘇寧易購全站的 HTTPS 方案：

如圖中所示，整個(gè)方案分三步構(gòu)建，分別是系統(tǒng)改造、性能優(yōu)化和灰度上線：

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

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

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

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

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

網(wǎng)頁制作HTTPS 方案之系統(tǒng)改造篇

01、網(wǎng)站建設(shè)HTTPS 接入層定義

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

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

如下圖，是蘇寧易購架構(gòu)中 HTTPS 接入層的位置：

如圖中所示，我們把 HTTPS 接入層放在 CDN 和應(yīng)用系統(tǒng)之間，采用四層+七層負(fù)載均衡的架構(gòu)。

四層負(fù)載并不處理 HTTPS 卸載，它的主要職責(zé)是做 TCP 的分發(fā)。在七層負(fù)載完成整個(gè) SSL 握手，而后面應(yīng)用系統(tǒng)走 80 端口，這樣就相當(dāng)于完成了 HTTPS 整個(gè)卸載的過程。

這樣做的好處，一方面，系統(tǒng)應(yīng)用層面不需要為 HTTPS 做任何調(diào)整；另一方面，將來所有 HTTPS 的調(diào)度、優(yōu)化和配置都可以在接入層完成。

02、網(wǎng)站制作頁面資源替換

第一步，理解 Mixed Content

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

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

第二步，網(wǎng)站建設(shè)技巧之// 替換 http://

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

第三步，網(wǎng)頁制作技巧之x-request-url 的定義和使用

當(dāng)然，我們在//替換過程中也遇到了一些坑。舉個(gè)例子，下圖是蘇寧易購單點(diǎn)登錄系統(tǒng)交互的過程：

如圖中所示，當(dāng)用戶 authID 失效，發(fā)起請求 https://xxx.suning.com/authStatus 鑒權(quán)，接入層會對所有請求做卸載，地址就會變成 HTTP。

進(jìn)入業(yè)務(wù)系統(tǒng)做鑒權(quán)的話，Reponse 302 就會跳轉(zhuǎn)到單點(diǎn)登錄系統(tǒng)。這時(shí)會將第二步的頁面記錄為原始頁面，返回到用戶端，用戶去請求單點(diǎn)登錄系統(tǒng)，單點(diǎn)登錄系統(tǒng)完成鑒權(quán)以后，再回跳時(shí)，是 HTTP 地址，最終導(dǎo)致用戶端 MixContent。

因此，我們引入 x-request-url 解決問題，如下圖：

所有原始請求協(xié)議都記錄在 x-request-url 中，如果業(yè)務(wù)系統(tǒng)鑒權(quán)，一定要遵循 x-request-url 記錄的協(xié)議，就可應(yīng)對回跳導(dǎo)致的用戶端 Mix Content 問題。

03、App 原生開發(fā)之無法識別//的問題

出現(xiàn)瀏覽器可以識別 //，但 App 原生無法識別 // 的原因很簡單，因?yàn)闉g覽器本身做了適配。

當(dāng)時(shí)，蘇寧服務(wù)端有一個(gè)系統(tǒng)，專門提供一個(gè)接口，向各個(gè)端提供圖片。做完 HTTPS 改造之后，PC 端和客戶端都沒有問題。但是第二天，很多用戶突然就不能加載圖片，原因是請求在 APP 原生情況下沒法識別 //。

這里的解決方法，只能是客戶端開發(fā)人員做適配，下圖是 App 無法識別//的一個(gè)例子：

04、網(wǎng)站制作技巧之如何處理商用 CDN 上的證書和私鑰？

CPN 證書的處理是大多數(shù)小型互聯(lián)網(wǎng)企業(yè)都會遇到的問題。因?yàn)檫@些小企業(yè)不像阿里、京東可自建 CDN，蘇寧也是一樣。

蘇寧的 CDN 由自建和商用兩種組成，一旦使用商用 CDN，就會面臨 HTTPS 如何過去的問題。

企業(yè)只要將私鑰給到第三方或廠商之后，在所有廠商的 CDN 服務(wù)器都沒辦法控制。當(dāng)有黑客攻擊完廠商服務(wù)器后，加密已沒任何意義，因?yàn)樗借€已經(jīng)泄露。

如下圖，業(yè)界比較公認(rèn)的應(yīng)對方式分別是：雙證書的策略、四層加速和 Keyless 解決方案。

• 雙證書的策略。它的思想很簡單，相當(dāng)于用戶到 CDN 端，提供的是 CDN 的證書，做加解密。從 CDN 到應(yīng)用服務(wù)器端用的是應(yīng)用自有的證書來做加解密。

  這樣的方式，可以保證應(yīng)用端的密鑰不用提供給 CDN 廠商，但根本的問題還是沒有解決，那就是 CDN 廠商的證書仍然有泄露的可能。如果泄露了，用戶端還是會受到影響。

• 四層加速。很多 CDN 廠商都有能力提供 TCP 加速，做動態(tài)、還原和擇優(yōu)等。CDN 廠商只做四層模式和 TCP 代理，不考慮請求緩存。

  這樣就沒必要將證書暴露給 CDN 廠商，這種方式適用于動態(tài)回源請求，比如加入購物車、提交訂單、登錄等。

• Keyless 解決方案。適用于金融，提供一臺實(shí)時(shí)計(jì)算的 Key Server 。

當(dāng) CDN 要用到私鑰時(shí)，通過加密通道將必要的參數(shù)傳給 Key Server，由 Key Server 算出結(jié)果并返回即可。

05、網(wǎng)頁制作技巧之HTTPS 測試策略

當(dāng)引入一個(gè)新的協(xié)議，如何進(jìn)行測試呢？主要步驟，如下圖：

• 源碼掃描。當(dāng)開發(fā)人員完成資源替換后，利用 Jenkins 遍歷代碼庫，shell 腳本掃描出 HTTP 鏈接。

• 對頁面爬蟲掃描。我們會寫一些爬蟲腳本，對測試環(huán)境的鏈接進(jìn)行掃描。

• 測試環(huán)境驗(yàn)證。自動化測試固然好，但是主要核心流程還是需要手動覆蓋一遍，防止 HTTPS 對頁面加載出現(xiàn)未知影響。

  如有些頁面是用 HTTPS 去訪問，可能這個(gè)系統(tǒng)還不支持 HTTPS，必須要手動驗(yàn)證。

• 線上預(yù)發(fā)和引流測試。HTTPS 的改造版本發(fā)到線上對用戶來講是沒有影響的，因?yàn)橛脩羰褂玫倪€是 HTTP 流量。

  可以選擇線上預(yù)發(fā)的方式，預(yù)發(fā)驗(yàn)證完畢后，通過 301 的方式，將用戶的流量從 HTTP 切到 HTTPS，這個(gè)后面講灰度時(shí)還會深入講解。

另外，我們還引入了引流測試系統(tǒng)：

它的思路很簡單，根據(jù)域名、用戶請求做捕獲，將所有捕獲流量放到 Copy Server 中去擴(kuò)大，放大若干倍，然后通過 Sender 再發(fā)送回到系統(tǒng)中。

這樣的方式，可以通過用戶的真實(shí)流量，來驗(yàn)證 HTTPS 的功能性和性能影響有多大。（全文未完詳見下篇）深圳網(wǎng)站建設(shè)博納網(wǎng)絡(luò)編輯整理。