Am 18.05.2017 um 16:03 schrieb john.e.gr...@wellsfargo.com.INVALID:
-----Original Message-----
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Thursday, May 18, 2017 8:47 AM
To: users@tomcat.apache.org
Subject: Re: TLS handshake performance
This time to the right list...
On 18/05/2017 06:04, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 5/17/17 5:31 PM, Mark Thomas wrote:
I got asked in the corridor at TomcatCon earlier today what the
relative performance of the TLS handshake was with 8.5.x, the NIO
connector and JSSE vs OpenSSL TLS implementation.
I'm curious about what exactly "TLS handshake" was intended to mean
(by the person who asked the question) in this context.
They are using Tomcat in a scenario where clients are making single requests
(so keep alve doesn't help). Given that the handshake uses asymmetric
encryption which is more expensive that symmetric encryption (which is why
the handshake is used to establish a shared secret so symmetric encryption
can used for the actual data) they wanted a sense of the performance
benefit - if any - of NIO and 8.5.x with OpenSSL vs NIO and 8.5.x with JSSE.
The handshake itself does not perform any bulk transfer of encrypted
data, so the negotiated cipher suite does not matter. However...
Tested with: ab -n 1000 -c 2 -f TLS1.2 -Z
ECDHE-RSA-AES128-GCM-SHA256 https://localhost:8443/test.txt
Here the cipher suite matters very much, since the client is not only
performing the TLS handshake but also transferring the client's
request to the server and the server's response back to the client. >
Support for a particular algorithm may dominate the benchmark, here.
Agreed. But it is the handshake that dominates the timings (if you add -k to
use keep-alive the req/sec are an order of magnitude higher).
The cipher suite was the default one chosen by by one of the configs (I
forget which).
The cipher suite will affect the results since it also impacts the enctrpyion
used during the handshake but for any 'reaosnably' secure cipher suite, I'd
expect similar results in terms of the relative performance.
What about SSL session reuse? Did you have any way of disabling that? If
you're testing against a single server, you'll get 100% reuse, which makes a
big difference in the CPU load (lower) on the server. If your real world case
involves dozens or hundreds of servers behind a load balancer, you get almost
no reuse.
Session reuse does not work magically. The client and the server have to
support it, being it using a session cache and IDs or using TLS session
tickets.
I am pretty sure, that "ab", the client used during these tests, does
not support TLS session reuse.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
