大型網(wǎng)站的 HTTPS 實(shí)踐（4）：協(xié)議層以外的實(shí)踐
百度在2015年即完成HTTPS改造，那大型網(wǎng)站的HTTPS改造中都有哪些實(shí)踐經(jīng)驗(yàn)，學(xué)堂君特分析這篇干貨滿滿系列內(nèi)容，轉(zhuǎn)自百度運(yùn)維博客。
1 前言
網(wǎng)上介紹 HTTPS 的文章并不多，更鮮有分享在大型互聯(lián)網(wǎng)站點(diǎn)部署 HTTPS 的實(shí)踐經(jīng)驗(yàn)，我們在考慮部署HTTPS 時(shí)也有重重的疑惑。
本文為大家介紹百度 HTTPS 的實(shí)踐和一些權(quán)衡, 希望以此拋磚引玉。
2 協(xié)議層以外的實(shí)踐工作
2.1 全站覆蓋 https 的理由
很多剛接觸 https 的會(huì)思考，我是不是只要站點(diǎn)的主域名換了HTTPS 就可以？答案是不行。
HTTPS的目的就是保證傳輸過程的安全，如果只有主域名上了 HTTPS ，但是主域名加載的資源，比如 js，css，圖片沒有上 HTTPS ，會(huì)怎么樣？
從效果上來說，沒有達(dá)到保證網(wǎng)站傳輸過程安全的目的，因?yàn)槟愕?js，css，圖片仍然有被劫持的可能性，如果這些內(nèi)容被篡改 / 嗅探了，那么 HTTPS 的意義就失去了。
瀏覽器在設(shè)計(jì)上早就考慮的這樣的情況，會(huì)有相應(yīng)的提示。具體的實(shí)現(xiàn)依賴瀏覽器，例如地址欄鎖形標(biāo)記從綠色變?yōu)辄S色, 阻止這次請求，或者直接彈出非常影響用戶體驗(yàn)的提示 (主要是 IE)，用戶會(huì)感覺厭煩，疑惑和擔(dān)憂安全性。
很多用戶看見這個(gè)鏈接會(huì)習(xí)慣性的點(diǎn)”是”，這樣非 HTTPS 的資源就被禁止加載了。非 ie 的瀏覽器很多也會(huì)阻止加載一些危害程度較高的非 HTTPS 資源（例如 js）。我們發(fā)現(xiàn)移動(dòng)端瀏覽器的限制目前會(huì)略松一些。
所以這里要是沒做好，很多情況連網(wǎng)站的基本功能都沒法正常使用。
2.2 站點(diǎn)的區(qū)別
很多人剛接觸 HTTPS 的時(shí)候，覺得不就是部署證書，讓 webserver 支持HTTPS 就行了嗎。
實(shí)際上對(duì)于不同的站點(diǎn)來說，HTTPS 的部署方式和難度有很大的區(qū)別。對(duì)于一個(gè)大型站點(diǎn)來說，讓 webserver 支持 HTTPS ，以及對(duì) webserver 在 HTTPS 協(xié)議特性上做一些優(yōu)化，在遷移的工作比重上，可能只占到 20%-40%。
我們考慮下以下幾種情況下，部署HTTPS 的方案。
2.2.1 簡單的個(gè)人站點(diǎn)
簡單的定義：資源只從本站的主域或者主域的子域名加載。
比如 axyz 的個(gè)人 blog，域名是 axyzblog.com。加載主域名下的 js 和圖片。
這樣的站部署 https，在已有證書且 webserver 支持的情況下，只需要把主域名替換為 HTTPS 接入，然后把資源連接修改為 https:// 或者 //。
2.2.2 復(fù)雜的個(gè)人站點(diǎn)
復(fù)雜的定義：資源需要從外部域名加載。
這樣就比較麻煩了，主域資源容易適配 HTTPS ，在 cdn 上加載的資源還需要 cdn 服務(wù)商支持 HTTPS 。目前各大 cdn 的服務(wù)商正在逐漸提供HTTPS 的支持，需要遷移的朋友可以看看自己使用的 cdn 是否提供了這項(xiàng)能力。一些 cdn 會(huì)對(duì) HTTPS 流量額外收費(fèi)。
Cdn 使用HTTPS 常見的方案有：
1 網(wǎng)站主提供私鑰給 cdn，回源使用HTTP。
2 cdn 使用公共域名，公共的證書，這樣資源的域名就不能自定義了。回源使用 HTTP。
3 僅提供動(dòng)態(tài)加速，cdn 進(jìn)行 tcp 代理，不緩存內(nèi)容。
4 CloudFlare 提供了Keyless SSL的服務(wù)，能夠支持不愿意提供私鑰, 不想使用公共的域名和證書卻又需要使用 cdn 的站點(diǎn)了。
2.2.3 簡單的大型站點(diǎn)
簡單的定義: 資源只從本站的主域, 主域的子域，或者自建 / 可控的 cdn 域名加載，幾乎沒有第三方資源。如果網(wǎng)站本身的特性就如此，或愿意改造為這樣的類型，部署 https 就相對(duì)容易。Google Twitter 都是非常好的范例。優(yōu)點(diǎn)：已經(jīng)改成這樣的站點(diǎn)，替換 https 就比較容易。缺點(diǎn)：如果需要改造，那么要很大的決心，畢竟幾乎不能使用多樣化的第三方資源了。
2.2.4 復(fù)雜，訪問速度重要性稍低的大型站點(diǎn)
復(fù)雜的定義：從本站的非主域，或者第三方站點(diǎn)的域名有大量的第三方資源需要加載，多出現(xiàn)在一些平臺(tái)類，或者有復(fù)雜內(nèi)容展現(xiàn)的的網(wǎng)站。
訪問速度要求：用戶停留時(shí)間長或者強(qiáng)需求，用戶對(duì)訪問速度的耐受程度較高。比如門戶，視頻，在線交易類（比如火車票 機(jī)票 商城）網(wǎng)站。
這樣的站點(diǎn)，可以努力推動(dòng)所有相關(guān)域名升級(jí)為支持 HTTPS 。我們用下圖舉例說明下這樣修改會(huì)導(dǎo)致一個(gè)網(wǎng)站的鏈接發(fā)生怎樣的改變。
負(fù)責(zé)流量接入的團(tuán)隊(duì)將可控的接入環(huán)境改造為 HTTP 和 HTTPS 都支持，這樣前端工程的工作相對(duì)就少一些。大部分時(shí)候?qū)㈡溄訌?http:// 替換為 // 即可. 在主域名是 HTTPS 的情況下，其它資源就能自動(dòng)從 HTTPS 協(xié)議下加載。一些第三方資源怎么辦？一般來說只有兩種選擇，一遷移到自己的 cdn 或者 idc 吧，二強(qiáng)制要求第三方自己能支持 HTTPS 。
以全站 HTTPS 接入的 facebook 舉例。第三方廠商想在 facebook 上線一個(gè)游戲。facebook：請?zhí)峁〩TTPS 接入吧。第三方想：能賺錢啊，還是提供下 HTTPS 接入吧。所以，足夠強(qiáng)勢，有吸引力，合作方也有提供 HTTPS 的能力的話，這是完全可行的。如果你的平臺(tái)接入的都是一些個(gè)人開發(fā)者，而且還賺不到多少錢的情況下，這樣就行不通了。
優(yōu)點(diǎn)：前端改動(dòng)相對(duì)簡單，不容易出現(xiàn) HTTPS 下還有 http 的資源問題。
缺點(diǎn)：通常這樣的實(shí)現(xiàn)下，用戶的訪問速度會(huì)變慢，比如從 2.5 秒變?yōu)?3 秒，如上述的理由，用戶還是能接受的。對(duì)第三方要求高。
2.2.5 復(fù)雜，訪問速度有嚴(yán)格要求的大型站點(diǎn)
復(fù)雜的定義：同上。
訪問速度要求：停留時(shí)間不長，用戶對(duì)訪問速度的心理預(yù)期較高。
但是如果用戶把網(wǎng)站當(dāng)作工具使用，需要你很快給出響應(yīng)的時(shí)候，這樣的實(shí)現(xiàn)就不好了。后續(xù)幾個(gè)部分我們介紹下這些優(yōu)化的抉擇。
2.3 域名的選擇
域名對(duì)訪問速度的影響具有兩面性：域名多，域名解析和建立連接的時(shí)間就多；域名少，下載并發(fā)度又不夠。
HTTPS 下重建連接的時(shí)間成本比HTTP 更高，對(duì)于上面提到的簡單的大型站點(diǎn), 可以用少量域名就能滿足需求，對(duì)于百度這樣富展現(xiàn)樣式較多的搜索引擎來說，頁面可能展示的資源種類太多。而不同類型的資源又是由不同的域名 (不同的產(chǎn)品 或者第三方產(chǎn)品) 提供的服務(wù)，換一個(gè)詞搜索就可能需要重新建立一些資源的 ssl 鏈接，會(huì)讓用戶感受到卡頓。
如果將域名限制在有限的范圍，維持和這些域名的連接，合并一些數(shù)據(jù)，加上有 spdy，http2.0 來保證并發(fā)，是可以滿足我們的需求的。
2.4 連接復(fù)用
連接復(fù)用率可以分為 tcp 和 ssl 等不同的層面，需要分開進(jìn)行分析和統(tǒng)計(jì)。
2.4.1 連接復(fù)用的意義
HTTP 協(xié)議 (RFC2616) 規(guī)定一個(gè)域名最多不能建立超過 2 個(gè)的 TCP 連接。但是隨著互聯(lián)網(wǎng)的發(fā)展，一張網(wǎng)頁的元素越來越多，傳輸內(nèi)容越來越大，一個(gè)域名 2 個(gè)連接的限制已經(jīng)遠(yuǎn)遠(yuǎn)不能滿足現(xiàn)在網(wǎng)頁加載速度的需求。
目前已經(jīng)沒有瀏覽器遵守這個(gè)規(guī)定，各瀏覽器針對(duì)單域名建立的 TCP 連接數(shù)如下：
表格 1 瀏覽器單域名建立的最大并發(fā)連接數(shù)
從上表看出，單個(gè)域名的連接數(shù)基本上是 6 個(gè)。所以只能通過增加域名的方式來增加并發(fā)連接數(shù)。在 HTTP 場景下，這樣的方式?jīng)]有什么問題。但是在 HTTPS 連接下，由于 TLS 連接建立的成本比較高，增加并發(fā)連接數(shù)本身就會(huì)帶來較大的延遲，所以對(duì)域名數(shù)需要一個(gè)謹(jǐn)慎的控制。
特別是 HTTP2 即將大規(guī)模應(yīng)用，而 HTTP2 的最大特性就是多路復(fù)用，使用多個(gè)域名和多個(gè)連接無法有效發(fā)揮多路復(fù)用和壓縮的特性。
那 HTTPS 協(xié)議下，一張網(wǎng)頁到底該有多少域名呢？這個(gè)其實(shí)沒有定論，取決于網(wǎng)頁需要加載元素個(gè)數(shù)。
2.4.2 預(yù)建連接
既然從協(xié)議角度無法減少握手對(duì)速度的影響，那能不能提前建立連接，減少用戶可以感知的握手延遲呢？當(dāng)然是可以的。思路就是預(yù)判當(dāng)前用戶的下一個(gè)訪問 URL，提前建立連接，當(dāng)用戶發(fā)起真實(shí)請求時(shí)，TCP 及 TLS 握手都已經(jīng)完成，只需要在連接上發(fā)送應(yīng)用層數(shù)據(jù)即可。
最簡單有效的方式就是在主域下對(duì)連接進(jìn)行預(yù)建，可以通過請求一些靜態(tài)資源的方式。但是這樣還是不容易做到極致，因?yàn)槭褂媚膫€(gè)連接，并發(fā)多少還是瀏覽器控制的。例如你對(duì) a 域名請求一個(gè)圖片，瀏覽器建立了兩個(gè)連接，再請求一張圖片的時(shí)候，瀏覽器很大概率能夠復(fù)用連接，但是當(dāng) a 域名需要加載 10 個(gè)圖片的時(shí)候，瀏覽器很可能就會(huì)新建連接了。
2.4.3 Spdy 的影響
Spdy 對(duì)于連接復(fù)用率的提升非常有效，因?yàn)樗苤С诌B接上的并發(fā)請求，所以瀏覽器會(huì)盡量在這個(gè)鏈接上保持復(fù)用。
2.4.4 其它
也可以嘗試一些其他發(fā)方法，讓瀏覽器在訪問你的網(wǎng)站之前就建立過 HTTP2 連接，這樣 session 能夠復(fù)用。HSTS 也能有效的減少跳轉(zhuǎn)時(shí)間，可惜對(duì)于復(fù)雜的網(wǎng)站來說，開啟需要考慮清楚很多問題。
2.5 優(yōu)化的效果
從百度的優(yōu)化經(jīng)驗(yàn)來看看，如果不開啟 HSTS，用戶在瀏覽器直接訪問主域名，再通過 302 跳轉(zhuǎn)到 HTTPS。增加的時(shí)間平均會(huì)有 400ms+，其中 302 跳轉(zhuǎn)和 ssl 握手的因素各占一半。但是對(duì)于后續(xù)的請求，我們做到了對(duì)絕大部分用戶幾乎無感知。
這 400ms+ 還有很多可以優(yōu)化的空間，我們會(huì)持續(xù)優(yōu)化用戶的體驗(yàn)。
3 HTTPS 遷移遇到的一些常見問題
3.1 傳遞 Referrer
我們可以把自己的網(wǎng)站替換為 HTTPS，但是一般的站點(diǎn)都有外鏈，要讓外鏈都 HTTPS 目前還不太現(xiàn)實(shí)。很多網(wǎng)站需要從 referrer 中判斷流量來源，因此對(duì)于搜索引擎這樣的網(wǎng)站來說，referer 的傳遞還是比較重要的。如果不做任何設(shè)置，你會(huì)發(fā)現(xiàn)在HTTPS站點(diǎn)中點(diǎn)擊外鏈并沒有將 referrer 帶入到HTTP請求的頭部中（http://tools.ietf.org/html/rfc7231#section-5.5.2）?，F(xiàn)代的瀏覽器可以用 meta 標(biāo)簽來傳遞 refer。(http://w3c.github.io/webappsec/specs/referrer-policy)
<meta name=”referrer” content=”always”> 傳遞完整的 url
<meta name=”referrer” content=”origin”> 只傳遞站點(diǎn)，不包含路徑和參數(shù)等。
對(duì)于不支持 meta 傳遞 referrer 的瀏覽器，例如 IE8, 我們怎么辦呢？
可以采用再次跳轉(zhuǎn)的方法，既然 HTTPS 下不能給 HTTP 傳遞 referer，我們可以先從 HTTPS 訪問一個(gè)可控的 HTTP 站點(diǎn)，把需要傳遞的內(nèi)容放到這個(gè) HTTP 站點(diǎn)的 url 中，然后再跳轉(zhuǎn)到目標(biāo)地址。
3.2 form 提交
有時(shí)需要將 form 提交到第三方站點(diǎn)，而第三方站點(diǎn)又是 HTTP 的地址，瀏覽器會(huì)有不安全的警告。可以和 referrer 的跳轉(zhuǎn)傳遞采取相似的邏輯。
但是這樣對(duì) referer 和 form 等內(nèi)容的方案，并不是完美的解決方法，因?yàn)檫@樣還是增加了不安全的因素（劫持，隱私泄露等 ）。理想情況需要用戶升級(jí)符合最新規(guī)范的瀏覽器，以及推進(jìn)更多的站點(diǎn)遷移至 HTTPS。
3.3 視頻播放
簡單來說，如果你使用 http 的協(xié)議來播放視頻，那么瀏覽器仍然會(huì)有不安全的提示。所以你有兩種選擇，1 讓視頻源提供 HTTPS。2 使用非 HTTP 的協(xié)議，如 rtmp 協(xié)議。
3.4 用戶異常
在 HTTP 遷移的過程中，也會(huì)有不少熱心的用戶向我們反饋遇到的各種問題。
常見的有以下的一些情況：
1 用戶的系統(tǒng)時(shí)間設(shè)置錯(cuò)誤，導(dǎo)致提示證書過期。
2 用戶使用 fiddler 等代理進(jìn)行調(diào)試，但是沒有添加這些軟件的根證書，導(dǎo)致提示證書非法。
3 用戶使用的 Dns 為公共 dns 或者跨網(wǎng)設(shè)置 dns，一些請求被運(yùn)營商作為跨網(wǎng)流量攔截。
4 連通性有問題，我們發(fā)現(xiàn)一個(gè)小運(yùn)營商的 https 失敗率奇高，又沒法聯(lián)系到他們，只能不對(duì)他們進(jìn)行 HTTPS 的轉(zhuǎn)換。
5 慢。有時(shí)由于網(wǎng)絡(luò)環(huán)境的因素，用戶打開其他網(wǎng)站也慢，ping 哪個(gè)網(wǎng)站都要 500-2000ms。這時(shí) https 自然也會(huì)很慢。
4 結(jié)束語
對(duì)于復(fù)雜的大型網(wǎng)站來說，HTTPS 的部署有很多工作要完成。
面對(duì)困難和挑戰(zhàn)，有充足的動(dòng)力支持著我們前進(jìn)：https 上線后，劫持等原因?qū)е碌挠脩艄δ墚惓＃[私泄露的反饋大幅減少。
熱心的用戶經(jīng)常會(huì)向我們反饋遇到的各種問題。在以前，有時(shí)即使我們確定了是劫持的問題，能夠解決問題的方法也非常有限。每當(dāng)這種時(shí)候，自己總會(huì)產(chǎn)生一些無力感。
HTTPS 的全站部署，給我們提供了能解決大部分問題的選項(xiàng)。能讓一個(gè)做技術(shù)的人看到自己的努力解決了用戶的問題，這就是最棒的收獲。
HTTPS 沒有想像中難用和可怕，只是沒有經(jīng)過優(yōu)化。與大家共勉。
來源：百度搜索資源平臺(tái) 百度搜索學(xué)堂
