http和https之间在性能上有什么主要区别吗？我似乎还记得阅读过的文章，HTTPS的速度可以是HTTP的五分之一。这对当前的网络服务器/浏览器有效吗？如果是这样，是否有任何白皮书来支持它？

解决方案

鉴于SSL需要额外的加密步骤，而非SLL HTTP根本不需要加密，因此几乎可以肯定这是正确的。

HTTPS具有加密/解密开销，因此它总是会稍微慢一些。 SSL终止会占用大量CPU。如果我们有要卸载SSL的设备，则延迟的差异可能几乎不会引起注意，具体取决于服务器所承受的负载。

一个更重要的性能差异是用户连接时HTTPS会话是ketp打开的。 HTTP"会话"仅持续单个项目请求。

如果我们正在运行一个具有大量并发用户的站点，则期望购买大量内存。

有一种方法可以衡量这一点。来自Apache的名为jmeter的工具将测量吞吐量。如果使用jmeter在受控环境中使用或者不使用SSL来对服务进行大量采样，则应该准确比较相对成本。我会对结果感兴趣。

有一个非常简单的答案：配置Web服务器的性能，以查看针对特定情况的性能损失。有几种工具可以比较HTTP与HTTPS服务器的性能(想到了JMeter和Visual Studio)，它们非常易于使用。

没有一些有关网站的性质，硬件，软件和网络配置的信息，没有人能给我们一个有意义的答案。

正如其他人所说，由于加密，会产生一定程度的开销，但是它高度依赖于：

• 硬件
• 服务器软件
• 动态与静态内容之比
• 客户端到服务器的距离
• 典型的会话时长
• 等等(我个人的最爱)
• 客户端的缓存行为

以我的经验，由于内容加密所花的时间(SSL开销)与内容生成时间相比微不足道，因此对动态内容非常重视的服务器受HTTPS的影响较小。

大量服务于可以轻松地缓存在内存中的静态页面集的服务器遭受了更高的开销(在一种情况下，吞吐量被"内部网"吞噬了)。

编辑：其他几个人提出的一个观点是SSL握手是HTTPS的主要成本。没错，这就是为什么"典型会话长度"和"客户端的缓存行为"很重要的原因。

许多非常短的会话意味着握手时间将压倒其他任何性能因素。较长的会话将意味着握手成本将在会话开始时发生，但后续请求的开销相对较低。

客户端缓存可以分几步完成，从大型代理服务器到单个浏览器缓存，可以随时随地进行。通常，HTTPS内容将不会缓存在共享缓存中(尽管少数代理服务器可以利用中间人行为来实现此目的)。许多浏览器会为当前会话缓存HTTPS内容，并且通常跨会话多次。不缓存或者缓存较少的影响意味着客户端将更频繁地检索相同的内容。这导致更多的请求和带宽来服务于相同数量的用户。

对此没有一个答案。

加密将始终消耗更多的CPU。在许多情况下，可以将其卸载到专用硬件，并且成本将因所选算法而异。例如，3des比AES贵。对于加密器而言，某些算法比解密器更昂贵。有些成本相反。

握手成本比批量加密更昂贵。新的连接将消耗更多的CPU。可以通过恢复会话来减少这种情况，其代价是保留旧的会话机密，直到它们过期为止。这意味着来自客户端的小额请求如果再也回不来，那是最昂贵的。

对于跨Internet流量，我们可能不会在数据速率中注意到此成本，因为可用带宽太低。但是我们肯定会在繁忙服务器上的CPU使用率中注意到它。

HTTPS需要初始握手，这可能会很慢。作为握手的一部分传输的实际数据量并不大(通常小于5 kB)，但是对于非常小的请求，这可能会产生相当大的开销。但是，握手完成后，将使用非常快速的对称加密形式，因此开销很小。底线：通过HTTPS发出大量短请求将比HTTP慢很多，但是如果在单个请求中传输大量数据，则差异将不明显。

但是，keepalive是HTTP / 1.1中的默认行为，因此我们将进行一次握手，然后在同一连接上进行大量请求。这对HTTPS来说有很大的不同。我们可能应该对站点进行概要分析(如其他人所建议的那样)以确保这一点，但是我怀疑性能差异不会很明显。

我可以告诉我们(作为拨号用户)，通过SSL的同一页面比通过常规HTTP慢几倍...

除了到目前为止提到的所有内容之外，请记住，出于安全原因，某些(全部？)Web浏览器不会将通过HTTPS获得的缓存内容存储在本地硬盘驱动器上。这意味着从用户的角度来看，具有大量静态内容的页面在重新启动浏览器后似乎加载速度较慢，并且从服务器的角度来看，通过HTTPS请求静态内容的数量将比通过HTTP请求的静态内容要高。

开销不是由于加密引起的。在现代CPU上，SSL要求的加密是微不足道的。

开销归因于SSL握手，这很长，并且极大地增加了HTTPS会话通过HTTP进行会话所需的往返次数。

当服务器位于模拟的高延迟链接的末端时，测量(使用Firebug等工具)页面加载时间。存在用于为Linux模拟高延迟链接的工具，即" netem"。在相同设置下将HTTP与HTTPS进行比较。

可以通过以下方式在某种程度上缓解延迟：

• 确保服务器正在使用HTTP Keepalive-这允许客户端重用SSL会话，从而避免了再次握手的需要
• 将请求数量减少到尽可能少-通过在可能的情况下合并资源(例如.js包含文件，CSS)并鼓励客户端缓存
• 减少页面加载次数，例如通过将不需要的数据加载到页面中(可能在隐藏的HTML元素中)，然后使用客户端脚本进行显示。

要真正了解HTTPS如何增加延迟，我们必须了解HTTPS连接是如何建立的。这是一个不错的图。关键是客户端不是在2个"行程"之后获取数据(一次往返，我们发送一个请求，服务器发送一个响应)，而是直到至少4个行程(两次往返)，客户端才获取数据。 。因此，如果数据包在客户端和服务器之间移动需要100毫秒，则第一个HTTPS请求将至少花费500毫秒。

当然，可以通过重新使用HTTPS连接(浏览器应该这样做)来缓解这种情况，但是它确实解释了在加载HTTPS网站时初始停顿的一部分。

当前的最佳答案并不完全正确。

正如其他人在这里指出的那样，https需要握手，因此需要进行更多的TCP / IP往返。

通常，在WAN环境中，延迟成为限制因素，而不是服务器上增加的CPU使用率。

请记住，从欧洲到美国的延迟时间可能约为200毫秒(原路段时间)。

我们可以使用HTTPWatch轻松衡量(针对单个用户的情况)。

在许多情况下，可以在两端(台式机和服务器)上缓存SSL会话，从而减轻了SSL握手对性能的影响。例如，在Windows计算机上，SSL会话最多可以缓存10个小时。请参阅http://support.microsoft.com/kb/247658/EN-US。某些SSL加速器还将具有允许我们调整会话缓存时间的参数。

要考虑的另一个影响是，通过HTTPS提供的静态内容将不会被代理缓存，并且这可能会降低跨同一代理访问该站点的多个用户的性能。可以通过以下方式缓解此问题：静态内容也将缓存在台式机上，除非另有说明，否则Internet Explorer 6和7版会缓存可缓存的HTTPS静态内容("工具"菜单/" Internet选项" /"高级" /"安全性" /"不保存加密的页面"到磁盘)。