唐山網(wǎng)站建設(shè),唐山網(wǎng)站制作,唐山做網(wǎng)站,唐山網(wǎng)頁設(shè)計,唐山網(wǎng)站優(yōu)化,唐山網(wǎng)絡(luò)公司,唐山400電話業(yè)務(wù) 24小時熱線：15031560143 關(guān)于我們 | 網(wǎng)站模版 | 支付方式 | 網(wǎng)站地圖
HTTPS 的作用是在會話層、表示層引入 TLS/SSL 握手協(xié)議，通過數(shù)據(jù)加密、解密方式，來應(yīng)對數(shù)據(jù)明文傳輸過程中遇到的問題，保障數(shù)據(jù)的完整性、一致性，為用戶帶來更安全的網(wǎng)絡(luò)體驗、更好的隱私保護。
然而，HTTPS 增加了 TLS/SSL 握手環(huán)節(jié)，再加上應(yīng)用數(shù)據(jù)傳輸需要經(jīng)過對稱加密，對性能提出了更大的挑戰(zhàn)。
作為一個好的架構(gòu)，一定要均衡安全和性能兩方面，如果讓天秤向任何一方傾斜過多，都會影響最終的用戶體驗。
因此，為了兼顧安全與性能，蘇寧的全站 HTTPS 改造從 2015 年底開始進行，歷時一年多時間，主要做了系統(tǒng) HTTPS 改造、HTTPS 性能優(yōu)化和 HTTPS 灰度上線這三方面工作，讓用戶在 HTTPS 下訪問能夠獲得極致體驗成為了可能。
全站 HTTPS 方案概述
蘇寧易購從 2015 年開始規(guī)劃做 HTTPS 相關(guān)的事情，當時可借鑒的資料非常少，電商類網(wǎng)站相關(guān)的 HTTPS 改造的詳盡案例更是難求。
如下圖，是蘇寧易購全站的 HTTPS 方案：
如圖中所示，整個方案分三步構(gòu)建，分別是系統(tǒng)改造、性能優(yōu)化和灰度上線：
系統(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)化點，下文會詳細展開。
灰度上線。唐山網(wǎng)站建設(shè)這部分是時間花費最多的，HTTPS 一步步上線的過程中，踩坑最多，其中部分是前面沒有發(fā)現(xiàn)的問題。
這證明不能一次性將整個全站、全地區(qū)、全用戶一次性堆成 HTTPS，可以根據(jù)流量所處的運營商和城市及用戶級別去做灰度上線。
HTTPS 方案之系統(tǒng)改造篇
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 接入層的定位。
如下圖，是蘇寧易購架構(gòu)中 HTTPS 接入層的位置：
如圖中所示，我們把 HTTPS 接入層放在 CDN 和應(yīng)用系統(tǒng)之間，采用四層+七層負載均衡的架構(gòu)。
四層負載并不處理 HTTPS 卸載，它的主要職責是做 TCP 的分發(fā)。在七層負載完成整個 SSL 握手，而后面應(yīng)用系統(tǒng)走 80 端口，這樣就相當于完成了 HTTPS 整個卸載的過程。
這樣做的好處，一方面，系統(tǒng)應(yīng)用層面不需要為 HTTPS 做任何調(diào)整；另一方面，將來所有 HTTPS 的調(diào)度、優(yōu)化和配置都可以在接入層完成。
02、頁面資源替換
第一步，理解 Mixed Content
對于一個頁面而言，請求頁面的請求是用 HTTPS 加載，一旦內(nèi)部頁面元素有 HTTP 的性質(zhì)，這時 RFC 標準里就會出現(xiàn)一個錯誤，叫 Mixed Content（混淆錯誤）。
所以，如果要加載一個安全的 HTTPS 頁面，就不應(yīng)該在其中混淆 HTTP 請求。
第二步，// 替換 http://
用 // 替換 http://，這樣就可以讓頁面所有的元素做一個適配，去遵循原來的請求。
第三步，x-request-url 的定義和使用
當然，我們在//替換過程中也遇到了一些坑。舉個例子，下圖是蘇寧易購單點登錄系統(tǒng)交互的過程：
如圖中所示，當用戶 authID 失效，發(fā)起請求 https://xxx.suning.com/authStatus 鑒權(quán)，接入層會對所有請求做卸載，地址就會變成 HTTP。
進入業(yè)務(wù)系統(tǒng)做鑒權(quán)的話，Reponse 302 就會跳轉(zhuǎn)到單點登錄系統(tǒng)。這時會將第二步的頁面記錄為原始頁面，返回到用戶端，用戶去請求單點登錄系統(tǒng)，單點登錄系統(tǒng)完成鑒權(quán)以后，再回跳時，是 HTTP 地址，最終導致用戶端 MixContent。
因此，我們引入 x-request-url 解決問題，如下圖：
所有原始請求協(xié)議都記錄在 x-request-url 中，如果業(yè)務(wù)系統(tǒng)鑒權(quán)，一定要遵循 x-request-url 記錄的協(xié)議，就可應(yīng)對回跳導致的用戶端 Mix Content 問題。