實際上，一些國際網(wǎng)站，比如維基百科，在啟用HTTPS前先會考慮自己計算能力是否可以承載HTTPS。那么問題來了，HTTPS要比HTTP多用多少服務(wù)器資源?
以下為知乎網(wǎng)友牟旭東的觀點：
HTTPS其實就是建構(gòu)在SSL/TLS之上的 HTTP協(xié)議，所以要比較HTTPS比HTTP多用多少服務(wù)器資源，主要看SSL/TLS本身消耗多少服務(wù)器資源。
HTTP使用TCP 三次握手建立連接，客戶端和服務(wù)器需要交換3個包，HTTPS除了 TCP 的三個包，還要加上 ssl握手需要的9個包，所以一共是12個包。HTTP 建立連接，按照下面鏈接中針對Computer Science House的測試，是114毫秒;HTTPS建立連接，耗費436毫秒。ssl 部分花費322毫秒，包括網(wǎng)絡(luò)延時和ssl 本身加解密的開銷(服務(wù)器根據(jù)客戶端的信息確定是否需要生成新的主密鑰;服務(wù)器回復(fù)該主密鑰，并返回給客戶端一個用主密鑰認(rèn)證的信息;服務(wù)器向客戶端請求數(shù)字簽名和公開密鑰)。
SSL handshake latency and HTTPS optimizations. :: semicomplete.com
當(dāng)SSL 連接建立后，之后的加密方式就變成了3DES等對于 CPU 負(fù)荷較輕的對稱加密方式。相對前面 SSL 建立連接時的非對稱加密方式，對稱加密方式對 CPU 的負(fù)荷基本可以忽略不記，所以問題就來了，如果頻繁的重建 ssl 的session，對于服務(wù)器性能的影響將會是致命的，盡管打開HTTPS 保活可以緩解單個連接的性能問題，但是對于并發(fā)訪問用戶數(shù)極多的大型網(wǎng)站，基于負(fù)荷分擔(dān)的獨立的SSL termination proxy就顯得必不可少了，Web 服務(wù)放在SSL termination proxy之后。SSL termination proxy既可以是基于硬件的，譬如F5;也可以是基于軟件的，譬如維基百科用到的就是 Nginx。
那采用 HTTPS 后，到底會多用多少服務(wù)器資源，2010年1月 Gmail切換到完全使用 HTTPS， 前端處理 SSL 機器的CPU 負(fù)荷增加不超過1%，每個連接的內(nèi)存消耗少于20KB，網(wǎng)絡(luò)流量增加少于2%。由于 Gmail 應(yīng)該是使用N臺服務(wù)器分布式處理，所以CPU 負(fù)荷的數(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對于服務(wù)器影響是致命的，所以聰明的RFC 在2012年提出了 RFC6520 TLS 的心跳擴展。這個協(xié)議本身是簡單和完美的，通過在客戶端和服務(wù)器之間來回發(fā)送心跳的請求和應(yīng)答，保活 TLS session，減少重建 TLS的session的性能開銷。令 |
 |
|
手機站
您當(dāng)前位置是：產(chǎn)品大全 >> 商務(wù)服務(wù) >>
電子商務(wù)
免責(zé)聲明：以上所展示的信息由會員自行提供，內(nèi)容的真實性、準(zhǔn)確性和合法性由發(fā)布會員負(fù)責(zé)，www.qy6.com對此不承擔(dān)任何責(zé)任。如有侵犯您的權(quán)益，請來信通知刪除。
聯(lián)系信息
