OpenSSL 加密需要很长时间才能加载
我的问题涉及加载期间 OpenSSL 的加密成本，问题如下：当通过 IMAP4 使用 SSL（使用我们编写的应用程序，某种 IMAP4 代理）时，我们以两种不同的方式获取消息： 1.全取。 2. 部分获取（获取块）。 就应用程序而言，部分获取和完全获取的第一个块的工作量几乎相同。 然而，当将数据发送回客户端（无论是整个数据还是其中的一部分）时，由于 SSL 加密，我们会得到荒谬的响应时间。 我们清楚地看到，数据越大，OpenSSL 加密它所需的时间就越长（与大小成线性关系，完整与部分显示它很漂亮。问题不在于花费更多时间，而是它加密的绝对时间）需要）。 它使我们面临这样一种情况：完全获取 80k 可能会导致 7 秒的响应时间（而不使用 SSL 时仅超过 1 秒）。 有人遇到过类似的问题吗？ 这样的开销有可能是现实的吗？ 有谁有加速将数据返回客户端的想法（无需添加外部加速器）？ 谢谢。
My question refers to the encryption costs of OpenSSL during load, and here is the problem: When working with SSL over IMAP4 (using an application that we write, some kind of IMAP4 Proxy), we fetch messages in two different ways:
1. full fetch.
2. partial fetch (fetching chunks).
The first chunk of the partial fetch and full fetch are almost equivalent in effort as far as the application is concerned. What happens, though, is that when sending the data back to the client (either the whole body or just a chunk of it), we get ridiculous response times due to the SSL encryption. We clearly see that the larger the data is, the more time it takes OpenSSL to encrypt it (linear to the size, and full vs. partial shows it beautifully. The problem is not that it takes more time, but the absolute time that it takes). It brings us to a situation in which full fetch of 80k may result in a 7 seconds response time (vs. just over 1 second when NOT using SSL). Has anyone ever come across a similar issue? Is there any chance that such overhead may be realistic? Does anyone have an idea for accelerating the data back to the client (without adding an external accelerator)?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
既然您提到您的产品是您编写的代理，我首先会看看问题是否可能与 Nagle 算法。 当我看到套接字性能急剧下降时，这是我检查的第一件事。 基本上，您需要确保在程序中的正确位置写入和刷新数据。 如果你做错了，默认情况下会有0.2秒的延迟才发送数据。 这些延迟很快就会增加，尤其是在频繁的小请求期间。
Since you mention you're product is a proxy which you've written, I would first look to see if the problem might be related to Nagle's algorithm. When I see socket performance drop through the floor, this is the first thing I check. Basically, you need to ensure your are writing and flushing data at the right points in your program. If you do it wrong, by default there will be a 0.2 second delay before the data is sent. These delays quickly add up, especially during frequent small requests.