<var id="rhdfd"><strike id="rhdfd"><thead id="rhdfd"></thead></strike></var>
<cite id="rhdfd"><video id="rhdfd"><menuitem id="rhdfd"></menuitem></video></cite>
<var id="rhdfd"></var>
<var id="rhdfd"><video id="rhdfd"></video></var>
<var id="rhdfd"><dl id="rhdfd"><listing id="rhdfd"></listing></dl></var><var id="rhdfd"></var><var id="rhdfd"></var>
<var id="rhdfd"></var>
<menuitem id="rhdfd"></menuitem>
<var id="rhdfd"><strike id="rhdfd"><thead id="rhdfd"></thead></strike></var><var id="rhdfd"><video id="rhdfd"></video></var>
<cite id="rhdfd"><video id="rhdfd"><menuitem id="rhdfd"></menuitem></video></cite>
<var id="rhdfd"></var>
<cite id="rhdfd"><span id="rhdfd"><menuitem id="rhdfd"></menuitem></span></cite><var id="rhdfd"></var>

網站制作百科

聯系我們

相關推薦

網站制作百科

首頁 > 新聞動態 > 網站制作百科 > >

為什么超過百分之六十的網站不支持HTTPS?

發布日期:2017-02-20來源:www.bikipduongtrangda.com

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

網站優化

1、慢,HTTPS未經任何優化的情況下要比HTTP慢幾百毫秒以上,特別在移動端可能要慢500毫秒以上,關于HTTPS慢和如何優化已經是一個非常系統和復雜的話題,由于時間的關系,本次分享就不做介紹了。但有一點可以肯定的是,HTTPS的訪問速度在經過優化之后是不會比HTTP慢;

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

        大家也很清楚HTTPS是大勢所趨,Google、Facebook和國內諸多互聯網公司也已經支持HTTPS,然而這里有兩點大家需要注意:

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

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

 

    HTTPS主要的計算環節

        首先看HTTPS主要的計算環節,下圖是一個協議交互的簡要介紹圖,它的四種顏色分別代表4種不同的主要計算環節:

        紅色環節是非對稱密鑰交換,通過客戶端和服務端不一致的信息協商出對稱的密鑰;

        藍色環節是證書校驗,對證書的簽名進行校驗,確認網站的身份;

        深綠色環節是對稱加解密,通過非對稱密鑰交換協商出對稱密鑰來進行加解密;

        淺綠色環節是完整性校驗,不僅要加密還要防止內容被篡改,所以要進行自身的完整性校驗。

         知道這些主要的計算環節之后,每一個計算環節對計算性能的影響分別是多少以及如何分析?這里和大家分享我們計算性能的分析維度,主要分為三部分:算法、協議和系統。
        算法:

網站建設

所謂的算法其實是HTTPS所用到密碼學里最基本的算法,包括對稱加密、非對稱密鑰交換、簽名算法、一致性校驗算法等,對應的分析手段也很簡單:openssl speed;

        協議:因為不同的協議版本和消息所對應使用的算法是不一樣的,雖然算法的性能很確定,但是和協議關聯起來它就不確定了。由于性能和協議相關,我們重點分析的是協議里完全握手的階段,我們會對完全握手的每個消息和每個函數進行時間的分析;

        系統:比如我們使用Nginx和OpenSSL,我們會對它進行壓力測試,然后在高并發壓力環境下對熱點事件進行分析和優化。

         最后我們看熱點事件的分析,它也比較簡單,我們對系統進行壓力測試,用perf record對事件進行記錄,然后使用flame graph將它們可視化出來,最后看到一些相關數據和結果。

        1、總結以上計算性能分析:

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

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

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

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

       

東莞網站建設

有了這些分析結論,如何優化呢?我們總結了三個步驟:

        首先第一步也是最簡單的一個優化策略,就是減少完全握手的發生,因為完全握手它非常消耗時間;

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

        對稱加密的優化評論;

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

        既然簡化握手這么好,我們如何實現?首先看協議層如何支持。TLS協議層有兩個策略可以實現,第一個是Session ID,Session ID由服務器生成并返回給客戶端,客戶端再次發起SSL握手時會攜帶上Session ID,服務端拿到后會從自己的內存查找,如果找到便意味著客戶端之前已經發生過完全握手,是可以信任的,然后可以直接進行簡化握手。

        第二個策略是Session Ticket,同樣它也是客戶端發起握手時會攜帶上的擴展,服務器拿到Session Ticket后會對它進行解密,如果解密成功了就意味著它是值得信任的,從而可以進行簡化握手,直接傳輸應用層數據。

        工程實現上會有什么問題呢?現在最常用的Nginx+OpenSSL有兩個局限:

        Nginx只支持單機多進程間共享的Session Cache,假如我們所有接入用的是一臺服務器、一臺Nginx的話,那ID生成和查找都在一起,肯定是可以命中的,但是我們大部分特別是流量比較大的接入環境都是多臺機器接入。比如我們同一個TGW或者說LVS下面有多臺Nginx,那么第一臺Nginx產生的ID返回給用戶,用戶可能隔了一個小時候之后再發起SSL握手,它攜帶上的Session ID肯定會隨機地落到某一臺Nginx上面(比如落在第三臺Nginx上),這樣肯定無法查找到之前的Session ID,無法進行簡化握手,這是第一個局限,即命中率會比較低;

        OpenSSL提供了一個Session Cache的callback可以回調,但是這個回調函數是同步的,而Nginx是完全異步事件驅動的框架,如果Nginx調用這個callback進行網絡查找,假如這個網絡查找需要1毫秒,這意味著整體性能不會超過一千次。

        我們如何進行改進?我們看第一個問題(Session Cache)的兩個改進方案:

東莞網站優化

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

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

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

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

        更多資訊請關注華商更多資訊,我們華商網絡是一家專業致力于為中國企業提供全方位、多層面的信息化服務的運營商。以40余家分公司為依托,在全國主要城市和二、三級城市建立了龐大的專業服務網絡,為客戶提供便捷、優質的本地化服務。主要義務有:網站設計,網站優化,東莞網站建設,東莞網站推廣,東莞網站制作,東莞網絡服務,東莞SEO優化等等

案例推薦:

在線咨詢

業務咨詢微信
返回頂部