I've been doing some testing, and I see an increase of about 40-60ms, just for initial connection server compute. Is that normal? How does one reduce the initial SSL/TLS connection compute time?
My web app responds in 1-2ms. Adding another 40-60ms on top of for https that wrecks latency.
Things like TLS False Start, TLS Resumption, TCP Fast Open, and more can really help reduce that pretty well.
Also, take a look at the book linked at the bottom of that page which includes a pretty comprehensive section on improving RTT and TLS speeds in general. (https://hpbn.co/transport-layer-security-tls/)
b) with session tickets configured, do you see this increase consistently for the same client?
c) would your users find it acceptable to have the occasional 50ms hit on a full handshake in order to get authentication & encryption? would they even notice (see 'a')
b) Session tickets cuts it from 60ms down to about .5ms extra delay (when loadtesting with a keepalive https connections) so this is really only an initial handshake problem.
c) The localhost full handshake latency problem is really a proxy to the real problem: the CPU load. TLS/SSL is adding a lot of compute requirement to each initial connection. This becomes important as I have to deal with celebrity content, where a single Twitter link can lead to hundreds of thousands of incoming connections within a few minutes.
TLS/SSL handshake compute requirements really need to be sped up somehow..
A quick test with ab (-n 1 -c 1) against a nginx instance shows about 5ms for me, on an Intel E3-1245 V2 @ 3.40GHz. This is with a P-384 key, so it would be even less with P-256 or RSA-2048 (which, IIRC, have fast assembler implementations in openssl).