>>> 在 11:15 下午 的 5/25/2011 上，在讯息 <20110525151556.ga5...@panix.com> 中，Thor Lancelot Simon <t...@panix.com> 写入：> On Tue, May 24, 2011 at 07:45:34PM -0600, Guan Jun He wrote: >> >> >> >>> ? 10:23 ?? ? 5/24/2011 ????? >> <20110524142324.ga29...@panix.com> ??Thor Lancelot Simon <t...@panix.com> >> ???> On Tue, May 24, 2011 at 05:10:03PM +0800, GuanJun He wrote: >> >> Hi, >> >> >> >> This is a patch to add a switch to openssl's compression >> >> methords(if compression methords are configured to compile in, 'config >> >> zlib').Add an environment variable to control compression methords on >> >> and off.As you know,more and more architectures have hardware >> >> compression methords already, to get benifit from the hardware >> >> compression, and to get a good performance,we need a switch as this. >> > >> > I don't understand this. Are you suggesting that some hardware mechanism >> > is trying to compress data _after_ OpenSSL handles it? Turning off >> > compression in OpenSSL won't help with this, since the resulting SSL/TLS >> > stream will stil be basically uncompressible. >> > >> >> I mean OpenSSL compresses data before the encryption(zlib compiled >> in), having a massive performance impact (throughput decrease, CPU load >> increase) on platforms with cryptographic hardware. > > It seems to me you've said two differnt things, and I don't know which > you mean. Do you mean "on platforms with hardware compression methods" > or "on platforms with cryptographic hardware"? > > Or do you have a platform with both features, and a version of OpenSSL > modified to take advantage of the platform's hardware cryptographic > features, but not the platform's hardware compression features? I was > in that situation for some time.
Yes, I mean this.Have you made any progress on this? Before the engine's enhancements, we probably should also provide users a way to work-around it. For platforms with both features, there is really a performance reduction. Till now, I can think of two methords to work-around it: *#1* environment variable (easiest way) *#2* add an item to configure file openssl.cnf (no essential difference from methord #1) Do you agree this? or what do you think about this? Thanks! > > I personally think that compression in OpenSSL needs to be made a > first-class transform such that it can be handed off to engines. Though > of course the engine interface needs other enhancements to deal with > platforms that can do "fused" transforms like compress-then-encrypt-then-MAC, > or full-on SSL record handling. But it would be a start. > > I think it should also be the case that compression (or not) should be > selectable via the existing interface for setting options on the SSL_CTX. > That would provide a more elegant way of dealing with the issue you're > seeing (which I assume is triggered by an increased number of peers who > want to do compression at the SSL layer because of the support for this > in Chrome and in Google's server software) rather than an environent > variable work-around. This is a good idea, make it negotiate-able in SSL session.and the work-around environent variable can also work with it together, and provide users a control to use the compression or not.After the engine is enhanced, we can easily disable the environment variable or remove it. best, Guanjun > > Thor > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
