HTTPS如何進行協(xié)議層以外的實踐

HTTPS如何進行協(xié)議層以外的實踐，針對這個問題，這篇文章詳細介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

 協(xié)議層以外的實踐

前言

網(wǎng)上介紹 https 的文章并不多，更鮮有分享在大型互聯(lián)網(wǎng)站點部署 https 的實踐經(jīng)驗，我們在考慮部署 https 時也有重重的疑惑。
本文為大家介紹百度 HTTPS 的實踐和一些權(quán)衡 , 希望以此拋磚引玉。

協(xié)議層以外的實踐工作

全站覆蓋 https 的理由

很多剛接觸 https 的會思考，我是不是只要站點的主域名換了 https 就可以？答案是不行。
https 的目的就是保證傳輸過程的安全，如果只有主域名上了 https，但是主域名加載的資源，比如 js，css，圖片沒有上 https，會怎么樣？
從效果上來說，沒有達到保證網(wǎng)站傳輸過程安全的目的，因為你的 js，css，圖片仍然有被劫持的可能性，如果這些內(nèi)容被篡改 / 嗅探了，那么 https 的意義就失去了。
瀏覽器在設(shè)計上早就考慮的這樣的情況，會有相應(yīng)的提示。具體的實現(xiàn)依賴瀏覽器，例如地址欄鎖形標記從綠色變?yōu)辄S色 , 阻止這次請求，或者直接彈出非常影響用戶體驗的提示 (主要是 IE)，用戶會感覺厭煩，疑惑和擔憂安全性。

很多用戶看見這個鏈接會習(xí)慣性的點” 是”，這樣非 https 的資源就被禁止加載了。非 ie 的瀏覽器很多也會阻止加載一些危害程度較高的非 https 資源（例如 js）。我們發(fā)現(xiàn)移動端瀏覽器的限制目前會略松一些。
所以這里要是沒做好，很多情況連網(wǎng)站的基本功能都沒法正常使用。

站點的區(qū)別

很多人剛接觸 https 的時候，覺得不就是部署證書，讓 webserver 支持 https 就行了嗎。
實際上對于不同的站點來說，https 的部署方式和難度有很大的區(qū)別。對于一個大型站點來說，讓 webserver 支持 https，以及對 webserver 在 https 協(xié)議特性上做一些優(yōu)化，在遷移的工作比重上，可能只占到 20%-40%。
我們考慮下以下幾種情況下，部署 https 的方案。

簡單的個人站點

簡單的定義：資源只從本站的主域或者主域的子域名加載。
比如 axyz 的個人 blog，域名是 axyzblog.com。加載主域名下的 js 和圖片。

這樣的站部署 https，在已有證書且 webserver 支持的情況下，只需要把主域名替換為 https 接入，然后把資源連接修改為 https:// 或者 //。

復(fù)雜的個人站點

復(fù)雜的定義：資源需要從外部域名加載。

這樣就比較麻煩了，主域資源容易適配 https，在 cdn 上加載的資源還需要 cdn 服務(wù)商支持 https。目前各大 cdn 的服務(wù)商正在逐漸提供 https 的支持，需要遷移的朋友可以看看自己使用的 cdn 是否提供了這項能力。一些 cdn 會對 https 流量額外收費。

Cdn 使用 https 常見的方案有：

1. 網(wǎng)站主提供私鑰給 cdn，回源使用 http。

2. cdn 使用公共域名，公共的證書，這樣資源的域名就不能自定義了?；卦词褂?http。

3. 僅提供動態(tài)加速，cdn 進行 tcp 代理，不緩存內(nèi)容。

4. CloudFlare 提供了 Keyless SSL 的服務(wù)，能夠支持不愿意提供私鑰 , 不想使用公共的域名和證書卻又需要使用 cdn 的站點了。

簡單的大型站點

簡單的定義: 資源只從本站的主域 , 主域的子域，或者自建 / 可控的 cdn 域名加載，幾乎沒有第三方資源。如果網(wǎng)站本身的特性就如此，或愿意改造為這樣的類型，部署 https 就相對容易。Google Twitter 都是非常好的范例。優(yōu)點：已經(jīng)改成這樣的站點，替換 https 就比較容易。缺點：如果需要改造，那么要很大的決心，畢竟幾乎不能使用多樣化的第三方資源了。

復(fù)雜，訪問速度重要性稍低的大型站點

復(fù)雜的定義：從本站的非主域，或者第三方站點的域名有大量的第三方資源需要加載，多出現(xiàn)在一些平臺類，或者有復(fù)雜內(nèi)容展現(xiàn)的的網(wǎng)站。
訪問速度要求：用戶停留時間長或者強需求，用戶對訪問速度的耐受程度較高。比如門戶，視頻，在線交易類（比如火車票 機票 商城）網(wǎng)站。
這樣的站點，可以努力推動所有相關(guān)域名升級為支持 https。我們用下圖舉例說明下這樣修改會導(dǎo)致一個網(wǎng)站的鏈接發(fā)生怎樣的改變。

負責(zé)流量接入的團隊將可控的接入環(huán)境改造為 http 和 https 都支持，這樣前端工程的工作相對就少一些。大部分時候?qū)㈡溄訌?http:// 替換為 // 即可 . 在主域名是 https 的情況下，其它資源就能自動從 https 協(xié)議下加載。一些第三方資源怎么辦？一般來說只有兩種選擇，一遷移到自己的 cdn 或者 idc 吧，二強制要求第三方自己能支持 https。
以全站 https 接入的 facebook 舉例。第三方廠商想在 facebook 上線一個游戲。facebook：請?zhí)峁?https 接入吧。第三方想：能賺錢啊，還是提供下 https 接入吧。所以，足夠強勢，有吸引力，合作方也有提供 https 的能力的話，這是完全可行的。如果你的平臺接入的都是一些個人開發(fā)者，而且還賺不到多少錢的情況下，這樣就行不通了。

• 優(yōu)點：前端改動相對簡單，不容易出現(xiàn) https 下還有 http 的資源問題。

• 缺點：通常這樣的實現(xiàn)下，用戶的訪問速度會變慢，比如從5 秒變?yōu)?3 秒，如上述的理由，用戶還是能接受的。對第三方要求高。

復(fù)雜，訪問速度有嚴格要求的大型站點

• 復(fù)雜的定義：同上。

• 訪問速度要求：停留時間不長，用戶對訪問速度的心理預(yù)期較高。 但是如果用戶把網(wǎng)站當作工具使用，需要你很快給出響應(yīng)的時候，這樣的實現(xiàn)就不好了。后續(xù)幾個部分我們介紹下這些優(yōu)化的抉擇。

域名的選擇

域名對訪問速度的影響具有兩面性：域名多，域名解析和建立連接的時間就多；域名少，下載并發(fā)度又不夠。
https 下重建連接的時間成本比 http 更高，對于上面提到的簡單的大型站點 , 可以只用 1-3 個域名就能滿足需求，對于百度這樣富展現(xiàn)樣式較多的搜索引擎來說，頁面可能展示的資源種類太多。而不同類型的資源又是由不同的域名 (不同的產(chǎn)品 或者第三方產(chǎn)品) 提供的服務(wù)，換一個詞搜索就可能需要重新建立一些資源的 ssl 鏈接，會讓用戶感受到卡頓。

如果將域名限制在有限的范圍 (一般 2-6 個左右)，維持和這些域名的連接，合并一些數(shù)據(jù)，加上有 spdy，http2.0 來保證并發(fā)，是可以滿足我們的需求的。我們的現(xiàn)狀是：百度搜索有數(shù)百個資源域名在加載各類的資源。這就變成了如何解決這樣的問題：如何用 2-6 個有限的域名提供數(shù)百個域名的服務(wù)，這就涉及了下一節(jié)，代理接入與 cdn。

代理接入

當域名從數(shù)百域名縮減到個位數(shù)的時候，就不可避免的需要談到統(tǒng)一接入，流量轉(zhuǎn)發(fā)和調(diào)度等內(nèi)容。通常的站點資源大都是從主域名 +cdn 進行加載，所以我們可以把域名分為這兩類，進行替換。

替換后的幾個 cdn 域名都指向相同的 cname，這樣的話意味著用戶訪問的途徑變?yōu)槿缦碌姆绞健?/p>

這樣 ssl 的握手只在用戶和兩類節(jié)點之間進行，維持連接相對容易很多，也不需要每個域名都去申請證書，部署 https 接入。
這個方式會遇到域名轉(zhuǎn)換，數(shù)據(jù)透傳，流量調(diào)度等一系列的問題，需要進行整體設(shè)計架構(gòu)，對很多細節(jié)都需要進行優(yōu)化，在運維和研發(fā)上都有不小的投入。
理想的方式：這樣就只需要和 cdn 節(jié)點進行 https 握手，大幅縮短了握手的 rtt 時間 (cdn 節(jié)點一般廣泛的分布在離用戶很近的地方，而主域節(jié)點一般都比較有限). 這樣部署會對 cdn 的運維和研發(fā)能力有更高的要求。

大家有沒發(fā)現(xiàn)，這樣的接入就把一個復(fù)雜的站點變?yōu)楹唵蔚恼军c了？

連接復(fù)用

連接復(fù)用率可以分為 tcp 和 ssl 等不同的層面，需要分開進行分析和統(tǒng)計。

連接復(fù)用的意義

HTTP 協(xié)議 (RFC2616) 規(guī)定一個域名最多不能建立超過 2 個的 TCP 連接。但是隨著互聯(lián)網(wǎng)的發(fā)展，一張網(wǎng)頁的元素越來越多，傳輸內(nèi)容越來越大，一個域名 2 個連接的限制已經(jīng)遠遠不能滿足現(xiàn)在網(wǎng)頁加載速度的需求。
目前已經(jīng)沒有瀏覽器遵守這個規(guī)定，各瀏覽器針對單域名建立的 TCP 連接數(shù)如下：

表格 1 瀏覽器單域名建立的最大并發(fā)連接數(shù)

從上表看出，單個域名的連接數(shù)基本上是 6 個。所以只能通過增加域名的方式來增加并發(fā)連接數(shù)。在 HTTP 場景下，這樣的方式?jīng)]有什么問題。但是在 HTTPS 連接下，由于 TLS 連接建立的成本比較高，增加并發(fā)連接數(shù)本身就會帶來較大的延遲，所以對域名數(shù)需要一個謹慎的控制。
特別是 HTTP2 即將大規(guī)模應(yīng)用，而 HTTP2 的最大特性就是多路復(fù)用，使用多個域名和多個連接無法有效發(fā)揮多路復(fù)用和壓縮的特性。

那 HTTPS 協(xié)議下，一張網(wǎng)頁到底該有多少域名呢？這個其實沒有定論，取決于網(wǎng)頁需要加載元素個數(shù)。

預(yù)建連接

既然從協(xié)議角度無法減少握手對速度的影響，那能不能提前建立連接，減少用戶可以感知的握手延遲呢？當然是可以的。思路就是預(yù)判當前用戶的下一個訪問 URL，提前建立連接，當用戶發(fā)起真實請求時，TCP 及 TLS 握手都已經(jīng)完成，只需要在連接上發(fā)送應(yīng)用層數(shù)據(jù)即可。

最簡單有效的方式就是在主域下對連接進行預(yù)建，可以通過請求一些靜態(tài)資源的方式。但是這樣還是不容易做到極致，因為使用哪個連接，并發(fā)多少還是瀏覽器控制的。例如你對 a 域名請求一個圖片，瀏覽器建立了兩個連接，再請求一張圖片的時候，瀏覽器很大概率能夠復(fù)用連接，但是當 a 域名需要加載 10 個圖片的時候，瀏覽器很可能就會新建連接了。

Spdy 的影響

Spdy 對于連接復(fù)用率的提升非常有效，因為它能支持連接上的并發(fā)請求，所以瀏覽器會盡量在這個鏈接上保持復(fù)用。

其它

也可以嘗試一些其他發(fā)方法，讓瀏覽器在訪問你的網(wǎng)站之前就建立過 https 連接，這樣 session 能夠復(fù)用。HSTS 也能有效的減少跳轉(zhuǎn)時間，可惜對于復(fù)雜的網(wǎng)站來說，開啟需要考慮清楚很多問題。

優(yōu)化的效果

從百度的優(yōu)化經(jīng)驗來看看，如果不開啟 HSTS，用戶在瀏覽器直接訪問主域名，再通過 302 跳轉(zhuǎn)到 HTTPS。增加的時間平均會有 400ms+，其中 302 跳轉(zhuǎn)和 ssl 握手的因素各占一半。但是對于后續(xù)的請求，我們做到了對絕大部分用戶幾乎無感知。
這 400ms+ 還有很多可以優(yōu)化的空間，我們會持續(xù)優(yōu)化用戶的體驗。

HTTPS 遷移遇到的一些常見問題。

傳遞 Referrer

我們可以把自己的網(wǎng)站替換為 https，但是一般的站點都有外鏈，要讓外鏈都 https 目前還不太現(xiàn)實。很多網(wǎng)站需要從 referrer 中判斷流量來源，因此對于搜索引擎這樣的網(wǎng)站來說，referer 的傳遞還是比較重要的。如果不做任何設(shè)置，你會發(fā)現(xiàn)在 https 站點中點擊外鏈并沒有將 referrer 帶入到 http 請求的頭部中（http://tools.ietf.org/html/rfc7231#section-5.5.2）?，F(xiàn)代的瀏覽器可以用 meta 標簽來傳遞 refer。(http://w3c.github.io/webappsec/specs/referrer-policy)
<meta name="referrer"><meta name="referrer" content="origin">只傳遞站點，不包含路徑和參數(shù)等。

對于不支持 meta 傳遞 referrer 的瀏覽器，例如 IE8, 我們怎么辦呢？
可以采用再次跳轉(zhuǎn)的方法，既然 HTTPS 下不能給 HTTP 傳遞 referer，我們可以先從 HTTPS 訪問一個可控的 http 站點，把需要傳遞的內(nèi)容放到這個 http 站點的 url 中，然后再跳轉(zhuǎn)到目標地址。

form 提交

有時需要將 form 提交到第三方站點，而第三方站點又是 http 的地址，瀏覽器會有不安全的警告?？梢院?referrer 的跳轉(zhuǎn)傳遞采取相似的邏輯。
但是這樣對 referer 和 form 等內(nèi)容的方案，并不是完美的解決方法，因為這樣還是增加了不安全的因素（劫持，隱私泄露等 ）。理想情況需要用戶升級符合最新規(guī)范的瀏覽器，以及推進更多的站點遷移至 https。

視頻播放

簡單來說，如果你使用 http 的協(xié)議來播放視頻，那么瀏覽器仍然會有不安全的提示。所以你有兩種選擇，1 讓視頻源提供 https。2 使用非 http 的協(xié)議，如 rtmp 協(xié)議。

用戶異常

在 https 遷移的過程中，也會有不少熱心的用戶向我們反饋遇到的各種問題。 常見的有以下的一些情況：

1. 用戶的系統(tǒng)時間設(shè)置錯誤，導(dǎo)致提示證書過期。

2. 用戶使用 fiddler 等代理進行調(diào)試，但是沒有添加這些軟件的根證書，導(dǎo)致提示證書非法。

3. 用戶使用的 Dns 為公共 dns 或者跨網(wǎng)設(shè)置 dns，一些請求被運營商作為跨網(wǎng)流量攔截。

4. 連通性有問題，我們發(fā)現(xiàn)一個小運營商的 https 失敗率奇高，又沒法聯(lián)系到他們，只能不對他們進行 https 的轉(zhuǎn)換。

5. 慢。有時由于網(wǎng)絡(luò)環(huán)境的因素，用戶打開其他網(wǎng)站也慢，ping 哪個網(wǎng)站都要 500-2000ms。這時 https 自然也會很慢。

對于復(fù)雜的大型網(wǎng)站來說，HTTPS 的部署有很多工作要完成。

面對困難和挑戰(zhàn)，有充足的動力支持著我們前進：https 上線后，劫持等原因?qū)е碌挠脩艄δ墚惓?，隱私泄露的反饋大幅減少。
熱心的用戶經(jīng)常會向我們反饋遇到的各種問題。在以前，有時即使我們確定了是劫持的問題，能夠解決問題的方法也非常有限。每當這種時候，自己總會產(chǎn)生一些無力感。
HTTPS 的全站部署，給我們提供了能解決大部分問題的選項。能讓一個做技術(shù)的人看到自己的努力解決了用戶的問題，這就是最棒的收獲。

HTTPS 沒有想像中難用和可怕，只是沒有經(jīng)過優(yōu)化。與大家共勉。

關(guān)于HTTPS如何進行協(xié)議層以外的實踐問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識。