為什么超過百分之六十的網站不支持HTTPS？
發布時間：2025-06-20 點擊：5
為什么超過百分之六十的網站不支持https？
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毫秒，這意味著整體性能不會超過一千次。
佛山定制型網站建設的特點是什么？
教你如何打破廣州網站建設沒有流量的局面！
建網站時如何設置網站的頁腳
教你怎么解決網站被降權被K站的風險
建設移動網站的四個基本要素
企業制作網站為什么要定制？
企業品牌網站建設需要注意哪些事項？
新企業營銷型網站如何快速引來流量?
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毫秒，這意味著整體性能不會超過一千次。
佛山定制型網站建設的特點是什么？
教你如何打破廣州網站建設沒有流量的局面！
建網站時如何設置網站的頁腳
教你怎么解決網站被降權被K站的風險
建設移動網站的四個基本要素
企業制作網站為什么要定制？
企業品牌網站建設需要注意哪些事項？
新企業營銷型網站如何快速引來流量?