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 的會思考，我是不是只要站點(diǎn)的主域名換了 https 就可以？答案是不行。

https 的目的就是保證傳輸過程的安全，如果只有主域名上了 https，但是主域名加載的資源，比如 js，css，圖片沒有上 https，會怎么樣？

從效果上來說，沒有達(dá)到保證網(wǎng)站傳輸過程安全的目的，因?yàn)槟愕?js，css，圖片仍然有被劫持的可能性，如果這些內(nèi)容被篡改 / 嗅探了，那么 https 的意義就失去了。

瀏覽器在設(shè)計(jì)上早就考慮的這樣的情況，會有相應(yīng)的提示。具體的實(shí)現(xiàn)依賴瀏覽器，例如地址欄鎖形標(biāo)記從綠色變?yōu)辄S色, 阻止這次請求，或者直接彈出非常影響用戶體驗(yàn)的提示 (主要是 IE)，用戶會感覺厭煩，疑惑和擔(dān)憂安全性。

很多用戶看見這個(gè)鏈接會習(xí)慣性的點(diǎn)”是”，這樣非 https 的資源就被禁止加載了。非 ie 的瀏覽器很多也會阻止加載一些危害程度較高的非 https 資源（例如 js）。我們發(fā)現(xiàn)移動端瀏覽器的限制目前會略松一些。

所以這里要是沒做好，很多情況連網(wǎng)站的基本功能都沒法正常使用。

2.2 站點(diǎn)的區(qū)別

很多人剛接觸 https 的時(shí)候，覺得不就是部署證書，讓 webserver 支持 https 就行了嗎。

實(shí)際上對于不同的站點(diǎn)來說，https 的部署方式和難度有很大的區(qū)別。對于一個(gè)大型站點(diǎn)來說，讓 webserver 支持 https，以及對 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 會對 https 流量額外收費(fèi)。

Cdn 使用 https 常見的方案有：

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

2 cdn 使用公共域名，公共的證書，這樣資源的域名就不能自定義了。回源使用 http。

3 僅提供動態(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 就相對容易。Google Twitter 都是非常好的范例。優(yōu)點(diǎn)：已經(jīng)改成這樣的站點(diǎn)，替換 https 就比較容易。缺點(diǎn)：如果需要改造，那么要很大的決心，畢竟幾乎不能使用多樣化的第三方資源了。

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

復(fù)雜的定義：從本站的非主域，或者第三方站點(diǎn)的域名有大量的第三方資源需要加載，多出現(xiàn)在一些平臺類，或者有復(fù)雜內(nèi)容展現(xiàn)的的網(wǎng)站。

訪問速度要求：用戶停留時(shí)間長或者強(qiáng)需求，用戶對訪問速度的耐受程度較高。比如門戶，視頻，在線交易類（比如火車票 機(jī)票 商城）網(wǎng)站。

這樣的站點(diǎn)，可以努力推動所有相關(guān)域名升級為支持 https。我們用下圖舉例說明下這樣修改會導(dǎo)致一個(gè)網(wǎng)站的鏈接發(fā)生怎樣的改變。

負(fù)責(zé)流量接入的團(tuán)隊(duì)將可控的接入環(huán)境改造為 http 和 https 都支持，這樣前端工程的工作相對就少一些。大部分時(shí)候?qū)㈡溄訌?http:// 替換為 // 即可. 在主域名是 https 的情況下，其它資源就能自動從 https 協(xié)議下加載。一些第三方資源怎么辦？一般來說只有兩種選擇，一遷移到自己的 cdn 或者 idc 吧，二強(qiáng)制要求第三方自己能支持 https。

以全站 https 接入的 facebook 舉例。第三方廠商想在 facebook 上線一個(gè)游戲。facebook：請?zhí)峁?https 接入吧。第三方想：能賺錢啊，還是提供下 https 接入吧。所以，足夠強(qiáng)勢，有吸引力，合作方也有提供 https 的能力的話，這是完全可行的。如果你的平臺接入的都是一些個(gè)人開發(fā)者，而且還賺不到多少錢的情況下，這樣就行不通了。

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

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

2.2.5 復(fù)雜，訪問速度有嚴(yán)格要求的大型站點(diǎn)

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

訪問速度要求：停留時(shí)間不長，用戶對訪問速度的心理預(yù)期較高。

但是如果用戶把網(wǎng)站當(dāng)作工具使用，需要你很快給出響應(yīng)的時(shí)候，這樣的實(shí)現(xiàn)就不好了。后續(xù)幾個(gè)部分我們介紹下這些優(yōu)化的抉擇。

2.3 域名的選擇

域名對訪問速度的影響具有兩面性：域名多，域名解析和建立連接的時(shí)間就多；域名少，下載并發(fā)度又不夠。

https 下重建連接的時(shí)間成本比 http 更高，對于上面提到的簡單的大型站點(diǎn), 可以用少量域名就能滿足需求，對于百度這樣富展現(xiàn)樣式較多的搜索引擎來說，頁面可能展示的資源種類太多。而不同類型的資源又是由不同的域名 (不同的產(chǎn)品 或者第三方產(chǎn)品) 提供的服務(wù)，換一個(gè)詞搜索就可能需要重新建立一些資源的 ssl 鏈接，會讓用戶感受到卡頓。

如果將域名限制在有限的范圍，維持和這些域名的連接，合并一些數(shù)據(jù)，加上有 spdy，http2.0 來保證并發(fā)，是可以滿足我們的需求的。

標(biāo)簽： HTTPS協(xié)議 https和http有什么區(qū)別 HTTPS站點(diǎn)優(yōu)化 

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。