TLS is used for other protocols, e.g., SMTPS (SMTP + TLS). But there's an extra DNS query for this case, and I don't think TLS setup time is a significant cause of delays. So I don't know how useful this is.
The latency hit of the extra trip will definitely be felt by end users if the endpoint is far enough away (e.g. ~100-200ms.) You can mitigate the initial setup other ways though, like the CDN approach: terminate TLS much closer with a proxy and use a warm, pre-established backhaul connection to the origin.
Less round trips are always good, though, without any extra stuff to put in place.
Having debugged stuff for someone crazy who wanted less than 50ms global latency for a private search engine I can tell you the TLS negotiation adds significant time the first time you initialize the connection
I've designed my own private CDN and unless you have edges near each geo, you're not getting that kind of latency. And even after TLS negotiation you have no idea what the MSS on a link along the way will be causing fragmentation and retransmits. I've made do with some shenanigans with Noise and pre shared certs and have tried to make payload sizes as small as possible.
Hah gotcha. Hope you got paid well for that. I do it for my own pleasure, but it's a lot of work to do as the internet just isn't designed for low latency interconnect.
emphasis on wanted. And it was quite obtainable depending on geo location. Some locations 70 was best we could do, but most of the US east coast we were able to get around 40
Not sure about real-world statistics, but the current IETF position is that SMTP STARTTLS for mail submission (not transport) is to be phased out in favour of “implicit” SMTP-over-TLS with no cleartext portion, due in part to the former being an implementation minefield[1].
