Details
-
New Feature
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
-
None
Description
The MySQL/MariaDB protocol works as follows for TLS connections:
1. TCP connection is established : 1.5 roundtrips.
2. The Server sends ServerHello
3. The Client sends ClientHello : +1 roundtrip
4. The Server and client initiate TLS connection (+1 or 2 roundtrips)
5. The Server re-sends Server Hello
6. The Client re-sends ClientHello: +1 roundtrip
....
So, in the most economical case, it's 4.5 roundtrips. (with TLS session tickets)
Whereas TLS connection establishment works in the opposite direction: it's the client sending the TLS ClientHello message right after the TCP ACK message.
We could save 1 round-trip (and speed up the TLS connection establishment) by "peeking" at the server side if there's data coming from the client before sending the ServerHello.
If there are these are to be interpreted as a TLS ClientHello message and a TLS connection establishment could continue:
1. TCP connection is established : 1.5 roundtrips.
2. Client sending TLS ClientHello before the server sends MySQL protocol ServerHello.
3. TLS connection is established : +1 or 2 roundtrips
4. Server initiates the MYSQL protocol (by sending MySQL protocol ServerHello) over the encrypted connection. : +1 roundtrip
So, we get down to 3.5 round-trips. (with TLS session tickets)
And even 3 if we can bundle ClientHello into the TCP Ack reply.
In environments that require secure MySQL connections this can lead to significant connection establishment performance enhancements.
And note that this can be done via multiplexing the MySQL/MariaDB server port, so no extra (dedicated TLS) port cost is to be paid.
Plus, it's not a huge alteration of the MySQL protocol, so implementation should not take serious effort.
Another benefit of all this is that all the standard TLS establishment speedup and multi-hosting techniques can be employed.