ssl 对 Web 服务器的影响
我们中的许多人都有使用普通 TCP 的 Web 和应用程序服务器。
我们中的一些人拥有使用 SSL 等安全层的 Web 和其他服务器。
我对 SSL 的理解是，握手的计算量非常大，并且持续连接的加密（相对）便宜。
我的假设需要你纠正：一个普通的托管盒（以及云托管的平均信息也很酷）可能很容易被期望能够用 AES 加密的数据包饱和其网络连接，但很难做一千个每秒 RSA 握手次数。 对于服务器来说，使用证书进行客户端身份验证的成本也比匿名客户端高得多。
对于 SSL 每秒的会话设置数量有哪些经验规则？
Many of us have web and application servers that use plain TCP.
Some of us have web and other servers that use a secure layer such as SSL.
My understanding of SSL is that the handshaking is very computationally intensive, and the encryption of an ongoing connection is (relatively) cheap.
My assumption for you to correct: an average hosting box (and info on what is average at cloud hosting would be cool too) might easy be expected to be able to saturate its network connections with AES-encrypted packets, but have difficulty doing a thousand RSA handshakes per second. Client authentication with certificates is substantially more expensive for the server than anonymous clients too.
What kind of rules of thumb for the number of session setups per second for SSL are there?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
正如 Ville 所说，没有真正的选择可以在您的配置上进行尝试。 但不要低估建立链接后数据的对称加密。 它可能会更便宜，但如果您要通过加密通道下载大量数据，那么它的成本可能比初始协商高得多。
因此，为此，您必须为站点的使用构建一个通用场景，然后进行压力测试。
As Ville said there is no real option then to try it out on your configuration. But don't underestimated the symmetric encryption of data after establishing a link. It might be less expensive but if you are going to download a lot of data over the encrypted channel than it might cost a lot more than the initial negotiation.
So for this you have to build a common scenario for the usage of your site and then stress test.
为什么不直接测量呢？ 它将为您提供有关您正在使用的软件和硬件的真实数据。 您还可以衡量服务器基础设施变化的影响（添加更多的盒子、SSL 加速器、调整参数等等）。
你是对的，你很难在单个盒子上达到每秒一千次 SSL 握手。 事实上，我想说这可能是不可能的。 每秒几十个，不是问题。 一千，不是没有很多$$$。
您也可能并不真正需要每秒 1000 次握手。 这是相当多的，而且您已经需要相当多的流量才能需要类似的东西：请参阅： SSL TPS 性能需要什么？
请记住，通常您不会一直进行新的 SSL 握手。 浏览器进行一次握手，并在多次请求和/或页面视图中保持连接打开，因此每秒握手的需求可能比您想象的要低得多。
Why not just measure? It will give you real numbers on the exact software and hardware that you are using. You'll also be able to measure the impact of changes in the server infrastructure (adding more boxes, SSL accelerators, tweaking parameters, what have you).
You are correct that you would be hard pressed to get to a thousand SSL handshakes per second on a single box. In fact, I'd say it's probably impossible. A few dozen per second, not a problem. A thousand, not without a lot of $$$.
It's also likely that you don't really need 1000 handshakes per second. That's quite a lot, and you'd already need quite a lot of traffic to need something like that: See this: What do I need in SSL TPS Performance?
Remember that normally you won't be doing new SSL handshakes all the time. Browsers do the handshake once, and keep the connection open over a number of requests and/or page views, so your needs for handshakes per second may be much lower than you think.