近日，百度宣布全站開啟HTTPS加密搜索。據(jù)官方表示，為解決“中間者”對(duì)用戶隱私的嗅探和劫持等問題，百度將對(duì)傳統(tǒng)HTTP通道添加SSL安全套接層，將所有百度搜索請(qǐng)求全部變成加密狀態(tài)。

　　實(shí)際上，一些國(guó)際網(wǎng)站，比如維基百科，在啟用HTTPS前先會(huì)考慮自己計(jì)算能力是否可以承載HTTPS。那么問題來了，HTTPS要比HTTP多用多少服務(wù)器資源？

　　以下為知乎網(wǎng)友牟旭東的觀點(diǎn)：

　　HTTPS其實(shí)就是建構(gòu)在SSL/TLS之上的 HTTP協(xié)議，所以要比較HTTPS比HTTP多用多少服務(wù)器資源，主要看SSL/TLS本身消耗多少服務(wù)器資源。

　　HTTP使用TCP 三次握手建立連接，客戶端和服務(wù)器需要交換3個(gè)包，HTTPS除了 TCP 的三個(gè)包，還要加上 ssl握手需要的9個(gè)包，所以一共是12個(gè)包。HTTP 建立連接，按照下面鏈接中針對(duì)Computer Science House的測(cè)試，是114毫秒；HTTPS建立連接，耗費(fèi)436毫秒。ssl 部分花費(fèi)322毫秒，包括網(wǎng)絡(luò)延時(shí)和ssl 本身加解密的開銷（服務(wù)器根據(jù)客戶端的信息確定是否需要生成新的主密鑰；服務(wù)器回復(fù)該主密鑰，并返回給客戶端一個(gè)用主密鑰認(rèn)證的信息；服務(wù)器向客戶端請(qǐng)求數(shù)字簽名和公開密鑰）。

　　SSL handshake latency and HTTPS optimizations. :: semicomplete.com

　　當(dāng)SSL 連接建立后，之后的加密方式就變成了3DES等對(duì)于 CPU 負(fù)荷較輕的對(duì)稱加密方式。相對(duì)前面 SSL 建立連接時(shí)的非對(duì)稱加密方式，對(duì)稱加密方式對(duì) CPU 的負(fù)荷基本可以忽略不記，所以問題就來了，如果頻繁的重建 ssl 的session，對(duì)于服務(wù)器性能的影響將會(huì)是致命的，盡管打開HTTPS 保活可以緩解單個(gè)連接的性能問題，但是對(duì)于并發(fā)訪問用戶數(shù)極多的大型網(wǎng)站，基于負(fù)荷分擔(dān)的獨(dú)立的SSL termination proxy就顯得必不可少了，Web 服務(wù)放在SSL termination proxy之后。SSL termination proxy既可以是基于硬件的，譬如F5；也可以是基于軟件的，譬如維基百科用到的就是 Nginx。

　　那采用 HTTPS 后，到底會(huì)多用多少服務(wù)器資源，2010年1月 Gmail切換到完全使用 HTTPS， 前端處理 SSL 機(jī)器的CPU 負(fù)荷增加不超過1%，每個(gè)連接的內(nèi)存消耗少于20KB，網(wǎng)絡(luò)流量增加少于2%。由于 Gmail 應(yīng)該是使用N臺(tái)服務(wù)器分布式處理，所以CPU 負(fù)荷的數(shù)據(jù)并不具有太多的參考意義，每個(gè)連接內(nèi)存消耗和網(wǎng)絡(luò)流量數(shù)據(jù)有參考意義。這篇文章中還列出了單核每秒大概處理1500次握手（針對(duì)1024-bit 的 RSA），這個(gè)數(shù)據(jù)很有參考意義，具體信息來源的英文網(wǎng)址：ImperialViolet。西安做網(wǎng)站推薦閱讀>>> 網(wǎng)站日志中的HTTP狀態(tài)碼詳解，

　　Heartbleed這個(gè)被稱作史上最大的網(wǎng)絡(luò)安全漏洞，想必很多人都有所耳聞，Heartbleed之所以能夠出現(xiàn)，其實(shí)和我們這個(gè)問題關(guān)系還不小，前面我們談到了頻繁重建 SSL/TLS的session對(duì)于服務(wù)器影響是致命的，所以聰明的RFC 在2012年提出了 RFC6520 TLS 的心跳擴(kuò)展。這個(gè)協(xié)議本身是簡(jiǎn)單和完美的，通過在客戶端和服務(wù)器之間來回發(fā)送心跳的請(qǐng)求和應(yīng)答，?；?TLS session，減少重建 TLS的session的性能開銷。令人遺憾的是，openssl 在實(shí)現(xiàn)這個(gè)心跳擴(kuò)展時(shí)，犯了一個(gè)低級(jí)的錯(cuò)誤，沒有對(duì)收到的心跳請(qǐng)求進(jìn)行長(zhǎng)度檢查，直接根據(jù)心跳請(qǐng)求長(zhǎng)度拷貝數(shù)據(jù)區(qū)，導(dǎo)致簡(jiǎn)單的心跳應(yīng)答中可能包含了服務(wù)器端的核心數(shù)據(jù)區(qū)內(nèi)容，用戶名，密碼，信用卡信息，甚至服務(wù)器的私有密鑰都有可能泄露。心因?yàn)樾奶；畹倪@個(gè) BUG 在滴血，這個(gè)名字起的極度形象。

　　下面開始講一個(gè)無聊的故事，和問題關(guān)系不大，時(shí)間緊張的看官可以到此為止了。

　　從前山上有座廟，廟里有個(gè)和尚......，別胡鬧了，老和尚來了。

　　小和尚問老和尚：ssl為什么會(huì)讓HTTP安全？

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

　　小和尚摸摸腦袋問老和尚：師傅，如果我們兩人選擇“和尚”作為密碼，再創(chuàng)造一個(gè)和尚算法，我們倆之間的通信不就高枕無憂了？

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

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

　　老和尚：我和小花只要知道每封信的密碼，就可以讀到對(duì)方加密的信件，關(guān)鍵是我們互相之間怎么知道這個(gè)對(duì)稱密碼。你說，我要是將密碼寫封信給她，信被別人偷了，那大家不都知道我們的密碼了，也就能夠讀懂我們情書了。不過還是有解的，這里我用到了江湖中秘傳的非對(duì)稱密碼。我現(xiàn)在手頭有兩個(gè)密碼，一個(gè)叫“公鑰”，一個(gè)叫“私鑰”，公鑰發(fā)布到了江湖上，好多人都知道，私鑰嘛，江湖上只有我一個(gè)人知道；這兩個(gè)密鑰有數(shù)學(xué)相關(guān)性，就是說用公鑰加密的信件，可以用私鑰解開，但是用公鑰卻解不開。公鑰小花是知道的，她每次給我寫信，都要我的公鑰加密她的對(duì)稱密碼，單獨(dú)寫一張密碼紙，然后用她的對(duì)稱密碼加密她的信件，這樣我用我的私鑰可以解出這個(gè)對(duì)稱密碼，再用這個(gè)對(duì)稱密碼來解密她的信件。西安網(wǎng)站建設(shè)推薦閱讀>>> IIS啟用Gzip壓縮(HTTP壓縮)過程詳解，

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

　　小和尚問：那然后呢？

　　老和尚：從嵩山少林寺回山上寺廟時(shí)，我將有火印的公鑰親自給小花送去，可是之后再也沒有收到小花的來信。過了一年才知道，其實(shí)小花還是給我寫過信的，當(dāng)時(shí)信確實(shí)是用有火印的公鑰加密，張屠夫拿到信后，由于不知道我的私鑰，解不開小花的密碼信，所以一怒之下將信件全部燒毀了。也由于張屠夫無法知道小花的對(duì)稱密碼而無法回信，小花發(fā)出幾封信后石沉大海，也心生疑惑，到處打聽我的近況。這下張屠夫急了，他使用我發(fā)布的公鑰，仿照小花的語(yǔ)氣，給我發(fā)來一封信。拿到信時(shí)我就覺得奇怪，信紙上怎么有一股豬油的味道，結(jié)尾竟然還關(guān)切的詢問我的私鑰。情知有詐，我思量無論如何要找到辦法讓我知道來的信是否真是小花所寫。后來竟然讓我想到了辦法....西安網(wǎng)站建設(shè)推薦閱讀>>> HTTP狀態(tài)代碼（錯(cuò)誤代碼)各代表什么意思？，

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

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