為什么超過(guò)百分之六十的網(wǎng)站不支持HTTPS？

HTTPS很安全，很古老也很成熟，為什么一直到今天我們還有66%的網(wǎng)站不支持HTTPS呢？原因有兩點(diǎn)：
1、慢，HTTPS未經(jīng)任何優(yōu)化的情況下要比HTTP慢幾百毫秒以上，特別在移動(dòng)端可能要慢500毫秒以上，關(guān)于HTTPS慢和如何優(yōu)化已經(jīng)是一個(gè)非常系統(tǒng)和復(fù)雜的話題，由于時(shí)間的關(guān)系，本次分享就不做介紹了。但有一點(diǎn)可以肯定的是，HTTPS的訪問(wèn)速度在經(jīng)過(guò)優(yōu)化之后是不會(huì)比HTTP慢；
2、貴，特別在計(jì)算性能和服務(wù)器成本方面。HTTPS為什么會(huì)增加服務(wù)器的成本？相信大家也都清楚HTTPS要額外計(jì)算，要頻繁地做加密和解密操作，幾乎每一個(gè)字節(jié)都需要做加解密，這就產(chǎn)生了服務(wù)器成本，但也有兩點(diǎn)大家可能并不清楚：

      大家也很清楚HTTPS是大勢(shì)所趨，Google、Facebook和國(guó)內(nèi)諸多互聯(lián)網(wǎng)公司也已經(jīng)支持HTTPS，然而這里有兩點(diǎn)大家需要注意：

一、iOS10的ATS政策（App Transport Security）要求2017年1月1日后所有在iOS App Store上架的App都需要支持HTTPS，否則無(wú)法上架；

二、Google的Chrome瀏覽器54版本已經(jīng)將HTTP的域名輸入框前增加“!”的提示，如下圖，所有的HTTP站點(diǎn)都會(huì)有這個(gè)標(biāo)識(shí)。同樣在2017年1月1日后開(kāi)始，Chrome瀏覽器會(huì)在用戶點(diǎn)擊“!”的提示符后將該網(wǎng)站不安全的信息顯示出來(lái)，只要涉及到登錄和搜集用戶數(shù)據(jù)的頁(yè)面，只要是HTTP的都會(huì)標(biāo)注不安全，相信這也會(huì)加速HTTPS的推進(jìn)。

HTTPS主要的計(jì)算環(huán)節(jié)
      首先看HTTPS主要的計(jì)算環(huán)節(jié)，下圖是一個(gè)協(xié)議交互的簡(jiǎn)要介紹圖，它的四種顏色分別代表4種不同的主要計(jì)算環(huán)節(jié)：
      紅色環(huán)節(jié)是非對(duì)稱(chēng)密鑰交換，通過(guò)客戶端和服務(wù)端不一致的信息協(xié)商出對(duì)稱(chēng)的密鑰；
      藍(lán)色環(huán)節(jié)是證書(shū)校驗(yàn)，對(duì)證書(shū)的簽名進(jìn)行校驗(yàn)，確認(rèn)網(wǎng)站的身份；
      深綠色環(huán)節(jié)是對(duì)稱(chēng)加解密，通過(guò)非對(duì)稱(chēng)密鑰交換協(xié)商出對(duì)稱(chēng)密鑰來(lái)進(jìn)行加解密；
      淺綠色環(huán)節(jié)是完整性校驗(yàn)，不僅要加密還要防止內(nèi)容被篡改，所以要進(jìn)行自身的完整性校驗(yàn)。
      知道這些主要的計(jì)算環(huán)節(jié)之后，每一個(gè)計(jì)算環(huán)節(jié)對(duì)計(jì)算性能的影響分別是多少以及如何分析？這里和大家分享我們計(jì)算性能的分析維度，主要分為三部分：算法、協(xié)議和系統(tǒng)。

算法：
      所謂的算法其實(shí)是HTTPS所用到密碼學(xué)里最基本的算法，包括對(duì)稱(chēng)加密、非對(duì)稱(chēng)密鑰交換、簽名算法、一致性校驗(yàn)算法等，對(duì)應(yīng)的分析手段也很簡(jiǎn)單：openssl speed；       協(xié)議：因?yàn)椴煌膮f(xié)議版本和消息所對(duì)應(yīng)使用的算法是不一樣的，雖然算法的性能很確定，但是和協(xié)議關(guān)聯(lián)起來(lái)它就不確定了。由于性能和協(xié)議相關(guān)，我們重點(diǎn)分析的是協(xié)議里完全握手的階段，我們會(huì)對(duì)完全握手的每個(gè)消息和每個(gè)函數(shù)進(jìn)行時(shí)間的分析；       系統(tǒng)：比如我們使用Nginx和OpenSSL，我們會(huì)對(duì)它進(jìn)行壓力測(cè)試，然后在高并發(fā)壓力環(huán)境下對(duì)熱點(diǎn)事件進(jìn)行分析和優(yōu)化。         最后我們看熱點(diǎn)事件的分析，它也比較簡(jiǎn)單，我們對(duì)系統(tǒng)進(jìn)行壓力測(cè)試，用perf record對(duì)事件進(jìn)行記錄，然后使用flame graph將它們可視化出來(lái)，最后看到一些相關(guān)數(shù)據(jù)和結(jié)果。

1、總結(jié)以上計(jì)算性能分析：
2、完全握手的性能不到普通HTTP性能的10%，如果說(shuō)HTTP的性能是QPS 1萬(wàn)，HTTPS可能只有幾百；
3、為什么會(huì)這么低呢？主要是RSA算法，它對(duì)性能的影響占了75%左右；
4、ECC橢圓曲線如果使用最常用的ECDHE算法，這部分約占整體計(jì)算量的7%；
5、對(duì)稱(chēng)加解密和MAC計(jì)算，它們對(duì)性能影響比較小，是微秒級(jí)別的。

有了這些分析結(jié)論，如何優(yōu)化呢？我們總結(jié)了三個(gè)步驟：
      首先第一步也是最簡(jiǎn)單的一個(gè)優(yōu)化策略，就是減少完全握手的發(fā)生，因?yàn)橥耆帐炙浅Ｏ臅r(shí)間；
      對(duì)于不能減少的完全握手，對(duì)于必須要發(fā)生的完全握手，對(duì)于需要直接消耗CPU進(jìn)行的握手，我們使用代理計(jì)算；
      對(duì)稱(chēng)加密的優(yōu)化評(píng)論；
      簡(jiǎn)化握手的原理以及實(shí)現(xiàn)
      我們首先來(lái)看完全握手和簡(jiǎn)化握手，這是TLS層的概念，我簡(jiǎn)單說(shuō)下簡(jiǎn)化握手的兩個(gè)好處：
      首先簡(jiǎn)化握手相比完全握手要少一個(gè)RTT(網(wǎng)絡(luò)交互），從完全握手大家可以看出來(lái)，它需要兩個(gè)握手交互才能進(jìn)行第三步應(yīng)用層的傳輸，而簡(jiǎn)化握手只需要一個(gè)RTT就能進(jìn)行應(yīng)用層的數(shù)據(jù)傳輸；
      完全握手有ServerKeyExchange的消息（紅色框部分），這個(gè)消息之前提過(guò)需要2.4毫秒，另外完全握手有Certificate證書(shū)的消息，而簡(jiǎn)化握手并不需要。這也就是簡(jiǎn)化握手第二個(gè)好處，它減少了計(jì)算量，它不需要CPU消耗太多時(shí)間。
      既然簡(jiǎn)化握手這么好，我們?nèi)绾螌?shí)現(xiàn)？首先看協(xié)議層如何支持。TLS協(xié)議層有兩個(gè)策略可以實(shí)現(xiàn)，第一個(gè)是Session ID，Session ID由服務(wù)器生成并返回給客戶端，客戶端再次發(fā)起SSL握手時(shí)會(huì)攜帶上Session ID，服務(wù)端拿到后會(huì)從自己的內(nèi)存查找，如果找到便意味著客戶端之前已經(jīng)發(fā)生過(guò)完全握手，是可以信任的，然后可以直接進(jìn)行簡(jiǎn)化握手。
      第二個(gè)策略是Session Ticket，同樣它也是客戶端發(fā)起握手時(shí)會(huì)攜帶上的擴(kuò)展，服務(wù)器拿到Session Ticket后會(huì)對(duì)它進(jìn)行解密，如果解密成功了就意味著它是值得信任的，從而可以進(jìn)行簡(jiǎn)化握手，直接傳輸應(yīng)用層數(shù)據(jù)。
      工程實(shí)現(xiàn)上會(huì)有什么問(wèn)題呢？現(xiàn)在最常用的Nginx+OpenSSL有兩個(gè)局限：
      Nginx只支持單機(jī)多進(jìn)程間共享的Session Cache，假如我們所有接入用的是一臺(tái)服務(wù)器、一臺(tái)Nginx的話，那ID生成和查找都在一起，肯定是可以命中的，但是我們大部分特別是流量比較大的接入環(huán)境都是多臺(tái)機(jī)器接入。比如我們同一個(gè)TGW或者說(shuō)LVS下面有多臺(tái)Nginx，那么第一臺(tái)Nginx產(chǎn)生的ID返回給用戶，用戶可能隔了一個(gè)小時(shí)候之后再發(fā)起SSL握手，它攜帶上的Session ID肯定會(huì)隨機(jī)地落到某一臺(tái)Nginx上面（比如落在第三臺(tái)Nginx上），這樣肯定無(wú)法查找到之前的Session ID，無(wú)法進(jìn)行簡(jiǎn)化握手，這是第一個(gè)局限，即命中率會(huì)比較低；
      OpenSSL提供了一個(gè)Session Cache的callback可以回調(diào)，但是這個(gè)回調(diào)函數(shù)是同步的，而Nginx是完全異步事件驅(qū)動(dòng)的框架，如果Nginx調(diào)用這個(gè)callback進(jìn)行網(wǎng)絡(luò)查找，假如這個(gè)網(wǎng)絡(luò)查找需要1毫秒，這意味著整體性能不會(huì)超過(guò)一千次。