HTTPS 要比 HTTP 多用多少伺服器資源？

11-16

一些國際網站，比如維基百科，在啟用https前先會考慮自己計算能力是否可以承載https。請問，https要比http多用多少伺服器資源？

https其實就是建構在SSL/TLS之上的 http協議，所以要比較https比http多用多少伺服器資源，主要看SSL/TLS本身消耗多少伺服器資源。

http使用TCP 三次握手建立連接，客戶端和伺服器需要交換3個包，https除了 TCP 的三個包，還要加上 ssl握手需要的9個包，所以一共是12個包。http 建立連接，按照下面鏈接中針對Computer Science House的測試，是114毫秒；https建立連接，耗費436毫秒。ssl 部分花費322毫秒，包括網路延時和ssl 本身加解密的開銷（伺服器根據客戶端的信息確定是否需要生成新的主密鑰；伺服器回復該主密鑰，並返回給客戶端一個用主密鑰認證的信息；伺服器向客戶端請求數字簽名和公開密鑰）。
SSL handshake latency and HTTPS optimizations. :: semicomplete.com
當SSL 連接建立後，之後的加密方式就變成了3DES等對於 CPU 負荷較輕的對稱加密方式。相對前面 SSL 建立連接時的非對稱加密方式，對稱加密方式對 CPU 的負荷基本可以忽略不記，所以問題就來了，如果頻繁的重建 ssl 的session，對於伺服器性能的影響將會是致命的，儘管打開https 保活可以緩解單個連接的性能問題，但是對於並發訪問用戶數極多的大型網站，基於負荷分擔的獨立的SSL termination proxy就顯得必不可少了，Web 服務放在SSL termination proxy之後。SSL termination proxy既可以是基於硬體的，譬如F5；也可以是基於軟體的，譬如維基百科用到的就是 Nginx。

那採用 https 後，到底會多用多少伺服器資源，2010年1月 Gmail切換到完全使用 https，前端處理 SSL 機器的CPU 負荷增加不超過1%，每個連接的內存消耗少於20KB，網路流量增加少於2%。由於 Gmail 應該是使用N台伺服器分散式處理，所以CPU 負荷的數據並不具有太多的參考意義，每個連接內存消耗和網路流量數據有參考意義。這篇文章中還列出了單核每秒大概處理1500次握手（針對1024-bit 的 RSA），這個數據很有參考意義，具體信息來源的英文網址：ImperialViolet。

Heartbleed這個被稱作史上最大的網路安全漏洞，想必很多人都有所耳聞，Heartbleed之所以能夠出現，其實和我們這個問題關係還不小，前面我們談到了頻繁重建 SSL/TLS的session對於伺服器影響是致命的，所以聰明的RFC 在2012年提出了 RFC6520 TLS 的心跳擴展。這個協議本身是簡單和完美的，通過在客戶端和伺服器之間來回發送心跳的請求和應答，保活 TLS session，減少重建 TLS的session的性能開銷。令人遺憾的是，openssl 在實現這個心跳擴展時，犯了一個低級的錯誤，沒有對收到的心跳請求進行長度檢查，直接根據心跳請求長度拷貝數據區，導致簡單的心跳應答中可能包含了伺服器端的核心數據區內容，用戶名，密碼，信用卡信息，甚至伺服器的私有密鑰都有可能泄露。心因為心跳保活的這個 BUG 在滴血，這個名字起的極度形象。

下面開始講一個無聊的故事，和問題關係不大，時間緊張的看官可以到此為止了。

從前山上有座廟，廟裡有個和尚......，別胡鬧了，老和尚來了。

小和尚問老和尚：ssl為什麼會讓http安全？

老和尚答道：譬如你我都有一個同樣的密碼，我發信給你時用這個密碼加密，你收到我發的信，用這個密碼解密，就能知道我信的內容，其他的閑雜人等，就算偷偷拿到了信，由於不知道這個密碼，也只能望信興嘆，這個密碼就叫做對稱密碼。ssl使用對稱密碼對http內容進行加解密，所以讓http安全了，常用的加解密演算法主要有3DES和AES等。

小和尚摸摸腦袋問老和尚：師傅，如果我們兩人選擇「和尚」作為密碼，再創造一個和尚演算法，我們倆之間的通信不就高枕無憂了？

老和尚當頭給了小和尚一戒尺：那我要給山下的小花寫情書，還得用「和尚」這個密碼不成？想了想又給了小和尚一戒尺：雖然我們是和尚，不是碼農，也不能自己造輪子，當初一堆牛人碼農造出了Wifi的安全演算法WEP，後來發現是一繡花枕頭，在安全界傳為笑談；況且小花只知道3DES和AES，哪知道和尚演算法？

小和尚問到：那師傅何解？

老和尚：我和小花只要知道每封信的密碼，就可以讀到對方加密的信件，關鍵是我們互相之間怎麼知道這個對稱密碼。你說，我要是將密碼寫封信給她，信被別人偷了，那大家不都知道我們的密碼了，也就能夠讀懂我們情書了。不過還是有解的，這裡我用到了江湖中秘傳的非對稱密碼。我現在手頭有兩個密碼，一個叫「公鑰」，一個叫「私鑰」，公鑰發布到了江湖上，好多人都知道，私鑰嘛，江湖上只有我一個人知道；這兩個密鑰有數學相關性，就是說用公鑰加密的信件，可以用私鑰解開，但是用公鑰卻解不開。公鑰小花是知道的，她每次給我寫信，都要我的公鑰加密她的對稱密碼，單獨寫一張密碼紙，然後用她的對稱密碼加密她的信件，這樣我用我的私鑰可以解出這個對稱密碼，再用這個對稱密碼來解密她的信件。

老和尚頓了頓：可惜她用的對稱密碼老是「和尚為什麼寫情書」這一類，所以我每次解開密碼紙時總是悵然若失，其實我鐘意的對稱密碼是諸如「風花」「雪月」什麼的，最頭痛的是，我還不得不用「和尚為什麼寫情書」這個密碼來加密我給小花回的情書，人世間最痛苦的事莫過於如此。可我哪裡知道，其實有人比我更痛苦。山下的張屠夫，暗戀小花很多年，看著我們鴻雁傳書，心中很不是滋味，主動毛遂自薦代替香客給我們送信。在他第一次給小花送信時，就給了小花他自己的公鑰，謊稱是我公鑰剛剛更新了，小花信以為真，之後的信件對稱密碼都用張屠夫的這個公鑰加密了，張屠夫拿到回信後，用他自己的私鑰解開了小花的對稱密碼，然後用這個對稱密碼，不僅能夠看到了小花信件的所有內容，還能使用這個密碼偽造小花給我寫信，同時還能用他的私鑰加密給小花的信件。漸漸我發現信件變味了，儘管心生疑惑，但是沒有確切的證據，一次我寫信問小花第一次使用的對稱密碼，回信中「和尚為什麼寫情書」赫然在列，於是我的疑惑稍稍減輕。直到有一次去拜會嵩山少林寺老方丈才頓悟，原來由於我的公鑰沒有火印，任何人都可以偽造一份公鑰宣稱是我的，這樣這個人即能讀到別人寫給我的信，也能偽造別人給我寫信，同樣也能讀到我的回信，也能偽造我給別人的回信，這種邪門武功江湖上稱之「Man-in-the-middle attack」。唯一的破解就是使用嵩山少林寺的火印，這個火印可有講究了，需要將我的公鑰及個人在江湖地位提交給18羅漢委員會，他們會根據我的這些信息使用委員會私鑰進行數字簽名，簽名的信息凸現在火印上，有火印的公鑰真實性在江湖上無人質疑，要知道18羅漢可是無人敢得罪的。

小和尚問：那然後呢？

老和尚：從嵩山少林寺回山上寺廟時，我將有火印的公鑰親自給小花送去，可是之後再也沒有收到小花的來信。過了一年才知道，其實小花還是給我寫過信的，當時信確實是用有火印的公鑰加密，張屠夫拿到信後，由於不知道我的私鑰，解不開小花的密碼信，所以一怒之下將信件全部燒毀了。也由於張屠夫無法知道小花的對稱密碼而無法回信，小花發出幾封信後石沉大海，也心生疑惑，到處打聽我的近況。這下張屠夫急了，他使用我發布的公鑰，仿照小花的語氣，給我發來一封信。拿到信時我就覺得奇怪，信紙上怎麼有一股豬油的味道，結尾竟然還關切的詢問我的私鑰。情知有詐，我思量無論如何要找到辦法讓我知道來的信是否真是小花所寫。後來竟然讓我想到了辦法....

老和尚摸著光頭說：這頭髮可不是白掉的，我托香客給小花帶話，我一切安好，希望她也擁有屬於自己的一段幸福，不對，是一對非對稱密鑰。小花委託小鎮美女協會給小花公鑰打上火印後，托香客給我送來，這樣小花在每次給我寫信時，都會在密碼紙上貼上一朵小牡丹，牡丹上寫上用她自己的私鑰加密過的給我的留言，這樣我收到自稱是小花的信後，我會先抽出密碼紙，取下小牡丹，使用小花的公鑰解密這段留言，如果解不出來，我會直接將整封信連同密碼紙一起扔掉，因為這封信一定不是小花寫的，如果能夠解出來，這封信才能確信來之於小花，我才仔細的解碼閱讀。

小和尚：難怪聽說張屠夫是被活活氣死的。您這情書整的，我頭都大了，我長大後，有想法直接扯著嗓子對山下喊，也省的這麼些麻煩。不過我倒是明白了樓上的話，ssl 握手階段，就是要解決什麼看火印，讀牡丹，解密碼紙，確實夠麻煩的，所以性能瓶頸在這裡，一旦雙方都知道了對稱密碼，之後就是行雲流水的解碼讀信階段了，相對輕鬆很多。

開啟 SSL 會增加內存、CPU、網路帶寬的開銷，後二者跟你使用的 cipher suite 密切相關，其中參數很多，很難一概而論。開啟 SSL 的前提是你的 cert 和 key 必須放在 TCP endpoint，你是否信得過那台設備？

SSL 開銷來自於兩部分，handshake 和 bulk encryption。對於性能，前者我們關注 handshakes/s，後者關注 MiB/s。

先說比較簡單的 bulk encryption，首先由於 padding 和 MAC，消息會變長，增加一些網路帶寬。其次，bulk encryption 和 MAC 會增加 CPU 使用，具體跟所使用的加密演算法和 MAC 演算法有關，如果用 AES，也跟 CPU 是否支持 AESNI 指令有關。如果用常見的 AES-256-CBC + SHA1 組合，單個 CPU core 就能輕鬆打滿千兆網帶寬。（AES128 vs. AES256 和 SHA1 vs. SHA256 還有細微差別，但透過千兆網就不一定能看出來了，不過 3DES 要慢得多。）另外，如果用 GCM 代替 CBC，會節約一些帶寬（省了 MAC），但會增加 CPU 開銷。測試 bulk encryption 的性能是比較容易的。

再說 handshake，這裡邊水比較深。開銷主要取決於 key exchange 演算法。這裡暫且只考慮流行的 2048 bit RSA key，不考慮新潮的 ECDSA。
首先，你要決定是否採用 forward secrecy，即如果有人錄下你今天的 traffic，將來再搞到了你的 private key，他是否能追溯解密以往的消息。這決定了是 RSA key exchange 還是 ECDHE RSA key exchange。（這裡就不考慮慢得多的 DHE key exchange 了。）

單從性能方面考慮，RSA key exchange 比 ECDHE RSA key exchange 快。大體上一秒鐘能做幾百上千次 handshake，比 TCP 三路握手慢很多。如果你用 ECDHE，注意選 secp256r1/secp224r1 等曲線，而不是更慢的 secp521r1。還有，對於 ECDHE，「每次 handshake 用新的 key （SSL_OP_SINGLE_ECDH_USE）」與「進程啟動時產生一個 key 反覆使用」也會有細微的性能差別。如果你要貼 benchmark 的對比結果，一定要把各個參數細節指明，否則沒有參考意義。

ECDHE RSA key exchange 比 RSA key exchange 的總運算量大，但分配在服務端和客戶端的比例不及後者懸殊。RSA key exchange 中，拋開 cert 驗證，客戶端耗CPU的操作是 RSA public key encrypt，而服務端需要做 RSA private key decrypt，後者要慢幾倍。ECDHE RSA key exchange 中，客戶端和服務端都要做 EC key generation 和 scalar multiplication，運算量相當，區別在於服務端還要做 RSA sign with private key，客戶端只要 RSA verify with public key，總體來看，服務端的運算量略大。也就是說兩種 key exchange 策略 handshake 產生的 CPU 負載在服務端和客戶端的分配比例差別較大。

總之，你需要找一位安全顧問，不然一個輕微的配置失誤也許就葬送了增強安全的全部努力。我不是專家，以上文字算是我的筆記吧。《Everything you need to know about cryptography in 1 hour》 https://www.bsdcan.org/2010/schedule/attachments/135_crypto1hr.pdf

我來說說小米是怎麼做的：
正常情況下一個16core的伺服器機器能夠撐死3000QPS.
後來我們使用了ssl的加速卡，這種卡在國外買回來也就5千快，性能到15kQPS沒有問題，據說還有優化的空間。但是我們太忙。沒有時間改nginx的module.
還可以使用GPU的並行計算來做，但是這個現在還沒有成熟的解決方案，我們的代碼不夠成熟，沒有敢放在線上來使用。

另外，我的經驗是https最主要的問題是，沒有辦法使用CDN，網站的證書又需要非常小心的保護，所有的請求都要回到主站，靜態資源會導致帶寬出現問題。所以需要仔細優化你的流量。

關於HTTPS，圖靈教育剛剛出版了一本新書《HTTPS權威指南：在伺服器和Web應用上部署SSL/TLS和PKI》，講解很細緻：圖靈社區 : 圖書 : HTTPS權威指南：在伺服器和Web應用上部署SSL/TLS和PKI

如果是iOS App開發者，需要注意這個問題，蘋果17年1月開始強制要求HTTPS

作者：沙銘
鏈接：知乎專欄
來源：知乎
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。

App上架重磅通知：蘋果安全新規17年1月生效

也許很多人並不了解什麼是ATS（App Transport Security），但是對於App開發者，這卻是一個定時炸彈，引爆點在2016年底，後果就是你不注意，可能就會導致產品無法在App Store上架，雖然沒有違規操作下架那麼嚴重，但結果同樣致命。現在還有2個月的緩衝期，但還有很多開發者沒有想到這一點，有必要給大家提個醒。

ATS是在2015年由蘋果引入的強化網路傳輸安全的標準，要求所有的App在從Web端獲取數據的時候都要使用安全的HTTPS鏈接，並進一步強調要使用最新的TLS1.2版本的HTTPS。

註：可以從網址前綴http://或者https://來區別兩種標準

蘋果也清楚還有大量的Web內容仍舊在使用不安全的HTTP鏈接，因此定義了ATS開關選項的集合（Dictionary），允許大家通過info.plist文件設置（如下圖所示），不過我估計99.9%的開發者會選擇先打開允許任意鏈接的選項，然後大部分人過段時間就忘了這回事，好像什麼事都沒有發生過。

現在是醒過來面對現實的時候了，蘋果在WWDC時已經透漏，強制使用ATS的大限是今年底，也就是說，從17年開始蘋果審核團隊會將ATS作為強制審核項，以蘋果的脾氣，可能會硬來，反正已經給了一年多的緩衝期了！

到時一刀切怎麼辦？作為開發者應該如何處理？我們今天就來詳聊下這個問題！

首先，我們還是要了解具體的政策，然後在此基礎上做出合理的猜測，這樣每家根據自己的具體情況評估之後就知道該怎麼做了。然而無論如何，大的原則是要快速做出反應，不要存有僥倖心理！

當然，HTTPS是大勢所趨，蘋果強制執行ATS也是本著對用戶負責的態度，無可厚非。在執行的尺度上，我認為蘋果也會靈活的評估，肯定有一些"I will know it when I see it"的模糊情況，想必App Store的老司機都心領神會。
雖然說17年ATS會成為強制標準，但是這裡面還是分為幾種不同的情況的，為了幫助大家理解，沙銘從推廣和開發兩個角度去說

推廣角度

第一
App的內容來源如果有自家網站，去和技術核對一下是使用哪種傳輸標準，如果仍然使用HTTP或者是低於TLS1.2的HTTPS，要不就趕緊整改，要不就準備和蘋果審核磨，準備好申請特例的充分理由。在我的星座蘋果系列中有兩篇文章《善變雙子，難言的苦衷：史上最強審核團隊起底，掩藏的秘密》和《悶瓜金牛，本應昭告天下卻緘默：開發者賬號，審核加速揭秘》，了解應該如何跟審核團隊打交道，以及開發者賬號在審核過程中的作用，還是非常必要的。

第二
App的內容如果有來自已知的第三方，可以暫時不用管，讓技術設置一下ATS的開關（下文中會涉及），不過最好的做法是和第三方溝通下，敦促他們所有的傳輸都使用TLS1.2加密。

第三
App的內容來自於不可知的第三方，比如說允許用戶通過App訪問任意網站，可以忽視ATS，不過來自於自有網站的內容還是必須遵循第一條。同時詢問技術使用的是何種框架，如果是WebKit，建議切換到Safari，否則今後可能還會有麻煩事。

第四
如果是提供流媒體內容的App，不想服從於ATS，就必須在源頭進行流媒體加密，並且使用蘋果的流媒體框架，就可以暫時無視ATS。
因此，大家可以根據自己的情況來決定是採用哪種對策，當然上策是盡量使用TLS1.2的HTTPS安全標準，實在不行就要多想想如何跟蘋果解釋，以爭取特例！
不過有個問題目前還不是特別明朗：對於那些不達標準的已上架App如何處理？我個人不太相信App會因為這個原因被下架，蘋果最可能的做法是等到App迭代時拒絕上架。這時可能又有人會想了：那我就不更新！呵呵，也許也是一種辦法。總而言之，新一輪的貓捉老鼠遊戲又要開始了。

開發角度

第一
ATS設置中打開了以下開關，又沒有提交合理的解釋，那麼會100%被拒
NSAllowsArbitraryLoads，打開此開關相當於關閉ATS

NSExceptionAllowsInsecureHTTPLoads，使用自有網站的HTTP鏈接

NSExceptionMinimumTLSVersion，使用自有網站低於TLS1.2標準的HTTPS鏈接

至於什麼是合理的解釋，這個就完全是一個主觀判斷的過程了，也許有的人覺得自己的理由很充分，但是如果不能夠說服蘋果審核，你的App就是上不了線，這考驗團隊的溝通技巧和英文水平！

第二
以下幾種情況蘋果給予特例，不需要提供解釋：
App提供流媒體服務，媒體源已經對內容進行了加密，這時只要使用蘋果的AV Foundation框架載入內容，就可以無視ATS；

不使用Forward Secrecy（完全前向保密）技術，可以在ATS設置中關閉NSExceptionRequiresForwardSecrecy開關（預設是打開）；

NSThirdPartyException，使用第三方鏈接，而這裡面又包括使用第三方HTTP鏈接或者是低於TLS1.2版本的HTTPS等幾個開關。

估計有人會想，那我把自己的網站偽裝成第三方網站，使用這個特例不就好了，Bingo！如果你能經得起被拒甚至更重的懲罰，也許可以試試，不過有理由相信蘋果有多種方法判斷關聯網站，承受不起風險者勿試。

第三
ATS設置中還有個開關NSAllowsArbitraryLoadsInWebContent，打開後允許使用任意Web鏈接，這個和NSAllowsArbitraryLoads有些區別，主要是針對那些提供類似於Web瀏覽器服務的App，由於事先不知道用戶會瀏覽哪些網站，因此無法限制鏈接類型。

不過蘋果建議如果要提供瀏覽器類的服務，請使用SFSafariViewController，優於WKWebView，後者更適用於對用戶訪問web內容更有把控的情況。
關於ATS的詳細設置，開發可以參考蘋果官方文檔。

此外，蘋果還建議放棄以下較老的標準

RC4
SSLv3
SHA-1
3DES

並向最新的安全標準遷移，包括

Forward SecrecySHA-2
OCSP Stapling

蘋果對用戶隱私的關注度極高，以上的政策會隨時調整，如果想及時了解蘋果生態的最新動向，歡迎關注我的公眾號「沙銘世界觀」，網站精品課程：App推廣實戰技能（含ASO），沙銘又一力作

我是沙銘，OOPSING諮詢創始人，推廣圈裡最懂編程，碼農圈裡最懂推廣的蘋果專家，著有《星座蘋果》系列連載及《App運營推廣實戰（含ASO）》在線課程。

嗯，吐個槽求摺疊：算上進出{不宜公開討論的政治內容}開銷的話，其實是少用資源啊哈哈…不走VPN等梯子的話看前級策略，要麼放行要麼直接拒掉

對於近年來的硬體來說，SSL加密帶來的開銷微乎其微。國內網站很少使用的其中最大問題是完全符合SSL要求的頁面資源沒法像HTTP的那樣很方便地做資源分散式緩衝。可以參考：為什麼更安全的 HTTPS 協議沒有在互聯網上全面採用？

所以，對維基百科來說，開啟https的成本，僅僅是購買這個證書的費用而已。

加密解密很耗時的，佔用的是CPU

我看了我的主機後台，也沒有費什麼資源呀，和原來的差不多。CPU和內存都一般。所以硬體開銷並不大。

以前怕加密壓力，把員工活動照片專門改用非加密的埠。
如果只是連接時慢10倍，內容傳輸時差不多，看來照片也採用https，問題也不大。

有專用的SSL解密卡的，為了減輕CPU的負擔而生，在網路層的時候完成解密。

HTTP訪問，用戶只需要完成TCP三次握手，建立TCP連接就能夠直接發送HTTP請求，獲取應用層數據。而HTTPS=HTTP+SSL，也就是說HTTPS比HTTP多消耗的伺服器資源主要就是看SSL/TLS消耗了多少伺服器資源。

△SSL/TLS 握手協議（圖片來源於網路，侵刪）

增加了 SSL 的握手階段，必然會帶來的是網站延時的增加，一次完整的握手至少增加延時 2* RTT，利用會話緩存從而復用連接，延時也至少 1* RTT*。

除數據傳輸之外，HTTPS主要是對對稱加解密、非對稱加解密。

對稱加密常見的有 AES-CBC、DES、3DES、AES-GCM等，相同的密鑰可以用於信息的加密和解密，掌握密鑰才能獲取信息，能夠防止信息竊聽，通信方式是1對1；
非對稱加密即常見的 RSA 演算法，還包括 ECC、DH 等演算法。對伺服器資源消耗最厲害的是SSL連接握手階段的非對稱解密。

當然，整體來講，消耗並沒有想像的那麼大，更可以通過各種方法來優化 HTTPS。

CDN接入：CDN 節點通過和業務伺服器維持長連接、會話復用和鏈路質量優化等可控方法，極大減少接入延時。這裡推薦下又拍雲，對每個用戶開放所有節點，共有 200 余個節點，而RTT 的特點是就節點越近延時越小。
硬體加速：採用專用的 SSL 解密卡，能夠具有更高的 HTTPS 接入能力且不影響業務程序的。
升級成 HTTP2。HTTP2 利用 TLS/SSL 帶來的優勢，通過修改協議的方法來提升 HTTPS 的性能，提高下載速度等。前面提到的又拍雲在 HTTPS 協議的基礎上已實現全平台支持 HTTP2。