Performance SSL性能影响

可能重复：

我最近与一位开发人员进行了一次对话，他告诉我，在站点范围内实现SSL会使服务器的负载增加300倍。这真的可信吗？我目前在所有页面上使用SSL，每天有数千名用户访问系统，没有任何明显的延迟。我们正在使用IIS 7服务器

---

他的解决方案是只在登录页面上使用SSL来保护登录凭证的传输。然后将它们重定向回HTTP…这是一种好的做法吗？

HTTPS中代价高昂的是握手，无论是CPU（非对称加密操作更昂贵）还是网络往返（不仅是握手本身，还包括检查证书吊销）。在此之后，加密使用对称加密完成，这不应该给现代CPU带来很大的开销。有一些方法可以减少握手带来的开销（特别是通过会话恢复，如果支持和配置的话）

在许多情况下，将静态内容配置为可在客户端缓存也很有用（请参见

缓存控制：public

）。默认情况下，某些浏览器不缓存HTTPS内容

当使用HTTPS时，服务器的CPU负载会增加300，这听起来好像是配置不当

他的解决方案是只在登录页面上使用SSL来保护 传输登录凭据。然后将它们重定向回 HTTP…这是好的做法吗

许多站点都这样做（包括StackOverflow）。这取决于需要多少安全性。如果执行此操作，则只会保护凭据。攻击者可以窃听在普通HTTP中传递的cookie（或类似的身份验证令牌），并使用它来模拟经过身份验证的用户

---

当从HTTP切换到HTTPS或其他方式时，需要非常小心。例如，来自登录页面的身份验证令牌在传递到普通HTTP后应被视为“已泄露”。特别是，您不能假设仍然使用该身份验证令牌的后续HTTPS请求来自合法用户（例如，不允许其编辑“我的帐户”详细信息或任何类似信息）。

他正在编造。你肯定想到300是个可疑的整数？请他证明一下。测试和测量

当然，这会给服务器带来更多的负载，如果你真的有问题的话，大部分负载都可以转移到硬件加密加速器或前端设备上，但根据我的经验，这是可以忽略不计的。有关更多信息，请参阅

他关于在登录后恢复HTTP的建议只有在登录页面是站点中唯一需要传输安全的页面时才有意义。情况不太可能如此

坦率地说，他似乎对这些都不太了解

大约15年前，我做了一个大型实验，结果表明，在互联网上，SSL的时间开销约为30%。

检查此线程也查看此线程：