大型互聯(lián)網(wǎng)站點HTTPS實踐(四)：協(xié)議層以外的實踐

大型互聯(lián)網(wǎng)站點HTTPS實踐（四）：協(xié)議層以外的實踐1前言網(wǎng)上介紹https的文章并不多，更鮮有分享在大型互聯(lián)網(wǎng)站點部署https的實踐經(jīng)驗，本文為大家介紹百度https實踐和部署https上的一些權(quán)衡，希望以此拋磚引玉。2協(xié)議層以外的實踐工作2.1全站覆蓋https的理由很多剛接觸https的會思考，我是不是只要站點的主域名換了https就可以?答案是不行。https的目的就是保證傳輸過程的安全，如果只有主域名上了https，但是主域名加載的資源，比如js，css，圖片沒有上https，會怎么樣？從效果上來說，沒有達到保證網(wǎng)站傳輸過程安全的目的，因為你的js，css，圖片仍然有被劫持的可能性，如果這些內(nèi)容被篡改/嗅探了，那么https的意義就失去了。瀏覽器在設(shè)計上早就考慮的這樣的情況，會有相應(yīng)的提示。具體的實現(xiàn)依賴瀏覽器，例如地址欄鎖形標(biāo)記從綠色變?yōu)辄S色阻止這次請求，或者直接彈出非常影響用戶體驗的提示（主要是IE），用戶會感覺厭煩，疑惑和擔(dān)憂安全性。很多用戶看見這個鏈接會習(xí)慣性的點”是"，這樣非https的資源就被禁止加載了。非ie的瀏覽器很多也會阻止加載一些危害程度較高的非https資源（例如js）。我們發(fā)現(xiàn)移動端瀏覽器的限制目前會略松一些。所以這里要是沒做好，很多情況連網(wǎng)站的基本功能都沒法正常使用。如何解決“此頁中包含其他不安全資源”？請百度：網(wǎng)站安裝SSL證書提示”此頁中包含其他不安全資源”解決辦法2.2站點的區(qū)別很多人剛接觸https的時候，覺得不就是部署證書嗎，在沃通CA申請一個免費的https證書，讓webserver支持https就行了嗎。實際上對于不同的站點來說,https的部署方式和難度有很大的區(qū)別。對于一個大型站點來說，讓webserver支持https，以及對webserver在https協(xié)議特性上做一些優(yōu)化，在遷移的工作比重上，可能只占到20%-40%。我們考慮下以下幾種情況下，部署https的方案。2.2.1簡單的個人站點簡單的定義：資源只從本站的主域或者主域的子域名加載。比如axyz的個人blog，域名是。加載主域名下的js和圖片。這樣的站部署https，在已有證書且webserver支持的情況下，只需要把主域名替換為https接入，然后把資源連接修改為https://或者〃。2.2.2復(fù)雜的個人站點復(fù)雜的定義：資源需要從外部域名加載。這樣就比較麻煩了，主域資源容易適配https，在cdn上加載的資源還需要cdn服務(wù)商支持https。目前各大cdn的服務(wù)商正在逐漸提供https的支持，需要遷移的朋友可以看看自己使用的cdn是否提供了這項能力。一些cdn會對https流量額外收費。Cdn使用https常見的方案有:

1網(wǎng)站主提供私鑰給cdn,回源使用http。2cdn使用公共域名，公共的證書，這樣資源的域名就不能自定義了?；卦词褂胔ttp。3僅提供動態(tài)加速，cdn進行tcp代理，不緩存內(nèi)容。4CloudFlare提供了KeylessSSL的服務(wù)，能夠支持不愿意提供私鑰，不想使用公共的域名和證書卻又需要使用cdn的站點了。2.2.3簡單的大型站點簡單的定義：資源只從本站的主域，主域的子域，或者自建/可控的cdn域名加載，幾乎沒有第三方資源。如果網(wǎng)站本身的特性就如此，或愿意改造為這樣的類型，部署https就相對容易。GoogleTwitter都是非常好的范例。優(yōu)點：已經(jīng)改成這樣的站點，替換https就比較容易。缺點：如果需要改造，那么要很大的決心，畢竟幾乎不能使用多樣化的第三方資源了。2.2.4復(fù)雜，訪問速度重要性稍低的大型站點復(fù)雜的定義：從本站的非主域，或者第三方站點的域名有大量的第三方資源需要加載，多出現(xiàn)在一些平臺類，或者有復(fù)雜內(nèi)容展現(xiàn)的的網(wǎng)站。訪問速度要求：用戶停留時間長或者強需求，用戶對訪問速度的耐受程度較高。比如門戶，視頻，在線交易類（比如火車票機票商城）網(wǎng)站。這樣的站點，可以努力推動所有相關(guān)域名升級為支持https。我們用下圖舉例說明下這樣修改會導(dǎo)致一個網(wǎng)站的鏈接發(fā)生怎樣的改變。丿7品帀匚.b也口xyFblcigtdiiNcim/1j百丿7品帀匚.b也口xyFblcigtdiiNcim/1j百fjquaRjsf 葉ECil&gCHni|a4"古機rk/itjirdS亡oh尤otn/i他fhrrp;"iv.bigaxyNblcig￡dFu:cim/vf2'l>l5G4Cd_mp4時和：打iffiOjiebmLX皆zb燦EonVdDriQhTT&y/卅卅卅-thindl￡OfnZirmM1jpg"ttp：//戦內(nèi)嗽thydl*工。啊flush/占則fhrtirr/gtoitii匚rthirc! 工iwf

負責(zé)流量接入的團隊將可控的接入環(huán)境改造為http和https都支持，這樣前端工程的工作相對就少一些。大部分時候?qū)㈡溄訌膆ttp://替換為//即可.在主域名是https的情況下，其它資源就能自動從https協(xié)議下加載。一些第三方資源怎么辦?一般來說只有兩種選擇，一遷移到自己的cdn或者ide吧，二強制要求第三方自己能支持https。以全站https接入的facebook舉例。第三方廠商想在facebook上線一個游戲。facebook:請?zhí)峁﹉ttps接入吧。第三方想：能賺錢啊，還是提供下https接入吧。所以，足夠強勢，有吸引力，合作方也有提供https的能力的話，這是完全可行的。如果你的平臺接入的都是一些個人開發(fā)者，而且還賺不到多少錢的情況下，這樣就行不通了。優(yōu)點：前端改動相對簡單，不容易出現(xiàn)https下還有http的資源問題。缺點：通常這樣的實現(xiàn)下，用戶的訪問速度會變慢，比如從2.5秒變?yōu)?秒，如上述的理由，用戶還是能接受的。對第三方要求高。2.2.5復(fù)雜，訪問速度有嚴格要求的大型站點復(fù)雜的定義：同上。訪問速度要求：停留時間不長，用戶對訪問速度的心理預(yù)期較高。但是如果用戶把網(wǎng)站當(dāng)作工具使用，需要你很快給出響應(yīng)的時候，這樣的實現(xiàn)就不好了。后續(xù)幾個部分我們介紹下這些優(yōu)化的抉擇。2.3域名的選擇域名對訪問速度的影響具有兩面性：域名多，域名解析和建立連接的時間就多域名少，下載并發(fā)度又不夠。https下重建連接的時間成本比http更高，對于上面提到的簡單的大型站點可以用少量域名就能滿足需求，對于百度這樣富展現(xiàn)樣式較多的搜索引擎來說，頁面可能展示的資源種

類太多。而不同類型的資源又是由不同的域名（不同的產(chǎn)品或者第三方產(chǎn)品）提供的服務(wù)，換一個詞搜索就可能需要重新建立一些資源的ssl鏈接，會讓用戶感受到卡頓。如果將域名限制在有限的范圍，維持和這些域名的連接，合并一些數(shù)據(jù)，加上有spdy，http2.0來保證并發(fā)，是可以滿足我們的需求的。2.4連接復(fù)用連接復(fù)用率可以分為tcp和ssl等不同的層面，需要分開進行分析和統(tǒng)計。2.4.1連接復(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ù)如下:

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

最簡單有效的方式就是在主域下對連接進行預(yù)建，可以通過請求一些靜態(tài)資源的方式。但是這樣還是不容易做到極致，因為使用哪個連接，并發(fā)多少還是瀏覽器控制的。例如你對a域名請求一個圖片，劉覽器建立了兩個連接，再請求一張圖片的時候，劉覽器很大概率能夠復(fù)用連接，但是當(dāng)a域名需要加載10個圖片的時候，瀏覽器很可能就會新建連接了。243Spdy的影響Spdy對于連接復(fù)用率的提升非常有效，因為它能支持連接上的并發(fā)請求，斤以瀏覽器會盡量在這個鏈接上保持復(fù)用。2.4.4其它也可以嘗試一些其他發(fā)方法，讓瀏覽器在訪問你的網(wǎng)站之前就建立過https連接，這樣session能夠復(fù)用。HSTS也能有效的減少跳轉(zhuǎn)時間，可惜對于復(fù)雜的網(wǎng)站來說，開啟需要考慮清楚很多問題。2.5優(yōu)化的效果從百度的優(yōu)化經(jīng)驗來看看，如果不開啟HSTS，用戶在瀏覽器直接訪問主域名，再通過302跳轉(zhuǎn)到HTTPS。增加的時間平均會有400ms+，其中302跳轉(zhuǎn)和ssl握手的因素各占一半。但是對于后續(xù)的請求，我們做到了對絕大部分用戶幾乎無感知。這400ms+還有很多可以優(yōu)化的空間，我們會持續(xù)優(yōu)化用戶的體驗。3HTTPS遷移遇到的一些常見問題。3.1傳遞Referrer我們可以把自己的網(wǎng)站替換為https，但是一般的站點都有外鏈，要讓外鏈都https目前還不太現(xiàn)實。很多網(wǎng)站需要從referrer中判斷流量來源，因此對于搜索引擎這樣的網(wǎng)站來說，referer的傳遞還是比較重要的。如果不做任何設(shè)置，你會發(fā)現(xiàn)在https站點中點擊

外鏈并沒有將referrer帶入到http請求的頭部?，F(xiàn)代的瀏覽器可以用meta標(biāo)簽來傳遞refer。傳遞完整的url只傳遞站點，不包含路徑和參數(shù)等。對于不支持meta傳遞referrer的瀏覽器，例如IE8,我們怎么辦呢？可以采用再次跳轉(zhuǎn)的方法，既然HTTPS下不能給HTTP傳遞referer，我們可以先從HTTPS訪問一個可控的http站點，把需要傳遞的內(nèi)容放到這個http站點的url中，然后再跳轉(zhuǎn)到目標(biāo)地址。3.2form提交有時需要將form提交到第三方站點，而第三方站點又是http的地址，瀏覽器會有不安全的警告?？梢院蛂eferrer的跳轉(zhuǎn)傳遞采取相似的邏輯。但是這樣對referer和form等內(nèi)容的方案，并不是完美的解決方法，因為這樣還是增加了不安全的因素（劫持，隱私泄露等）。理想情況需要用戶升級符合最新規(guī)范的瀏覽器，以及推進更多的站點遷移至https。3.3視頻播放簡單來說，如果你使用http的協(xié)議來播放視頻，那么瀏覽器仍然會有不安全的提示。所以你有兩種選擇，1讓視頻源提供https。2使用非http的協(xié)議，如rtmp協(xié)議。

3.4用戶異常在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明0個網(wǎng)站都要500-2000ms。這時https自然也會很慢。4