benchmarking mod_gnutls vs mod_ssl

[Sam Varshavchik]

Simon Josefsson writes:

> "Paul Querna" <chip at corelands.com> writes:
> 
>>> One interesting behaviour I noticed when running the tests was that with
>>> mod_ssl, the exchanged TCP packets as seen in wireshark were:
>>>
>>> -> client hello
>>> <- server hello, certificate, server key exchange, server hello done
>>> -> client key exchange, change cipher spec, encrypted handshake message
>>> <- change cipher spec, encrypted handshake message
>>> ...
>>>
>>> but with gnutls we have:
>>>
>>> -> client hello
>>> <- server hello
>>> <- certificate
>>> <- server key exchange
>>> <- server hello done
>>> ->client key exchange, change cipher spec, encrypted handshake message
>>> <- change cipher spec
>>> <- encrypted handshake message
>>>
>>> In other words, gnutls sends each TLS packet in a separate TCP packet.
>>> This may have some impact on performance, but it is too early to tell
>>> for sure.
>>
>> This might be a bug in mod_gnutls -- we might want to add some smarter
>> buffering / picking when we do a flush(). Right now I believe we try to
>> flush every time gnutls says there is data to send.
> 
> Hm, yes, perhaps mod_gnutls could do some buffering.  Or gnutls could do
> it internally.
> 
>> It also would be nice if the gnutls API had a better way to say "flush",
>> rather than just "here is data", although the current API is simple :-)
> 
> Aren't there options in the kernel TCP interface to delay sending
> packets for some time, to wait for more data that could also be sent in
> the same packet?  I have some vague memory about this.

Yes, TCP_CORK via setsockopt. It's Linux specific.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: </pipermail/attachments/20080310/840105b3/attachment.pgp>