 作者｜羅成編輯｜小智本文根據羅成在2016ArchSummit全球架構師（北京）峰會上的演講整理而成。主要內容分以下三部分：計算性能的分析和優(yōu)化；無密鑰加載；證書優(yōu)化。為什么66%的網站不支持HTTPS？ 談優(yōu)化之前我們先看背景和趨勢，大家也很清楚HTTPS是大勢所趨，Google、Facebook和國內諸多大型互聯(lián)網公司也已經支持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很安全，很古老也很成熟，為什么一直到今天我們還有66%的網站不支持HTTPS呢？原因有兩點： 1、慢，HTTPS未經任何優(yōu)化的情況下要比HTTP慢幾百毫秒以上，特別在移動端可能要慢500毫秒以上，關于HTTPS慢和如何優(yōu)化已經是一個非常系統(tǒng)和復雜的話題，由于時間的關系，本次分享就不做介紹了。但有一點可以肯定的是，HTTPS的訪問速度在經過優(yōu)化之后是不會比HTTP慢；  2、貴，特別在計算性能和服務器成本方面。HTTPS為什么會增加服務器的成本？相信大家也都清楚HTTPS要額外計算，要頻繁地做加密和解密操作，幾乎每一個字節(jié)都需要做加解密，這就產生了服務器成本，但也有兩點大家可能并不清楚： HTTPS有哪些主要的計算環(huán)節(jié)，是不是每個計算環(huán)節(jié)計算量都一樣？ 知道這些計算環(huán)節(jié)對CPU的影響，我們如何優(yōu)化這些計算環(huán)節(jié)？ 接下來我將介紹我們在這兩個問題上的探討。 HTTPS主要的計算環(huán)節(jié) 首先看HTTPS主要的計算環(huán)節(jié)，下圖是一個協(xié)議交互的簡要介紹圖，它的四種顏色分別代表4種不同的主要計算環(huán)節(jié)： 紅色環(huán)節(jié)是非對稱密鑰交換，通過客戶端和服務端不一致的信息協(xié)商出對稱的密鑰； 藍色環(huán)節(jié)是證書校驗，對證書的簽名進行校驗，確認網站的身份； 深綠色環(huán)節(jié)是對稱加解密，通過非對稱密鑰交換協(xié)商出對稱密鑰來進行加解密； 淺綠色環(huán)節(jié)是完整性校驗，不僅要加密還要防止內容被篡改，所以要進行自身的完整性校驗。  知道這些主要的計算環(huán)節(jié)之后，每一個計算環(huán)節(jié)對計算性能的影響分別是多少以及如何分析？這里和大家分享我們計算性能的分析維度，主要分為三部分：算法、協(xié)議和系統(tǒng)。 算法，所謂的算法其實是HTTPS所用到密碼學里最基本的算法，包括對稱加密、非對稱密鑰交換、簽名算法、一致性校驗算法等，對應的分析手段也很簡單：openssl speed； 協(xié)議，因為不同的協(xié)議版本和消息所對應使用的算法是不一樣的，雖然算法的性能很確定，但是和協(xié)議關聯(lián)起來它就不確定了。由于性能和協(xié)議相關，我們重點分析的是協(xié)議里完全握手的階段，我們會對完全握手的每個消息和每個函數進行時間的分析； 系統(tǒng)，比如我們使用Nginx和OpenSSL，我們會對它進行壓力測試，然后在高并發(fā)壓力環(huán)境下對熱點事件進行分析和優(yōu)化。  接下來詳細介紹以上的分析維度，首先是對稱加密和一致性校驗算法的測試分析，這個手段和工具（openssl speed）很簡單，我就不多介紹了。這里總結一下：下圖中柱狀圖越高表示性能越好，可以看出性能最好的是AES-128-GCM，性能最差的是AES-256-CBC，但即使它性能最差，它也只需要47微秒就能處理4000個字節(jié)，性能相比來說也還能接受。  接下來我們看密鑰交換和簽名算法的測試，下表中Sign代表服務端進行的簽名，Verify指的是客戶端對簽名進行的校驗。我們關注一下紅色數字809，這代表使用RSA-2048位時，我們服務端1秒鐘只能處理809次，這已經是我們使用線上非常好的一款CPU進行測試的結果，事實上大部分機器1秒鐘只能處理三四百次，可以說性能非常差。 接下來是Verify校驗，能看出來我們使用Ecdsa(nistp256)時一秒鐘能處理7000多次，同樣這也是我們使用線上比較好的服務器所測試的結果，由于Verify發(fā)生在客戶端，考慮到移動端手機的CPU是非常弱的，因此這里一秒鐘可能只就能處理幾百次。  接下來看協(xié)議耗時的分析，這里用ECDHE_RSA非對稱密鑰交換握手進行舉例，大家注意紅色ServerKeyExchange部分，它用了2400微秒（2.4毫秒），這是一個非?？植赖母拍?，如果我們HTTPS請求每一次都需要進行完全握手處理，這意味著我們CPU一個核每秒最多只能處理400次多一點。  最后我們看熱點事件的分析，它也比較簡單，我們對系統(tǒng)進行壓力測試，用perf record對事件進行記錄，然后使用flame graph將它們可視化出來，最后看到一些相關數據和結果。  總結以上計算性能分析： 完全握手的性能不到普通HTTP性能的10%，如果說HTTP的性能是QPS 1萬，HTTPS可能只有幾百； 為什么會這么低呢？主要是RSA算法，它對性能的影響占了75%左右； ECC橢圓曲線如果使用最常用的ECDHE算法，這部分約占整體計算量的7%； 對稱加解密和MAC計算，它們對性能影響比較小，是微秒級別的。  有了這些分析結論，如何優(yōu)化呢？我們總結了三個步驟： 首先第一步也是最簡單的一個優(yōu)化策略，就是減少完全握手的發(fā)生，因為完全握手它非常消耗時間； 對于不能減少的完全握手，對于必須要發(fā)生的完全握手，對于需要直接消耗CPU進行的握手，我們使用代理計算； 對稱加密的優(yōu)化評論；  簡化握手的原理以及實現 我們首先來看完全握手和簡化握手，這是TLS層的概念，我簡單說下簡化握手的兩個好處： 首先簡化握手相比完全握手要少一個RTT(網絡交互），從完全握手大家可以看出來，它需要兩個握手交互才能進行第三步應用層的傳輸，而簡化握手只需要一個RTT就能進行應用層的數據傳輸； 完全握手有ServerKeyExchange的消息（紅色框部分），這個消息之前提過需要2.4毫秒，另外完全握手有Certificate證書的消息，而簡化握手并不需要。這也就是簡化握手第二個好處，它減少了計算量，它不需要CPU消耗太多時間。 既然簡化握手這么好，我們如何實現？首先看協(xié)議層如何支持。TLS協(xié)議層有兩個策略可以實現，第一個是Session ID，Session ID由服務器生成并返回給客戶端，客戶端再次發(fā)起SSL握手時會攜帶上Session ID，服務端拿到后會從自己的內存查找，如果找到便意味著客戶端之前已經發(fā)生過完全握手，是可以信任的，然后可以直接進行簡化握手。 第二個策略是Session Ticket，同樣它也是客戶端發(fā)起握手時會攜帶上的擴展，服務器拿到Session Ticket后會對它進行解密，如果解密成功了就意味著它是值得信任的，從而可以進行簡化握手，直接傳輸應用層數據。 工程實現上會有什么問題呢？現在最常用的Nginx+OpenSSL有兩個局限： Nginx只支持單機多進程間共享的Session Cache，假如我們所有接入用的是一臺服務器、一臺Nginx的話，那ID生成和查找都在一起，肯定是可以命中的，但是我們大部分特別是流量比較大的接入環(huán)境都是多臺機器接入。比如我們同一個TGW或者說LVS下面有多臺Nginx，那么第一臺Nginx產生的ID返回給用戶，用戶可能隔了一個小時候之后再發(fā)起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環(huán)境下切換導致的IP變化同樣會使Session Cache的命中率降低。 2、分布式緩存（分布式Session Cache），這是更優(yōu)的方案，假如用戶開始發(fā)起握手，我們第一臺Nginx生成ID會寫入到一個全局的比如redis緩存里，然后返回給用戶。用戶下一次發(fā)起握手的時候，假如他落到第三臺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、瀏覽器或操作系統(tǒng)如果第一次啟動或重啟（或者瀏覽器的Tab關閉后又打開）都有可能導致Session ID和Session Ticket丟失，出于安全角度考慮，這情況下就必須要發(fā)起完全握手，怎么解決呢？ 如果這個App是我們完全自主、獨立自主開發(fā)，我們可以實現Self Session Ticket，我們將Ticket存儲在硬盤里面，而不是在內存里。這顯然會帶來一定的安全風險，但是我們會做一些限制： Ticket存儲在App的私有路徑里，對非Root的手機是很難讀取到私有路徑的數據； 我們可以選擇對一些安全系數要求不是很高的業(yè)務開啟這個功能； 這個密鑰開關我們做到可以隨時控制。 綜上，即使這方案出現最危險的情況，其實是和HTTP方案是一樣的，它不會比HTTP方案安全性要差。 異步代理計算的原理和實現 剛才提到的都是關于如何減少完全握手，提升簡化握手，但對很多的請求，比如說瀏覽器第一次啟動必須要經過完全握手，而且不是我們能夠自主控制的。對于這部分的內容，完全握手比例占了至少30%以上，也就是說我們還有30%以上的請求必須要觸發(fā)CPU進行大量計算，對這部分怎么解決呢？ 我們的方案是異步代理計算，主要是分三個步驟： 算法分離，把最消耗CPU資源的算法剝離出來，不讓它消耗本機的CPU資源； 代理計算，既然不消耗本機的CPU資源，我們可以使用硬件加速卡或者空閑的CPU資源來完成計算； 異步執(zhí)行，我把算法分離出來交給計算集群去計算的時候，這個過程是異步的，我不需要同步等待計算結果返回，這樣對我們性能提升也是非常有幫助的。 算法分離 要分離哪些算法？最主要是密鑰交換算法（非對稱密鑰交換算法），密鑰交換算法最常用的是三類： RSA ECDHE_RSA DHE_RSA 由于DHE_RSA是非常消耗性能的，這個方法也不安全，所以我們線上并沒有采用。目前使用最多的是ECDHE_RSA，考慮到兼容性的問題時使用了RSA。 RSA和ECDHE_RSA為什么會消耗CPU資源？RSA主要是對客戶端發(fā)回來的pre_master_secret進行解密，它消耗CPU資源的過程是私鑰解密的計算；而ECDHE_RSA則有兩個步驟： 生成ECC橢圓曲線的公鑰和幾個重要的參數； 對這幾個參數進行簽名，客戶端要確保參數是我服務端發(fā)過來的，就是通過RSA的簽名來保證。 RSA簽名為什么消耗CPU呢？RSA簽名同樣有兩個步驟： 首先它通過SHA1進行Hash計算； 對Hash結果進行私鑰加密，也就是最終消耗CPU的過程是私鑰解密和私鑰加密的計算。這兩個計算為什么消耗CPU？看下圖公式，如果e或者d這個指數是一個接近2的2048次方的天文數字，那就非常消耗CPU。這也就是RSA算法為什么消耗CPU的最直接的數學解釋。 我們再看一下協(xié)議層面我們該如何實現分離。同樣以ECDHE_RSA為例，由于使用了ECC參數和RSA簽名，之前提到的ServerKeyExchange這個消息用了2.4毫秒，我們需要對這個消息進行分離，將一步操作拆成多個步驟。 我們再看一下RSA密鑰交換的分離，RSA非對稱密鑰交換算法不需要ServerKeyExchange的消息，但需要對Client發(fā)過來的ClientKeyExchange進行解密的操作，也就是最消耗算法的過程是RSA解密的地方，我們需要對這個步驟進行分離。 異步代理計算——架構 以上是算法層面包括協(xié)議層面進行的分離。接下來解釋工程實現上的架構，下圖左部分是最常用最簡單的配置，比如我們配置好Nginx+OpenSSL，然后把證書和私鑰放上去，把443端口打開，就能用上HTTPS了，但這里消耗的都是本機的CPU資源，這里面就會性能很差。 我們看異步硬件加速卡代理計算的模型，用戶發(fā)起HTTPS握手，涉及到私鑰計算（比如ServerKeyExchange和對ClientKeyExchange解密）的時候，我們會把ECC的參數剝離出來發(fā)送給我們的計算集群，發(fā)送出去同時立馬異步返回，又可以接受其他用戶的請求，不需要等待。 計算集群計算完了以后，我們會把計算結果返回給比如Nginx，Nginx又觸發(fā)最初的用戶場景，從而完成HTTPS的握手，這是一個大概的交互流程。 這里面需要注意的是，我們不僅僅可以使用SSL硬件加速卡，還可以使用線上的空閑CPU資源，比如CPU比較空閑的存儲集群，如果硬件加速卡出現故障，我們可以直接把卡拔掉，可以用硬件加速卡集群上的CPU資源來做計算。我們對算法的解耦是非常純粹的，和協(xié)議、證書沒有任何關系，我們只做RSA的計算，不管哪一邊進行升級，只要RSA算法還是安全的，我們的協(xié)議就十分穩(wěn)定，我們的維護成本也非常低。 異步代理計算——工程實現 我們看一下工程實現，像Nginx需要事件框架進行修改來實現OpenSSL Nginx計算集群交互，通過模塊是無法實現的，盡管Nginx模塊機制非常強大豐富，但是它在HTTP頭部數據解析完成之后才能介入處理，但SSL握手只有進行SSL握手完之后才能進行應用層的數據傳輸，也就是說在進行SSL握手的時候，它沒有任何HTTP的數據，這時候模塊是沒辦法介入處理的，必須對事件框架進行修改。 關于OpenSSL，需要對OpenSSL的協(xié)議棧進行修改，主要涉及到s3_srvr.c這個文件，這個文件主要是實現OpenSSL握手的協(xié)議棧，這里介紹一個開源方案：OpenSSL1.1.0，它已經支持了異步事件，同樣還是需要修改Nginx才能實現異步。性能也很強大，純ECDHE_RSA性能相比本機能夠提升3.5倍，而且解耦做得非常好。 ECC橢圓曲線的優(yōu)化 剛才提到的一系列都是針對完全握手、簡化握手的介紹。接下來看對ECC橢圓曲線的優(yōu)化，這里說的優(yōu)化不是針對算法本身進行的優(yōu)化，而是使用OpenSSL的官方版本過程中需要注意的地方。 盡量使用NIST P-256這條曲線，這條曲線是Intel幾個工程師在2013年進行的優(yōu)化，性能提升了4倍。通常來講密鑰越大，性能肯定越差，比如RSA-2048肯定比1024要慢4倍左右，P-256曲線看上去應該比P-224要慢，但是實際上P-256曲線比P-224性能高了4倍，正是因為經過了一系列的優(yōu)化。 另外需要注意的是OpenSSL的版本，這個優(yōu)化特性只是在1.0.1L之后才加入的，下圖表格中OpenSSL的1.0.1e版本ecdh(nistp256)的性能只有2548，而OpenSSL的1.1.0b版本ecdh(nistp256)性能能達到10271，提高了4倍。 對稱加密算法的優(yōu)化 我們再看一下對稱加密算法的優(yōu)化，對稱加密主要分兩塊： 1、塊式對稱加密算法，根據剛才OpenSpeed跑的結果也能發(fā)現AES-GCM性能最高，建議大家使用。AES-NI同樣是Intel CPU提供的硬件加速指令，這個指令相比不開啟的CPU性能要提升5倍左右，現在市面上2010年之后的Intel CPU都是支持的，但需要注意如果要直接使用AES對稱加解密，一定要使用OpenSSL封裝的EVP_EncryptInit_ex函數，而不是用最底層的AES_encrypt（盡管它很好記也很好用），默認的AES_encrypt函數是不會用硬件加速指令的，因此性能會很差； 2、流式對稱加密算法。Chacha20-Poly1305是由Google專門針對移動端CPU優(yōu)化的流式對稱加密算法，它的性能相比普通算法要提高3倍。但Chacha20算法只適用于稍微低端、且不支持AES-NI指令的手機才能提高3倍，舉個例子，例如iPhone支持AES-NI，但它的性能還是會比AES-GCM要差的。 RC4、SSL3.0已經不安全了，也徹底退出了歷史舞臺，但我們還有很多客戶端只支持SSL3.0，比如IE6，比如WindowsXP的一些客戶端和瀏覽器，我們的業(yè)務方仍需要支持這些業(yè)務，因此我們就必須支持SSL3.0，那如何支持呢？ 首先SSL3.0為什么不安全？主要是兩點： SSL3.0存在AES-CBC的緩存Poodle漏洞； RC4存在Bios偏移的漏洞； 這兩個漏洞哪個更嚴重？Poodle漏洞會更嚴重一些，于是開啟SSL3.0的話我們只支持RC4，這是第一點安全性的考慮，其次RC4的算法性能要比AES-CBC要高，比如業(yè)務方一定要支持WindowsXP和IE6的話，優(yōu)先使用RC4。 無密鑰加載 我們再看無密鑰加載，無密鑰加載的背景是這樣的，HTTPS證書和私鑰，私鑰是HTTPS安全的根本，如果私鑰被泄露了，那么意味著你的HTTPS是沒有安全性可言，如果泄露了，只能撤銷證書，重新生成私鑰。 而且我們大部分使用HTTPS的場景都是將私鑰和證書同機部署在比如Nginx上面，然后私鑰保存在硬盤，這其實有安全風險的。比如說我們有很多兼容的大客戶，他使用了證書和私鑰，但是他的業(yè)務可能分散在幾個云，或者幾個CDN上，他就會擔心私鑰如果泄露了怎么辦？ 我們因此設計了一個無密鑰加載的方案，我們先看普通的HTTPS流程，用戶發(fā)起HTTPS，到達騰訊云，到達STGW，我們直接調用私鑰完成計算，完成HTTPS的握手，然后卸載，然后將HTTPS傳遞給業(yè)務。這是最普通的流程，會有一定的安全風險。 再看一下無密鑰加載流程，什么是無密鑰呢？比如騰訊云，我們接收的服務器不需要部署私鑰，我們私鑰是完全放在客戶的物理服務器上面，為了保證私鑰的安全，客戶甚至可以把這個物理服務器放在家里。 正常的接收流程是這樣的，我們用戶到達HTTPS握手，到達STGW，然后涉及到私鑰計算的時候，我們會把請求以及和私鑰相關的參數，封裝成一個異步請求發(fā)給騰訊云客戶的物理服務器，然后物理服務器會調用私鑰進行相關計算，再把計算結果返回給騰訊云服務器，完成HTTPS卸載。 整個交互流程中，STGW或者說騰訊云和私鑰沒有任何的接觸，私鑰是客戶自己才擁有。這就是我們無密鑰加載的一個簡單的介紹。當然具體的流程或者實現，其實跟我剛才提到的異步代理計算有點類似，包括協(xié)議方面。 證書優(yōu)化 接下來看證書的優(yōu)化。如果是個人用戶，向大家推薦Let's Encrypt，它是免費開源的CA證書頒發(fā)機構，它的優(yōu)點就是免費開源，開源最大的好處就是可以對協(xié)議對整個交互流程都很清楚，支持Debug。它還有一個優(yōu)點是能支持自動部署，它提供幾個工具運行幾分鐘就可以把證書申請下來。 但它也有缺點，第一，它只是低級別即域名級別的證書申請，它只對域名的有效性進行校驗，你能擁有這個域名就可以給你頒發(fā)證書，這就有安全風險了，假如我對域名進行劫持，我就可以冒名申請別人的證書。 另外兼容性也會比較差，像PC端Chrome訪問沒有任何問題，但我們用Android7.0去訪問就有可能出現問題，因為CA支持和更新并不及時，因此就有兼容性的風險，所以推薦個人用戶使用。 對于企業(yè)用戶，建議大家使用EV和OV級別的，因為它會需要你證書的機構、你的地址、法人信息、營業(yè)執(zhí)照、在工商局的認證等信息，才確保只有你才能申請這個證書。 這是云的優(yōu)勢，申請很簡單，一鍵式申請，不需要你自己生成私鑰，也不需要生成證書的申請文件。這是騰訊云證書簡單的說明。我們還有一個動作，在跟最大的證書廠商進行合作接觸，我們會實現自己更低成本的自主品牌證書的頒發(fā)，這樣的話證書會更加便宜，下圖是騰訊云上面的介紹。 我們看一下證書簽名的選擇，我們最后使用了RSA，還使用ECDSA，這兩個是最主流最常用的簽名類型。 RSA的好處是兼容性好、歷史悠久，所有的客戶端都支持，因為它算法已經存在40年了，缺點就是之前提到的代理計算，RSA需要私鑰進行計算，服務端需要加密解密性能會比較差。 ECDSA，優(yōu)點就是服務端的性能好一點，P-256只需要256位的輸出域就能實現和2048位長度同樣的安全性，它的安全性更高，服務端計算性能要好，但是客戶端的性能要差。使用ECDSA P-256客戶端的計算量要比RSA要大，RSA的公鑰的數字非常小，只有65537，而ECDSA的客戶端公鑰長度很大，計算性要差很多，特別是手機計算性能要弱。 ECDSA的缺點就是兼容性差，比如說WindowsXP不支持。具體可以看下圖的系統(tǒng)支持情況，這里面其實由于RSA和ECDSA這兩個完全不同類型的證書，服務端其實可以同時支持，當然成本可能會稍微增加一些。目前使用ECDSA的還是多一些的。 最后看一下SHA1和SHA256，SHA1不安全，像Google和Microsoft已經宣布放棄SHA1，如果你使用SHA1證書就訪問不了。 SHA2兼容性比較差，比如WindowsXP不支持SHA2證書，但對于需要支持WindowsXP的業(yè)務來說如何兼容呢？我們觀察到一個特性：不支持SNI的客戶端也不支持SHA2。 SNI是TLS的一個特性和擴展，發(fā)起client hello的時候，它會攜帶上一個域名的信息，在握手的時候告訴服務端要訪問哪一個域名（Server Name Indicator），雖然從協(xié)議或者從原理的角度來講沒有任何的必然的關系，但這個現象給我們一個啟發(fā)：我們通過服務端配置能夠解決這個兼容性的問題。 同樣以Nginx和OpenSSL舉例，假如說客戶端1不支持SNI，只支持SHA1，客戶端2是新的系統(tǒng)支持SNI。我們配置配兩張證書，第一張證書我們同樣都是接403端口和兩個不同的Server，證書1放在前面，證書2支持SHA2放在后面。 當客戶端1發(fā)起請求的時候，由于它不支持SNI，所以默認會返回第一張證書（第一張證書是支持SHA1的），這樣不支持SNI也不支持SHA2的客戶端1兼容性沒有問題。 客戶端2發(fā)起請求的時候，攜帶了SNI，由于有SNI和域名信息，服務端會挑選有域名的信息SHA2返回給客戶端，實現SHA2的兼容。 最后是我對于HTTPS發(fā)展的簡單的概括和理解： 更廣。它會越來越流行，以后會成為互聯(lián)網的標配。HTTP2作為下一代的協(xié)議，主流實現像Chrome\FireFox都是強制使用HTTPS的。ATS也強制使用HTTPS，Chrome2017年也會將HTTP標識為不安全； 更快。這里涉及到訪問速度的優(yōu)化，TLS1.3是革命性飛躍式的TLS協(xié)議，可以認為是TLS2.0，它相比1.2有非常大的變化，最大的變化有完全握手，它只需要一個RTT，而簡化握手不需要RTT，也就是應用層數據不需要握手直接可以完成數據的傳輸，另外QUIC解決HTTPS協(xié)議的性能問題，TLS協(xié)議以后也會越來越快，大家不用擔心訪問速度的問題； 更強。密鑰長度越來越大，加密強度會越來越強，隨著客戶端和硬件的發(fā)展，CPU加解密的性能也會越來越強； 更開放。之前提到類似Let's Encrypt的免費開源方案，以后也會成為越來越流行的方案。 以上是HTTPS的性能優(yōu)化，謝謝大家！ 作者介紹 羅成，騰訊資深研發(fā)工程師。目前主要負責騰訊stgw(騰訊安全云網關）的相關工作，整體推進騰訊內部及騰訊公有云，混合云的七層負載均衡及全站HTTPS接入。對HTTPS，SPDY，HTTP2，QUIC等應用層協(xié)議、高性能服務器技術、云網絡技術、用戶訪問速度、分布式文件傳輸等有較深的理解。 這是一發(fā)彩蛋 每年 InfoQ 都會舉辦 2 場屬于架構師們的技術盛會——ArchSummit 全球架構師峰會，一場在深圳，一場在北京。秉承著實踐第一，案例為主的原則，ArchSummit 旨在展示新技術在行業(yè)應用中的最新實踐，技術在企業(yè)轉型中的加速作用，幫助企業(yè)技術管理者、CTO、架構師做好技術選型、技術團隊組建與管理，并確立技術對于產品和業(yè)務的關鍵作用。 如你所看到的，這篇誠意滿滿的干貨文章只是大會眾多專題中的一個演講，還有更多分量不輸此次演講的專題等著你親臨現場?，F在是AS 7折購票期，期間購票立減2040。更多專題、講師信息，都可以去官網了解詳情：http://sz2017./ |
|
|
