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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　小和尚問(wèn)到：那師傅何解？

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

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

　　小和尚問(wèn)：那然后呢？

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

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

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