【51CTO.com原創(chuàng)稿件】眾所周知，數(shù)據(jù)HTTP明文傳輸過程中，會遇到如劫持、篡改、監(jiān)聽、竊取等一系列問題，解決這一問題的方法就是做HTTPS改造。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)的事情，當(dāng)時可借鑒的資料非常少，電商類網(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ǔ)上做頁面資源替換，解決當(dāng)一個HTTPS頁面出現(xiàn)HTTP請求時就會出現(xiàn)錯誤的問題。做完這兩件事，CDN上證書的處理、HTTPS測試方案等問題也就迎刃而解。
• 性能優(yōu)化。做系統(tǒng)改造，增加兩次TLS握手，必然會對性能造成一定的開銷和損失，如何去彌補性能的損失，達到性能和安全兼顧呢?性能優(yōu)化部分包含若干優(yōu)化點，下文會詳細展開。
• 灰度上線。這部分是時間花費最多的，HTTPS一步步上線的過程中，踩坑最多，其中部分是前面沒有發(fā)現(xiàn)的問題。這證明不能一次性將整個全站、全地區(qū)、全用戶一次性堆成HTTPS，可以根據(jù)流量所處的運營商和城市及用戶級別去做灰度上線。

HTTPS方案之系統(tǒng)改造篇

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卸載，它的主要職責(zé)是做TCP的分發(fā)。在七層負載完成整個SSL握手，而后面應(yīng)用系統(tǒng)走80 端口，這樣就相當(dāng)于完成了HTTPS整個卸載的過程。

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

頁面資源替換

第一步，理解Mixed Content

對于一個頁面而言，請求頁面的請求是用HTTPS加載，一旦內(nèi)部頁面元素有HTTP的性質(zhì)，這時RFC標準里就會出現(xiàn)一個錯誤，叫Mixed Content(混淆錯誤)。所以，如果要加載一個安全的HTTPS頁面，就不應(yīng)該在其中混淆HTTP請求。

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

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

第三步，x-request-url的定義和使用

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

如圖中所示，當(dā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地址，最終導(dǎo)致用戶端Mix Content。

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

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

App原生無法識別//的問題

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

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

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

如何處理商用CDN上的證書和私鑰?

CPN證書的處理是大多數(shù)小型互聯(lián)網(wǎng)企業(yè)都會遇到的問題。因為這些小企業(yè)不像阿里、京東可自建CDN，蘇寧也是一樣。蘇寧的CDN由自建和商用兩種組成，一旦使用商用CDN，就會面臨HTTPS如何過去的問題。企業(yè)只要將私鑰給到第三方或廠商之后，在所有廠商的CDN服務(wù)器都沒辦法控制。當(dāng)有黑客攻擊完廠商服務(wù)器后，加密已沒任何意義，因為私鑰已經(jīng)泄露。

如下圖，業(yè)界比較公認的應(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解決方案。適用于金融，提供一臺實時計算的 Key Server 。

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

HTTPS測試策略

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

• 源碼掃描。當(dāng)開發(fā)人員完成資源替換后，利用Jenkins遍歷代碼庫，shell腳本掃描出HTTP鏈接。
• 對頁面爬蟲掃描。我們會寫一些爬蟲腳本，對測試環(huán)境的鏈接進行掃描。
• 測試環(huán)境驗證。自動化測試固然好，但是主要核心流程還是需要手動覆蓋一遍，防止HTTPS對頁面加載出現(xiàn)未知影響。如有些頁面是用HTTPS去訪問，可能這個系統(tǒng)還不支持HTTPS，必須要手動驗證。
• 線上預(yù)發(fā)和引流測試。HTTPS的改造版本發(fā)到線上對用戶來講是沒有影響的，因為用戶使用的還是HTTP流量?？梢赃x擇線上預(yù)發(fā)的方式，預(yù)發(fā)驗證完畢后，通過301的方式，將用戶的流量從HTTP切到HTTPS，這個后面講灰度時還會深入講。

另外，我們還引入了引流測試系統(tǒng)： 它的思路很簡單，根據(jù)域名、用戶請求做捕獲，將所有捕獲流量放到Copy Server中去擴大，放大若干倍，然后通過Sender再發(fā)送回到系統(tǒng)中。這樣的方式，可以通過用戶的真實流量，來驗證HTTPS的功能性和性能影響有多大。

HTTPS方案之性能優(yōu)化篇

談如何優(yōu)化HTTPS的性能之前，我們先來看看整個TLS握手流程，如下圖：

如圖中所示，一個握手過程最壞的情況下，要分為八個步驟：

1. 發(fā)送Syn包到Web客戶端，收到并確認后，同時發(fā)送SynAck到服務(wù)器，這時還是一個HTTP的請求。
2. HTTP轉(zhuǎn)換HTTPS，需要做一次302或者301跳轉(zhuǎn)。
3. 用戶再次發(fā)送HTTPS請求，做一次TCP握手。
4. 做TLS完全握手第一階段，Client hello到Server hello。
5. 當(dāng)證書首次到客戶端，客戶端需要走驗證流程，做CA域名解析。
6. 第二次，TLS握手。
7. 在線證書合法性校驗的過程。
8. TLS完全握手第二階段，底部灰色部分才是真正的數(shù)據(jù)通訊。

蘇寧易購的全站HTTPS方案在性能優(yōu)化方面做了很多事情，如HSTS、Session resume、Ocsp stapling的合理使用，如客戶端HTTPS性能、HttpDNS 解決 DNS攻擊劫持等優(yōu)化。

HSTS的合理使用

Web安全協(xié)議HSTS的作用是強制客戶端(如瀏覽器)使用HTTPS與服務(wù)器創(chuàng)建連接。

優(yōu)點是減少HTTP做302跳轉(zhuǎn)的開銷。302跳轉(zhuǎn)不僅暴露了用戶的訪問站點，也很容易被中間者劫持(降級劫持、中間人攻擊)，最重要是降低了訪問速度(影響性能)。

缺點是HSTS在max-age過期時間內(nèi)，在客戶端是強制HTTPS的，服務(wù)端無法控制。因此，當(dāng)需要降級時，HTTPS無法及時切換到HTTP。當(dāng)然你也可以通過手動動態(tài)去配置maxage的值，這樣可以通過將maxage設(shè)置為0來達到降級效果。還有HSTS是嚴格的HTTPS，一旦網(wǎng)絡(luò)證書錯誤時，網(wǎng)頁將直接無法訪問(用戶無法選擇忽視)。

Session resume的合理使用

當(dāng)用戶端和客戶端、客戶端和服務(wù)端完成第一次TLS握手之后，第二次數(shù)據(jù)傳輸還需要TLS握手嗎?這里可以采用Session復(fù)用的方式。Session resume(會話復(fù)用)，是RFC標準中早就定好的一個機制，HTTPS最初發(fā)布時就已經(jīng)涉及其中。

Session復(fù)用有Session ID和Session tickets兩種方式，下圖是實現(xiàn)流程：

Session ID。使用 client hello 中的 session ID查詢服務(wù)端的 session cache, 如果服務(wù)端有對應(yīng)的緩存，則直接使用已有的 session 信息提前完成握手，稱為簡化握手。Session ID 是 TLS 協(xié)議的標準字段，市面上的瀏覽器全部都支持 Session ID。需要注意的是，單機多進程間共享ssl session對集群環(huán)境是沒有意義的。因此，在這里需要實現(xiàn)多機共享Session ID。可以放在redis中，nginx提供了專門處理Session ID的模塊ssl_session_fetch_by_lua_block。

Session tickets。Session tickets是會話ID的一種補充，server 將 session 信息加密成 ticket 發(fā)送給瀏覽器，瀏覽器在后續(xù)握手請求時會發(fā)送 ticket，server 端如果能成功解密和處理 ticket，就能完成簡化握手。顯然，session ticket 的優(yōu)點是不需要服務(wù)端消耗大量資源來存儲 session 內(nèi)容。但是session ticket 只是 TLS 協(xié)議的一個擴展特性，目前的支持率不是很廣泛，只有 60% 左右，還需要維護一個全局的 key 來加解密，需要考慮 KEY 的安全性和部署效率。

Ocsp stapling的合理使用

Ocsp 全稱在線證書狀態(tài)檢查協(xié)議 (rfc6960)，用來向 CA 站點查詢證書狀態(tài)，比如證書是否被撤銷，是否已經(jīng)過期等。通常情況下，瀏覽器使用 OCSP 協(xié)議發(fā)起查詢請求，CA 返回證書狀態(tài)內(nèi)容，然后瀏覽器接受證書是否可信的狀態(tài)。

如下圖，是Ocsp實現(xiàn)流程：

這個過程非常消耗時間，因為 CA 站點有可能在國外，導(dǎo)致網(wǎng)絡(luò)不穩(wěn)定，RTT 也比較大。那有沒有辦法不直接向 CA 站點請求 OCSP 內(nèi)容呢?

ocsp stapling 就能實現(xiàn)這個功能。ocsp stapling的原理簡單來說是服務(wù)端代替客戶端完成CA校驗證書的過程，節(jié)省用戶端的時間開銷。就是當(dāng)瀏覽器發(fā)起 client hello 時會攜帶一個 certificate status request 的擴展，服務(wù)端看到這個擴展后將 OCSP 內(nèi)容直接返回給瀏覽器，完成證書狀態(tài)檢查。

由于瀏覽器不需要直接向 CA 站點查詢證書狀態(tài)，這個功能對訪問速度的提升非常明顯。

HTTPS方案之灰度上線篇

灰度上線可遵循灰度、降級和開閉三大原則?；叶仍瓌t是指整個上線過程要按區(qū)域、版本、用戶等級來進行灰度，通過灰度收集上來的用戶數(shù)據(jù)來決定整個計劃的進行。降級原則保證每一步的操作都是可逆可回滾的，即對擴展開放，對修改關(guān)閉，這是可復(fù)用設(shè)計的基石。

HTTPS開關(guān)控制

HTTPS開關(guān)控制方面，蘇寧主要建設(shè)內(nèi)容管理、CDN、客戶端三大開關(guān)：

• 內(nèi)容管理開關(guān)。內(nèi)容管理開關(guān)的作用是保證所有運營維護的鏈接都可以被替換。
• CDN開關(guān)。每個頁面，從HTTP到HTTPS都需要做301跳轉(zhuǎn)，這些跳轉(zhuǎn)都配置在CDN中。
• 客戶端開關(guān)。就是移動加速SDK的開關(guān)。

上線過程中遇到的新問題

做完開關(guān)控制，在正式上線的過程中，又遇到了一些新問題如：Referrer、DNS劫持、HTTPS性能監(jiān)控等。

Referrer

目前大部分瀏覽器，在發(fā)生協(xié)議降級時默認不發(fā)送Referrer 信息，最典型的場景就是從HTTPS 頁面點鏈接跳到HTTP 網(wǎng)站時，瀏覽器并不會在請求頭中帶上Referer 字段。當(dāng)Referrer帶不過去，對大數(shù)據(jù)的影響非常大，因為沒辦法追溯流量來源。

針對現(xiàn)代的瀏覽器，這個問題可以通過給頁面加上meta 標簽來解決：<meta name="referrer" content="always" />

DNS劫持

DNS劫持是指非法破壞域名的解析過程導(dǎo)致請求被解析到一個錯誤節(jié)點以達到某些惡意目的。當(dāng)我們使用HTTP時，DNS異?？赡苓€不會影響請求的功能性，但HTTPS因為非法節(jié)點沒有證書和私鑰，肯定是無法響應(yīng)了。

蘇寧的做法的是通過一些波測監(jiān)控DNS的正常，如下圖，我們監(jiān)測到蘇寧中華特色館在某個地區(qū)有大量DNS解析異常。

出現(xiàn)DNS劫持，對用戶影響很大，一旦出現(xiàn)一次頁面打不開，用戶就會認為這個頁面有問題，不會在進行二次訪問。

如下圖，是蘇寧易購河北地區(qū)出現(xiàn)的問題：

如圖中所示，頁面整個框架都在，但就是沒有圖片，最終確定是由DNS劫持導(dǎo)致的。

這里的應(yīng)對方法就是要建立完整的風(fēng)控體系，在全國各地建設(shè)波測節(jié)點，做整個請求圖片、頁面的記錄，并保存，如下圖：

當(dāng)時，河北地區(qū)用戶發(fā)出請求后，TCP沒有辦法建立連接，使用SSL無法握手。原因是DNS劫持，被映射到非法的錯誤節(jié)點上了。應(yīng)對方法還是我剛才說的降級手段，通過IP

判斷是河北移動的用戶就對HTTPS進行降級成HTTP，其他地方還繼續(xù)使用HTTPS策略。待當(dāng)?shù)剡\營商解決問題之后，再進行恢復(fù)。

HTTPS性能監(jiān)控

如下圖，是蘇寧易購移動端的監(jiān)控頁面：

HTTPS灰度最重要的一個是做好監(jiān)控，必須要有一個監(jiān)控覆蓋，要做好灰度，每一步上線時都要分析一下業(yè)務(wù)、性能、站內(nèi)站外投放，CPS等數(shù)據(jù)。一切數(shù)據(jù)分析都正常之后，再逐步擴大區(qū)域，按APP的版本和用戶級別進行部署。

HTTPS未來展望篇

這里分享一個基于UDP的低時延的互聯(lián)網(wǎng)傳輸層協(xié)議：QUIC(Quick UDP Internet Connection)。TCP/IP協(xié)議族是互聯(lián)網(wǎng)的基礎(chǔ)。這個UDP協(xié)議由谷歌提出，其用意是替代TCP協(xié)議。這兩種協(xié)議，UDP更為輕量，錯誤校驗也要少得多，但可靠性方面要弱于TCP。目前，針對QUIC協(xié)議，國外一些公司在試用階段，強調(diào)的是既保證安全，又能保證握手不會對原來的傳輸造成影響，這也許是未來的發(fā)展方向。

【作者簡介】

[[203117]]

朱羿全，蘇寧云商IT總部架構(gòu)師，先后參與了全景應(yīng)用性能監(jiān)控平臺搭建、移動端性能優(yōu)化與提升、移動端統(tǒng)一接入層建設(shè)等工作，主導(dǎo)了蘇寧易購全站HTTPS上線和優(yōu)化工作。專注于應(yīng)用層網(wǎng)絡(luò)性能優(yōu)化，在HTTPS、HTTP/2等領(lǐng)域擁有豐富的經(jīng)驗，目標是通過優(yōu)化，以保證復(fù)雜網(wǎng)絡(luò)環(huán)境下，通信的快速、穩(wěn)定和安全。

以上內(nèi)容根據(jù)朱羿全老師在 WOTA2017 “電商大促背后的技術(shù)挑戰(zhàn)”專場的演講內(nèi)容整理。

由于篇幅問題，一些加密套件、SPDY&HTTP/2、HTTP/2 壓測工具、SSL硬件加速卡等合理使用，沒有在文中一一分享，更詳細內(nèi)容請見：視頻 & PPT

本月熱文推薦TOP3

混合云的那些事，如何做到讓公有云和私有云實現(xiàn)1+1>2

AR/VR專家告訴你：人機交互的未來場景長啥樣?

15年資深架構(gòu)師詳解：一個大型互聯(lián)網(wǎng)公司的微服務(wù)轉(zhuǎn)型實踐

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】