实际上,一些国际网站,比如维基百科,在启用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的性能开销。令 |
|
|