您好!歡迎進(jìn)入廣東華商網(wǎng)絡(luò)科技有限公司

東莞做網(wǎng)站

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

2019-11-13

        HTTPS很安全,很古老也很成熟,為什么一直到今天我們還有66%的網(wǎng)站不支持HTTPS呢?原因有兩點(diǎn):

170.jpg

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的訪問速度在經(jīng)過優(yōu)化之后是不會(huì)比HTTP慢;

        2、貴,特別在計(jì)算性能和服務(wù)器成本方面。HTTPS為什么會(huì)增加服務(wù)器的成本?相信大家也都清楚HTTPS要額外計(jì)算,要頻繁地做加密和解密操作,幾乎每一個(gè)字節(jié)都需要做加解密,這就產(chǎn)生了服務(wù)器成本,但也有兩點(diǎn)大家可能并不清楚:

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

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

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

    HTTPS主要的計(jì)算環(huán)節(jié)

        首先看HTTPS主要的計(jì)算環(huán)節(jié),下圖是一個(gè)協(xié)議交互的簡要介紹圖,它的四種顏色分別代表4種不同的主要計(jì)算環(huán)節(jié):

        紅色環(huán)節(jié)是非對(duì)稱密鑰交換,通過客戶端和服務(wù)端不一致的信息協(xié)商出對(duì)稱的密鑰;

        藍(lán)色環(huán)節(jié)是證書校驗(yàn),對(duì)證書的簽名進(jìn)行校驗(yàn),確認(rèn)網(wǎng)站的身份;

        深綠色環(huán)節(jié)是對(duì)稱加解密,通過非對(duì)稱密鑰交換協(xié)商出對(duì)稱密鑰來進(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)。
        算法:

171.jpg

所謂的算法其實(shí)是HTTPS所用到密碼學(xué)里最基本的算法,包括對(duì)稱加密、非對(duì)稱密鑰交換、簽名算法、一致性校驗(yàn)算法等,對(duì)應(yīng)的分析手段也很簡單:openssl speed;

        協(xié)議:因?yàn)椴煌膮f(xié)議版本和消息所對(duì)應(yīng)使用的算法是不一樣的,雖然算法的性能很確定,但是和協(xié)議關(guān)聯(lián)起來它就不確定了。由于性能和協(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)事件的分析,它也比較簡單,我們對(duì)系統(tǒng)進(jìn)行壓力測(cè)試,用perf record對(duì)事件進(jìn)行記錄,然后使用flame graph將它們可視化出來,最后看到一些相關(guān)數(shù)據(jù)和結(jié)果。

        1、總結(jié)以上計(jì)算性能分析:

        2、完全握手的性能不到普通HTTP性能的10%,如果說HTTP的性能是QPS 1萬,HTTPS可能只有幾百;

        3、為什么會(huì)這么低呢?主要是RSA算法,它對(duì)性能的影響占了75%左右;

        4、ECC橢圓曲線如果使用最常用的ECDHE算法,這部分約占整體計(jì)算量的7%;

        5、對(duì)稱加解密和MAC計(jì)算,它們對(duì)性能影響比較小,是微秒級(jí)別的。

       

172.jpg

有了這些分析結(jié)論,如何優(yōu)化呢?我們總結(jié)了三個(gè)步驟:

        首先第一步也是最簡單的一個(gè)優(yōu)化策略,就是減少完全握手的發(fā)生,因?yàn)橥耆帐炙浅O臅r(shí)間;

        對(duì)于不能減少的完全握手,對(duì)于必須要發(fā)生的完全握手,對(duì)于需要直接消耗CPU進(jìn)行的握手,我們使用代理計(jì)算;

        對(duì)稱加密的優(yōu)化評(píng)論;

        簡化握手的原理以及實(shí)現(xiàn)
        我們首先來看完全握手和簡化握手,這是TLS層的概念,我簡單說下簡化握手的兩個(gè)好處:
        首先簡化握手相比完全握手要少一個(gè)RTT(網(wǎng)絡(luò)交互),從完全握手大家可以看出來,它需要兩個(gè)握手交互才能進(jìn)行第三步應(yīng)用層的傳輸,而簡化握手只需要一個(gè)RTT就能進(jìn)行應(yīng)用層的數(shù)據(jù)傳輸;
完全握手有ServerKeyExchange的消息(紅色框部分),這個(gè)消息之前提過需要2.4毫秒,另外完全握手有Certificate證書的消息,而簡化握手并不需要。這也就是簡化握手第二個(gè)好處,它減少了計(jì)算量,它不需要CPU消耗太多時(shí)間。

        既然簡化握手這么好,我們?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ā)生過完全握手,是可以信任的,然后可以直接進(jìn)行簡化握手。

        第二個(gè)策略是Session Ticket,同樣它也是客戶端發(fā)起握手時(shí)會(huì)攜帶上的擴(kuò)展,服務(wù)器拿到Session Ticket后會(huì)對(duì)它進(jìn)行解密,如果解密成功了就意味著它是值得信任的,從而可以進(jìn)行簡化握手,直接傳輸應(yīng)用層數(shù)據(jù)。

        工程實(shí)現(xiàn)上會(huì)有什么問題呢?現(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或者說LVS下面有多臺(tái)Nginx,那么第一臺(tái)Nginx產(chǎn)生的ID返回給用戶,用戶可能隔了一個(gè)小時(shí)候之后再發(fā)起SSL握手,它攜帶上的Session ID肯定會(huì)隨機(jī)地落到某一臺(tái)Nginx上面(比如落在第三臺(tái)Nginx上),這樣肯定無法查找到之前的Session ID,無法進(jì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ì)超過一千次。

        我們?nèi)绾芜M(jìn)行改進(jìn)?我們看第一個(gè)問題(Session Cache)的兩個(gè)改進(jìn)方案:

東莞網(wǎng)站優(yōu)化

        1、 IP Hash,這是最簡單的根據(jù)IP做Hash的負(fù)載均衡策略,相信大家對(duì)此都很清楚,這方案的好處是可以保證相同的IP用戶永遠(yuǎn)都在同一臺(tái)Nginx上面,Session Cache的命中率會(huì)提升,但是它有兩個(gè)缺點(diǎn):
它容易導(dǎo)致熱點(diǎn),我們有很多Net網(wǎng)關(guān)出口IP用戶的訪問量非常大,也就是說有一些IP請(qǐng)求非常大導(dǎo)致某一臺(tái)機(jī)器負(fù)載不均衡;用戶IP可能會(huì)經(jīng)常變化,特別在移動(dòng)端上,在Wi-Fi和4G環(huán)境下切換導(dǎo)致的IP變化同樣會(huì)使Session Cache的命中率降低。

        2、分布式緩存(分布式Session Cache),這是更優(yōu)的方案,假如用戶開始發(fā)起握手,我們第一臺(tái)Nginx生成ID會(huì)寫入到一個(gè)全局的比如redis緩存里,然后返回給用戶。用戶下一次發(fā)起握手的時(shí)候,假如他落到第三臺(tái)Nginx上面,由于我們都是全局的Session Cache查找,這命中率一下就提升上來了。我們實(shí)現(xiàn)了這個(gè)方案,但暫時(shí)還沒有開源,在這里可以給大家推薦兩個(gè)開源方案,大家有興趣可以了解一下。OpenResty,它提供了SSL Cache全局查找的指令;BoringSSL,這是Google fork OpenSSL的版本,它也在SSL層面上實(shí)現(xiàn)了異步的Session Cache查找。

        接下來我們看Session Ticket,由于Session Cache有個(gè)缺點(diǎn)是必須在服務(wù)端做緩存,會(huì)浪費(fèi)很大內(nèi)存,而Session Ticket有個(gè)好處是它不需要服務(wù)端做緩存,但同樣它也有個(gè)缺點(diǎn):默認(rèn)情況下比如三臺(tái)Nginx各自的Session Ticket加解密密鑰是不同(這里的密鑰是指Session Ticket的對(duì)稱加解密的密鑰而不是指證書對(duì)應(yīng)的私鑰)。舉個(gè)例子,比如第一臺(tái)Nginx的Session Ticket用密鑰加密返回給用戶,用戶下一次再訪問落到第三臺(tái)機(jī)器,你用第一臺(tái)機(jī)器加密產(chǎn)生的密鑰用第三臺(tái)的密鑰去解密肯定會(huì)失敗。這個(gè)問題很好解決,我們將所有的Nginx機(jī)器配置成同一個(gè)加解密的密鑰就可以了,這樣也能實(shí)現(xiàn)簡化握手。

        我們看一下第三個(gè)方案:Self Session Ticket。Session ID和Session Cache都有一個(gè)共同點(diǎn):Session基于內(nèi)存,如果我們的App、瀏覽器或操作系統(tǒng)如果第一次啟動(dòng)或重啟(或者瀏覽器的Tab關(guān)閉后又打開)都有可能導(dǎo)致Session ID和Session Ticket丟失,出于安全角度考慮,這情況下就必須要發(fā)起完全握手,怎么解決呢?如果這個(gè)App是我們完全自主、獨(dú)立自主開發(fā),我們可以實(shí)現(xiàn)Self Session Ticket,我們將Ticket存儲(chǔ)在硬盤里面,而不是在內(nèi)存里。這顯然會(huì)帶來一定的安全風(fēng)險(xiǎn),但是我們會(huì)做一些限制:Ticket存儲(chǔ)在App的私有路徑里,對(duì)非Root的手機(jī)是很難讀取到私有路徑的數(shù)據(jù);我們可以選擇對(duì)一些安全系數(shù)要求不是很高的業(yè)務(wù)開啟這個(gè)功能;這個(gè)密鑰開關(guān)我們做到可以隨時(shí)控制。綜上,即使這方案出現(xiàn)最危險(xiǎn)的情況,其實(shí)是和HTTP方案是一樣的,它不會(huì)比HTTP方案安全性要差。

        更多資訊請(qǐng)關(guān)注華商更多資訊,我們華商網(wǎng)絡(luò)是一家專業(yè)致力于為中國企業(yè)提供全方位、多層面的信息化服務(wù)的運(yùn)營商。以40余家分公司為依托,在全國主要城市和二、三級(jí)城市建立了龐大的專業(yè)服務(wù)網(wǎng)絡(luò),為客戶提供便捷、優(yōu)質(zhì)的本地化服務(wù)。主要義務(wù)有:網(wǎng)站設(shè)計(jì),網(wǎng)站優(yōu)化,東莞網(wǎng)站建設(shè),東莞網(wǎng)站推廣,東莞網(wǎng)站制作,東莞網(wǎng)絡(luò)服務(wù),東莞SEO優(yōu)化等等


標(biāo)簽

近期瀏覽:

熱門搜索:東莞網(wǎng)站建設(shè)東莞做網(wǎng)站東莞建網(wǎng)站

華商網(wǎng)絡(luò)專業(yè)為企業(yè)提供基礎(chǔ)互聯(lián)網(wǎng)建設(shè)服務(wù):網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)站設(shè)計(jì),微官網(wǎng)設(shè)計(jì)制作,小程序開發(fā)等等,您的選擇是我們奮力向前的最好動(dòng)力!

版權(quán)所有:廣東華商網(wǎng)絡(luò)科技有限公司 備案號(hào): 粵ICP備13071417號(hào)

獲取同行網(wǎng)站建設(shè)方案,10秒填寫,急速獲得

今日已有165人獲取方案

在線客服
服務(wù)熱線
400 0769 366
15217380701

業(yè)務(wù)咨詢微信
返回頂部