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

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

• 發(fā)送 Syn 包到 Web 客戶端，收到并確認(rèn)后，同時(shí)發(fā)送 SynAck 到服務(wù)器，這時(shí)還是一個(gè) HTTP 的請求。

• HTTP 轉(zhuǎn)換 HTTPS，需要做一次 302 或者 301 跳轉(zhuǎn)。

• 用戶再次發(fā)送 HTTPS 請求，做一次 TCP 握手。

• 做 TLS 完全握手第一階段，Clienthello 到 Server hello。

• 當(dāng)證書首次到客戶端，客戶端需要走驗(yàn)證流程，做 CA 域名解析。

• 第二次，TLS 握手。

• 在線證書合法性校驗(yàn)的過程。

• TLS 完全握手第二階段，底部灰色部分才是真正的數(shù)據(jù)通訊。

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

01、網(wǎng)頁制作技巧之HSTS 的合理使用

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

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

缺點(diǎn)是 HSTS 在 max-age 過期時(shí)間內(nèi)，在客戶端是強(qiáng)制 HTTPS 的，服務(wù)端無法控制。

因此，當(dāng)需要降級時(shí)，HTTPS 無法及時(shí)切換到 HTTP。當(dāng)然你也可以通過手動(dòng)動(dòng)態(tài)去配置 max-age 的值，這樣可以通過將 max-age 設(shè)置為 0 來達(dá)到降級效果。

還有 HSTS 是嚴(yán)格的 HTTPS，一旦網(wǎng)絡(luò)證書錯(cuò)誤時(shí)，網(wǎng)頁將直接無法訪問（用戶無法選擇忽視）。

02、網(wǎng)頁設(shè)計(jì)注意Session resume 的合理使用

當(dāng)用戶端和客戶端、客戶端和服務(wù)端完成第一次 TLS 握手之后，第二次數(shù)據(jù)傳輸還需要 TLS 握手嗎？

這里可以采用 Session 復(fù)用的方式。Session resume（會(huì)話復(fù)用），是 RFC 標(biāo)準(zhǔn)中早就定好的一個(gè)機(jī)制，HTTPS 最初發(fā)布時(shí)就已經(jīng)涉及其中。

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

• Session ID。使用 clienthello 中的 session ID 查詢服務(wù)端的 session cache，如果服務(wù)端有對應(yīng)的緩存，則直接使用已有的 session 信息提前完成握手，稱為簡化握手。

  Session ID 是 TLS 協(xié)議的標(biāo)準(zhǔn)字段，市面上的瀏覽器全部都支持 Session ID。需要注意的是，單機(jī)多進(jìn)程間共享 ssl session 對集群環(huán)境是沒有意義的。

  因此，在這里需要實(shí)現(xiàn)多機(jī)共享 Session ID?？梢苑旁?redis 中，nginx 提供了專門處理 Session ID 的模塊 ssl_session_fetch_by_lua_block。

• Session tickets。Session tickets 是會(huì)話 ID 的一種補(bǔ)充，server 將session 信息加密成 ticket 發(fā)送給瀏覽器，瀏覽器在后續(xù)握手請求時(shí)會(huì)發(fā)送 ticket，server 端如果能成功解密和處理 ticket，就能完成簡化握手。

  顯然，session ticket 的優(yōu)點(diǎn)是不需要服務(wù)端消耗大量資源來存儲 session 內(nèi)容。但是 session ticket 只是 TLS 協(xié)議的一個(gè)擴(kuò)展特性，目前的支持率不是很廣泛，只有 60% 左右。

  還需要維護(hù)一個(gè)全局的 KEY 來加解密，需要考慮 KEY 的安全性和部署效率。

03、網(wǎng)站制作注意Ocsp stapling 的合理使用

Ocsp 全稱在線證書狀態(tài)檢查協(xié)議 (rfc6960)，用來向 CA 站點(diǎn)查詢證書狀態(tài)，比如證書是否被撤銷，是否已經(jīng)過期等。

通常情況下，瀏覽器使用 OCSP 協(xié)議發(fā)起查詢請求，CA 返回證書狀態(tài)內(nèi)容，然后瀏覽器接受證書是否可信的狀態(tài)。

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

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

ocsp stapling 就能實(shí)現(xiàn)這個(gè)功能。ocspstapling 的原理簡單來說是服務(wù)端代替客戶端完成 CA 校驗(yàn)證書的過程，節(jié)省用戶端的時(shí)間開銷。

就是當(dāng)瀏覽器發(fā)起 clienthello 時(shí)會(huì)攜帶一個(gè) certificate status request 的擴(kuò)展，服務(wù)端看到這個(gè)擴(kuò)展后將 OCSP 內(nèi)容直接返回給瀏覽器，完成證書狀態(tài)檢查。

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

網(wǎng)站建設(shè)技巧之HTTPS 方案之灰度上線篇

灰度上線可遵循灰度、降級和開閉三大原則?；叶仍瓌t是指整個(gè)上線過程要按區(qū)域、版本、用戶等級來進(jìn)行灰度，通過灰度收集上來的用戶數(shù)據(jù)來決定整個(gè)計(jì)劃的進(jìn)行。

降級原則保證每一步的操作都是可逆可回滾的，即對擴(kuò)展開放，對修改關(guān)閉，這是可復(fù)用設(shè)計(jì)的基石。

01、網(wǎng)站制作技巧之HTTPS 開關(guān)控制

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

• 內(nèi)容管理開關(guān)。內(nèi)容管理開關(guān)的作用是保證所有運(yùn)營維護(hù)的鏈接都可以被替換。

• CDN 開關(guān)。每個(gè)頁面，從 HTTP 到 HTTPS 都需要做 301 跳轉(zhuǎn)，這些跳轉(zhuǎn)都配置在 CDN 中。

• 客戶端開關(guān)。就是移動(dòng)加速 SDK 的開關(guān)。

02、網(wǎng)頁設(shè)計(jì)之上線過程中遇到的新問題如何解決

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

Referrer

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

針對現(xiàn)代的瀏覽器，這個(gè)問題可以通過給頁面加上下面這個(gè) meta 標(biāo)簽來解決：

<meta name="referrer" content="always" />

DNS 劫持

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

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

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

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

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

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

當(dāng)時(shí)，河北地區(qū)用戶發(fā)出請求后，TCP 沒有辦法建立連接，使用 SSL 無法握手。原因是 DNS 劫持，被映射到非法的錯(cuò)誤節(jié)點(diǎn)上了。

應(yīng)對方法還是我剛才說的降級手段，通過 IP 判斷是河北移動(dòng)的用戶就對 HTTPS 進(jìn)行降級成 HTTP，其他地方還繼續(xù)使用 HTTPS 策略。待當(dāng)?shù)剡\(yùn)營商解決問題之后，再進(jìn)行恢復(fù)。

網(wǎng)頁設(shè)計(jì)方法HTTPS 性能監(jiān)控

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

HTTPS 灰度最重要的一個(gè)是做好監(jiān)控，必須要有一個(gè)監(jiān)控覆蓋，要做好灰度，每一步上線時(shí)都要分析一下業(yè)務(wù)、性能、站內(nèi)站外投放，CPS 等數(shù)據(jù)。

一切數(shù)據(jù)分析都正常之后，再逐步擴(kuò)大區(qū)域，按 APP 的版本和用戶級別進(jìn)行部署。

網(wǎng)頁制作技巧HTTPS 未來展望篇

這里分享一個(gè)基于 UDP 的低時(shí)延的互聯(lián)網(wǎng)傳輸層協(xié)議：QUIC（Quick UDP Internet Connection）。

TCP/IP 協(xié)議族是互聯(lián)網(wǎng)的基礎(chǔ)，這個(gè) UDP 協(xié)議由谷歌提出，其用意是替代 TCP 協(xié)議。

這兩種協(xié)議，UDP 更為輕量，錯(cuò)誤校驗(yàn)也要少得多，但可靠性方面要弱于 TCP。目前，針對 QUIC 協(xié)議，國外一些公司在試用階段，強(qiáng)調(diào)的是既保證安全，又能保證握手不會(huì)對原來的傳輸造成影響，這也許是未來的發(fā)展方向。深圳網(wǎng)站建設(shè)博納網(wǎng)絡(luò)編輯整理。