如今，越來越多的網站和服務開始啟動加密，HTTPS加密Web流量占到總流量的一半，其中YouTube這樣的流媒體網站首次有50%的流量是經過HTTPS，這一切證明了Web的完整加密是可行的。

百度自2017年底起，開始對部分地區開放了HTTPS加密搜索服務，如今百度已全站開啟了HTTPS安全加密搜索，那么，我們該如何看待百度全站采用HTTPS加密搜索呢？

HTTPS在保護用戶隱私，防止流量劫持方面發揮著非常關鍵的作用，但與此同時，HTTPS也會降低用戶訪問速度，增加網站服務器的計算資源消耗。

百度在工程開發上幾乎不做沒有性價比的事情，所以我們先看看https這個事情在技術上的投入在哪里？

一、百度啟用了HTTPS加密搜索

從2017年底開始，百度在部分地區開始對其搜索啟用了HTTPS加密(VeriSign簽發的證書)，百度HTTPS相關負責人指出，此舉致力于為用戶提供一個安全可靠的網絡環境。

當你網購的時候，你輸入銀行信息后按繼續，在與銀行網站對接的過程中，你的付款信息在網絡傳輸過程中，是被加密的，這是為了確保使客戶與服務器應用之間的通信不被攻擊者竊聽。

二、在性能方面的影響

1、多幾次握手，網絡耗時變長，用戶從http跳轉到https還要一點時間。

2、機器性能，https要多做一次RSA校驗。

3、CDN，全國所有節點要支持https才行，另外，如果面對DDOS，https的解決方案也會復雜得多。

三、對周邊系統的影響

1、頁面里所有嵌入的資源都要改成https的，這些資源可能會來自不同的部門甚至不同的公司，包括：圖片、js、form表單等等，否則瀏覽器就會報警。

2、手機百度這類使用了百度搜索服務的客戶端產品，也可能要修改。

3、解決第三方網站看不到refer的問題。

4、所有的開發、測試環境都要做https的升級。

還有，上線前肯定是一大堆預案，保證切換過程順暢，所以說下來，https這個事情的投入真心很大，不是說換就換的。

好了，這個事情的收益在哪里呢？在看來，就是用戶的搜索安全，至于原因可能有以下幾點：

1、被運營商強插廣告，甚至在正常結果前面插一條廣告。

2、有的時候劫持代碼還會寫錯，導致用戶訪問白屏或者報錯。

3、手機上被瀏覽器或者什么衛士篡改或者劫持。

4、最惡心的是泄露用戶數據，經常在網上看到說： 我用百度搜了一個黃金，馬上就有人聯系我了 我在百度上搜了一種病，馬上醫院就來電話了 。

5、另外，對百度的收入也有影響、有不少公共wifi自動會自動給百度搜索加一個聯盟的計費id。

其實在搜索HTTPS很久之前，百度就做了搜索結果url加密，我想應該是基于類似的考慮。

很多互聯網公司在做大的時候都會遇到這個問題：https成本高，速度又慢，規模小的時候在涉及到登錄和交易用上就夠了，做大以后遇到信息泄露和劫持，想整體換，代價又很高。

四、HTTPS對訪問速度的影響

在介紹速度優化策略之前，先來看下HTTPS對速度有什么影響，在看來，其影響主要來自兩方面：

①、協議交互所增加的網絡RTT(round trip time)。

②、加解密相關的計算耗時。

卡內基梅隆大學、西班牙電信和都靈理工大學的研究人員在ACM CoNEXT上發表了一篇論文（PDF），量化了網站從HTTP切換到HTTPS所付出的代價。

研究人員分析了啟用加密對延遲、消耗數據和客戶端電池壽命的影響，他們發現，HTTPS的 S 會使得頁面加載時間增加了50%，增加10%到20%的耗電，此外，HTTPS還會影響緩存增加數據開銷和功耗，以及父母控制和病毒掃描等也會受到影響。

下面分別跟大家介紹一下：

1、網絡耗時增加

由于HTTP和HTTPS都需要DNS解析，并且大部分情況下使用了DNS緩存，為了突出對比效果，忽略主域名的DNS解析時間。

用戶使用HTTP協議訪問www.或者www.時會有如下網絡上的交互耗時：

可見，用戶只需要完成TCP三次握手建立TCP連接就能夠直接發送HTTP請求獲取應用層數據，此外在整個訪問過程中也沒有需要消耗計算資源的地方。

接下來看HTTPS的訪問過程，相比HTTP要復雜很多，在部分場景下，使用HTTPS訪問有可能增加7個RTT，如下圖：

HTTPS首次請求需要的網絡耗時解釋如下：

①、三次握手建立TCP連接，耗時一個RTT。

②、使用HTTP發起GET請求，服務端返回302跳轉到www.域名需要一個RTT以及302跳轉延時。

a、大部分情況下用戶不會手動輸入www.域名來訪問HTTPS，服務端只能返回302強制瀏覽器跳轉到https。

b、瀏覽器處理302跳轉也需要耗時。

③、三次握手重新建立TCP連接，耗時一個RTT。

302跳轉到HTTPS服務器之后，由于端口和服務器不同，需要重新完成三次握手，建立TCP連接。

④、TLS完全握手階段一，耗時至少一個RTT。

a、這個階段主要是完成加密套件的協商和證書的身份認證。

b、服務端和瀏覽器會協商出相同的密鑰交換算法、對稱加密算法、內容一致性校驗算法、證書簽名算法、橢圓曲線(非ECC算法不需要)等。

c、瀏覽器獲取到證書后需要校驗證書的有效性，比如是否過期，是否撤銷。

⑤、解析CA站點的DNS，耗時一個RTT。

a、瀏覽器獲取到證書后，有可能需要發起OCSP或者CRL請求，查詢證書狀態。

b、瀏覽器首先獲取證書里的CA域名。

c、如果沒有命中緩存，瀏覽器需要解析CA域名的DNS。

⑥、三次握手建立CA站點的TCP連接，耗時一個RTT。

DNS解析到IP后，需要完成三次握手建立TCP連接。

⑦、發起OCSP請求，獲取響應。耗時一個RTT。

⑧、完全握手階段二，耗時一個RTT及計算時間。

完全握手階段二主要是密鑰協商。

⑨、完全握手結束后，瀏覽器和服務器之間進行應用層(也就是HTTP)數據傳輸。

當然不是每個請求都需要增加7個RTT才能完成HTTPS首次請求交互，據了解，大概只有不到0.01%的請求才有可能需要經歷上述步驟，它們需要滿足如下條件：

①、必須是首次請求，即建立TCP連接后發起的第一個請求，該連接上的后續請求都不需要再發生上述行為。

②、必須要發生完全握手，而正常情況下80%的請求能實現簡化握手。

③、瀏覽器需要開啟OCSP或者CRL功能，Chrome默認關閉了ocsp功能，firefox和IE都默認開啟。

④、瀏覽器沒有命中OCSP緩存，Ocsp一般的更新周期是7天，firefox的查詢周期也是7天，也就說是7天中才會發生一次ocsp的查詢。

⑤、瀏覽器沒有命中CA站點的DNS緩存，只有沒命中DNS緩存的情況下才會解析CA的DNS。

2、計算耗時增加

上節還只是簡單描述了HTTPS關鍵路徑上必須消耗的純網絡耗時，沒有包括非常消耗CPU資源的計算耗時，事實上計算耗時也不小(30ms以上)，從瀏覽器和服務器的角度分別介紹一下：

①、瀏覽器計算耗時

a、RSA證書簽名校驗，瀏覽器需要解密簽名，計算證書哈希值，如果有多個證書鏈，瀏覽器需要校驗多個證書。

b、RSA密鑰交換時，需要使用證書公鑰加密premaster，耗時比較小，但如果手機性能比較差，可能也需要1ms的時間。

c、ECC密鑰交換時，需要計算橢圓曲線的公私鑰。

d、ECC密鑰交換時，需要使用證書公鑰解密獲取服務端發過來的ECC公鑰。

e、ECC密鑰交換時，需要根據服務端公鑰計算master key。

f、應用層數據對稱加解密。

g、應用層數據一致性校驗。

②、服務端計算耗時

a、RSA密鑰交換時需要使用證書私鑰解密premaster，這個過程非常消耗性能。

b、ECC密鑰交換時，需要計算橢圓曲線的公私鑰。

c、ECC密鑰交換時，需要使用證書私鑰加密ECC的公鑰。

d、ECC密鑰交換時，需要根據瀏覽器公鑰計算共享的master key。

e、應用層數據對稱加解密。

f、應用層數據一致性校驗。

由于客戶端的CPU和操作系統種類比較多，所以計算耗時不能一概而論，手機端的HTTPS計算會比較消耗性能，單純計算增加的延遲至少在50ms以上，PC端也會增加至少10ms以上的計算延遲。

服務器的性能一般比較強，但由于RSA證書私鑰長度遠大于客戶端，所以服務端的計算延遲也會在5ms以上。

五、HTTPS協議為何沒在互聯網上全面采用？

很多人會有一個疑問：https夠不夠呢？肯定是不夠的，但是沒有更好的方案了，可為什么更安全的HTTPS協議沒有在互聯網上全面采用呢？簡單來說，有以下幾點：

1、SSL證書需要錢，功能越強大的證書費用越高，個人網站、小網站沒有必要一般不會用。

2、SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗。（SSL有擴展可以部分解決這個問題，但是比較麻煩，而且要求瀏覽器、操作系統支持，Windows XP就不支持這個擴展，考慮到XP的裝機量，這個特性幾乎沒用。）

3、HTTPS連接緩存不如HTTP高效，大流量網站如非必要也不會采用，流量成本太高。

4、HTTPS連接服務器端資源占用高很多，支持訪客稍多的網站需要投入更大的成本，如果全部采用HTTPS，基于大部分計算資源閑置的假設的VPS的平均成本會上去。

5、HTTPS協議握手階段比較費時，對網站的相應速度有負面影響，如非必要，沒有理由犧牲用戶體驗。

6、最關鍵的，SSL證書的信用鏈體系并不安全，特別是在某些國家（你們懂的）可以控制CA根證書的情況下，中間人攻擊一樣可行。

另外，在客戶端被植入無數后門、木馬的狀況下，HTTPS連接的作用非常有限，這也許是支付寶不可能像PayPal那么易用的原因之一。