大型網站的HTTPS實踐四:協議層以外的實踐

1 前言

網上介紹 https 的文章並不多,更鮮有分享在大型互聯網站點部署 https 的實踐經驗,我們在考慮部署 https 時也有重重的疑惑。

本文為大傢介紹百度 HTTPS 的實踐和一些權衡,希望以此拋磚引玉。

2 協議層以外的實踐工作

2.1 全站覆蓋 https 的理由

很多剛接觸 https 的會思考,我是不是隻要站點的主域名換瞭 https 就可以?答案是不行。

https 的目的就是保證傳輸過程的安全,如果隻有主域名上瞭 https,但是主域名加載的資源,比如 js,css,圖片沒有上 https,會怎麼樣?

從效果上來說,沒有達到保證網站傳輸過程安全的目的,因為你的 js,css,圖片仍然有被劫持的可能性,如果這些內容被篡改 / 嗅探瞭,那麼 https 的意義就失去瞭。

瀏覽器在設計上早就考慮的這樣的情況,會有相應的提示。具體的實現依賴瀏覽器,例如地址欄鎖形標記從綠色變為黃色, 阻止這次請求,或者直接彈出非常影響用戶體驗的提示 (主要是 IE),用戶會感覺厭煩,疑惑和擔憂安全性。

很多用戶看見這個鏈接會習慣性的點是,這樣非 https 的資源就被禁止加載瞭。非 ie 的瀏覽器很多也會阻止加載一些危害程度較高的非 https 資源(例如 js)。我們發現移動端瀏覽器的限制目前會略松一些。

所以這裡要是沒做好,很多情況連網站的基本功能都沒法正常使用。

2.2 站點的區別

很多人剛接觸 https 的時候,覺得不就是部署證書,讓 webserver 支持 https 就行瞭嗎。

實際上對於不同的站點來說,https 的部署方式和難度有很大的區別。對於一個大型站點來說,讓 webserver 支持 https,以及對 webserver 在 https 協議特性上做一些優化,在遷移的工作比重上,可能隻占到 20%-40%。

我們考慮下以下幾種情況下,部署 https 的方案。

2.2.1 簡單的個人站點

簡單的定義:資源隻從本站的主域或者主域的子域名加載。

比如 axyz 的個人 blog,域名是 axyzblog.com。加載主域名下的 js 和圖片。

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

2.2.2 復雜的個人站點

復雜的定義:資源需要從外部域名加載。

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

Cdn 使用 https 常見的方案有:

1 網站主提供私鑰給 cdn,回源使用 http。

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

3 僅提供動態加速,cdn 進行 tcp 代理,不緩存內容。

4 CloudFlare 提供瞭Keyless SSL的服務,能夠支持不願意提供私鑰, 不想使用公共的域名和證書卻又需要使用 cdn 的站點瞭。

2.2.3 簡單的大型站點

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

2.2.4 復雜,訪問速度重要性稍低的大型站點

復雜的定義:從本站的非主域,或者第三方站點的域名有大量的第三方資源需要加載,多出現在一些平臺類,或者有復雜內容展現的的網站。

訪問速度要求:用戶停留時間長或者強需求,用戶對訪問速度的耐受程度較高。比如門戶,視頻,在線交易類(比如火車票 機票 商城)網站。

這樣的站點,可以努力推動所有相關域名升級為支持 https。我們用下圖舉例說明下這樣修改會導致一個網站的鏈接發生怎樣的改變。

負責流量接入的團隊將可控的接入環境改造為 http 和 https 都支持,這樣前端工程的工作相對就少一些。大部分時候將鏈接從 http:// 替換為 // 即可. 在主域名是 https 的情況下,其它資源就能自動從 https 協議下加載。一些第三方資源怎麼辦?一般來說隻有兩種選擇,一遷移到自己的 cdn 或者 idc 吧,二強制要求第三方自己能支持 https。

以全站 https 接入的 facebook 舉例。第三方廠商想在 facebook 上線一個遊戲。facebook:請提供 https 接入吧。第三方想:能賺錢啊,還是提供下 https 接入吧。所以,足夠強勢,有吸引力,合作方也有提供 https 的能力的話,這是完全可行的。如果你的平臺接入的都是一些個人開發者,而且還賺不到多少錢的情況下,這樣就行不通瞭。

優點:前端改動相對簡單,不容易出現 https 下還有 http 的資源問題。

缺點:通常這樣的實現下,用戶的訪問速度會變慢,比如從 2.5 秒變為 3 秒,如上述的理由,用戶還是能接受的。對第三方要求高。

2.2.5 復雜,訪問速度有嚴格要求的大型站點

復雜的定義:同上。

訪問速度要求:停留時間不長,用戶對訪問速度的心理預期較高。

但是如果用戶把網站當作工具使用,需要你很快給出響應的時候,這樣的實現就不好瞭。後續幾個部分我們介紹下這些優化的抉擇。

2.3 域名的選擇

域名對訪問速度的影響具有兩面性:域名多,域名解析和建立連接的時間就多;域名少,下載並發度又不夠。

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

如果將域名限制在有限的范圍,維持和這些域名的連接,合並一些數據,加上有 spdy,http2.0 來保證並發,是可以滿足我們的需求的。