http和https之间的性能有任何重大差异吗？我似乎记得读到HTTPS的速度可以达到HTTP的五分之一.这对当前的网络服务器/浏览器有效吗？如果是这样,有没有支持它的白皮书？
对此有一个非常简单的答案:描述您的Web服务器的性能,以了解对您的特定情况的性能损失.有几种工具可以比较HTTP与HTTPS服务器(JMeter和Visual Studio)的性能,并且它们非常易于使用.
如果没有关于网站性质,硬件,软件和网络配置的一些信息,没有人能给你一个有意义的答案.
正如其他人所说,由于加密会产生一定程度的开销,但它高度依赖于:
硬件
服务器软件
动态与静态内容的比率
客户端与服务器的距离
典型的会话长度
等(我个人最喜欢的)
客户端的缓存行为
根据我的经验,对动态内容很重的服务器往往受到HTTPS的影响较小,因为与内容生成时间相比,加密所花费的时间(SSL开销)是微不足道的.
服务于可以容易地在内存中缓存的相当小的静态页面集的服务器遭受更高的开销(在一种情况下,吞吐量在"内联网"上肆虐).
编辑:其他几个人提出的一点是SSL握手是HTTPS的主要成本.这是正确的,这就是"典型的会话长度"和"客户端的缓存行为"很重要的原因.
许多非常短的会话意味着握手时间将压倒任何其他性能因素.较长的会话将意味着会话开始时将产生握手成本,但后续请求的开销相对较低.
客户端缓存可以在几个步骤中完成,从大型代理服务器到单个浏览器缓存.通常,HTTPS内容不会缓存在共享缓存中(尽管一些代理服务器可以利用中间人类型行为来实现此目的).许多浏览器会为当前会话缓存HTTPS内容,并且通常会跨会话进行缓存.非缓存或较少缓存的影响意味着客户端将更频繁地检索相同的内容.这导致为相同数量的用户提供更多请求和带宽.
HTTPS需要初始握手,这可能非常慢.作为握手的一部分传输的实际数据量并不大(通常低于5 kB),但对于非常小的请求,这可能是相当多的开销.但是,一旦握手完成,就会使用非常快速的对称加密形式,因此开销很小.结论:通过HTTPS进行大量短请求将比HTTP慢很多,但如果您在单个请求中传输大量数据,则差异将是微不足道的.
但是,keepalive是HTTP/1.1中的默认行为,因此您将通过同一连接执行单次握手,然后执行大量请求.这对HTTPS产生了重大影响.您可能应该对您的网站进行分析(正如其他人建议的那样)以确保,但我怀疑性能差异不会明显.
要真正了解HTTPS如何增加延迟,您必须了解如何建立HTTPS连接.这是一个很好的图表.关键是,不是客户端获取2"腿"之后的数据(一次往返,你发送请求,服务器发送响应),客户端将至少在4条腿(2次往返)之前不会获取数据.因此,如果数据包在客户端和服务器之间移动需要100毫秒,那么您的第一个HTTPS请求将至少花费500毫秒.
当然,这可以通过重新使用HTTPS连接(浏览器应该这样做)来缓解,但它确实解释了加载HTTPS网站时的初始停顿的一部分.
开销不是由于加密造成的.在现代CPU上,SSL所需的加密是微不足道的.
开销是由于SSL握手造成的,这种握手很长并且大大增加了HTTP会话所需的往返次数.
在服务器处于模拟高延迟链接的末尾时,测量(使用Firebug等工具)页面加载时间.存在用于模拟高延迟链接的工具 - 对于Linux存在"netem".在同一设置上将HTTP与HTTPS进行比较.
可以通过以下方式在一定程度上减轻延迟:
确保您的服务器正在使用HTTP keepalive - 这允许客户端重用SSL会话,从而避免了另一次握手的需要
通过尽可能少地组合资源(例如.js包含文件,CSS)和鼓励客户端缓存,将请求数量减少到尽可能少
减少页面加载的数量,例如通过将不需要的数据加载到页面中(可能在隐藏的HTML元素中),然后使用客户端脚本显示它.
您可以使用AnthumChris的HTTP与HTTPS测试网站在您自己的浏览器中轻松测试HTTP和HTTPS性能之间的差异:"此页面测量其在不安全的HTTP和加密的HTTPS连接上的加载时间.这两个页面都加载了360个独特的非缓存图像(总共2.04 MB)."
结果可能会让你大吃一惊.
有一个高达约在HTTPS的性能,因为最新的知识是很重要的让我们的加密证书颁发机构将开始在夏季2015年发布免费的,自动化的,开放的SSL证书,这要归功于Mozilla的阿卡迈,思科,电子前沿基金会和的IdenTrust.
2015年6月更新关于Let's加密的更新 - 到2015年9月:
让我们加密发布时间表(2015年6月16日)
我们加密根和中间证书(2015年6月4日)
Let Let的加密订户协议草案(2015年5月21日)
有关Twitter的更多信息:@letsencrypt
有关HTTPS和SSL/TLS性能的更多信息,请参阅:
TLS快了吗？
高性能浏览器网络,第4章:传输层安全性
超频SSL
SSL处理的剖析与性能
有关使用HTTPS的重要性的更多信息,请参阅:
为什么HTTPS为万物？(仅限HTTPS的标准)
让我们加密(互联网安全研究组)
HTTPS无处不在(电子前沿基金会)
总而言之,让我引用Ilya Grigorik的话:"TLS只有一个性能问题:它没有被广泛使用.其他所有东西都可以优化."
感谢Chris - HTTP与HTTPS测试基准的作者 - 以下是他的评论.
目前的最佳答案并不完全正确.
正如其他人在此指出的那样,https需要握手,因此可以进行更多的TCP/IP往返.
通常在WAN环境中,延迟成为限制因素,而不是服务器上CPU使用率的增加.
请记住,从欧洲到美国的延迟时间约为200毫秒(折扣时间).
您可以使用HTTPWatch轻松测量(针对单个用户案例).
除了目前为止提到的所有内容之外,请注意,出于安全原因,某些(所有？)Web浏览器不会将通过HTTPS获取的缓存内容存储在本地硬盘驱动器上.这意味着从用户的角度来看,具有大量静态内容的页面在重新启动浏览器后似乎加载速度较慢,从服务器的角度来看,通过HTTPS的静态内容请求量将高于通过HTTP的量.
对此没有一个答案.
加密将始终消耗更多的CPU.在许多情况下,这可以卸载到专用硬件,并且成本将根据所选算法而变化.例如,3des比AES贵.对于加密器,某些算法比解密器更昂贵.有些人的成本相反.
比批量加密更昂贵的是握手成本.新连接将消耗更多CPU.这可以通过会话恢复来减少,代价是保持旧的会话秘密,直到它们到期为止.这意味着来自客户端的小额请求不会再回来的费用最高.
对于跨互联网流量,您可能不会在数据速率中注意到此成本,因为可用带宽太低.但是你肯定会注意到它在繁忙的服务器上的CPU使用率.
我可以告诉你(作为拨号用户)SSL上的同一页面比普通HTTP慢几倍......
在许多情况下,SSL会话的性能影响将通过SSL会话可以在两端(桌面和服务器)缓存这一事实得到缓解.例如,在Windows机器上,SSL会话可以缓存最多10个小时.请参阅 http://support.microsoft.com/kb/247658/EN-US.某些SSL加速器还具有允许您调整会话缓存时间的参数.
要考虑的另一个影响是,通过HTTPS提供的静态内容不会被代理缓存,这可能会降低通过同一代理访问该站点的多个用户的性能.这可以通过以下事实来缓解:静态内容也将缓存在桌面上,Internet Explorer版本6和7缓存可缓存的HTTPS静态内容,除非另有指示(工具菜单/ Internet选项/高级/安全性/不保存加密页面)到磁盘).
京公网安备 11010802040832号 | 京ICP备19059560号-6 