可能重复：
SSL 会产生多少开销？
我最近与一位开发人员进行了交谈，他告诉我，在站点范围内实施 SSL 会使服务器负载增加 300 倍。这真的可信吗？我目前在所有页面上都使用 SSL，我们每天有数千名用户访问系统，没有任何明显的延迟。我们正在使用 IIS 7 服务器。
他的解决方案是仅在登录页面上使用 SSL 来保护登录凭据的传输。然后将它们重定向回 HTTP ...这是一种好习惯吗？
问问题
2140 次
2 回答
3
HTTPS 中代价高昂的是握手，包括 CPU（非对称加密操作更昂贵）和网络往返（不仅是握手本身，还包括检查证书吊销）。在此之后，加密是使用对称加密完成的，这不应该对现代 CPU 造成很大的开销。有一些方法可以减少由于握手引起的开销（特别是通过会话恢复，如果支持和配置）。
在许多情况下，将静态内容配置为在客户端也可缓存是很有用的（请参阅 参考资料Cache-Control: public）。某些浏览器默认不缓存 HTTPS 内容。
使用 HTTPS 时将服务器的 CPU 负载增加 300 听起来好像配置不正确。
他的解决方案是仅在登录页面上使用 SSL 来保护登录凭据的传输。然后将它们重定向回 HTTP ...这是一种好习惯吗？
许多网站都这样做（包括 StackOverflow）。这取决于需要多少安全性。如果您这样做，则只有凭据会受到保护。攻击者可以窃听以纯 HTTP 传递的 cookie（或类似的身份验证令牌），并使用它来模拟经过身份验证的用户。
从 HTTP 切换到 HTTPS 或以其他方式切换时需要非常小心。例如，来自登录页面的身份验证令牌在传递给纯 HTTP 后应被视为“已泄露”。特别是，您不能假设仍然使用该身份验证令牌的后续 HTTPS 请求来自合法用户（例如，不允许它编辑“我的帐户”详细信息或任何类似内容）。
于 2013-01-29T19:34:10.100 回答
-1
他正在弥补。您肯定想到 300 是一个可疑的整数吗？请他证明。测试和测量。
它肯定会给服务器增加更多负载，如果你真的有问题，其中大部分可以卸载到硬件加密加速器或前端盒，但根据我的经验，它可以忽略不计。请参阅此处了解更多信息。
他关于在登录后恢复到 HTTP 的建议只有在登录页面是站点中唯一需要传输安全性的页面时才有意义。情况不太可能如此。
坦率地说，他似乎对这一切都不太了解。
大约 15 年前，我做了一个大型实验，结果表明在 Internet 上 SSL 的时间开销约为 30%。
于 2013-01-30T00:10:53.790 回答