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

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

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

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

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

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

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

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

標簽： https ssl 安全 服務器 服務器端 服務器性能 漏洞 網(wǎng)絡(luò) 網(wǎng)絡(luò)安全 網(wǎng)站 問題 用戶

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。