TurboTLS: TLS connection establishment with 1 less round trip

TL;DR

TurboTLS introduces a TLS handshake optimization that eliminates one RTT by delivering the initial TLS flights over UDP while the TCP three-way handshake runs in parallel, then switches to TCP for the final handshake and application data. The approach preserves TLS semantics, relies on lightweight UDP fragmentation with connection identifiers, and can be deployed via transparent proxies with DNS-based server support discovery. Experimental results across local to intercontinental links show latency reductions approaching QUIC on long distances and clear improvements on shorter paths, highlighting TurboTLS as a practical, low-complexity alternative to full protocol migrations. The paper also discusses DoS considerations, deployment scenarios, and extensions (e.g., PSK, ECH), and introduces TLS depth as a metric for analyzing real-world TLS behavior on websites.

Abstract

We show how to establish TLS connections using one less round trip. In our approach, which we call TurboTLS, the initial client-to-server and server-to-client flows of the TLS handshake are sent over UDP rather than TCP. At the same time, in the same flights, the three-way TCP handshake is carried out. Once the TCP connection is established, the client and server can complete the final flight of the TLS handshake over the TCP connection and continue using it for application data. No changes are made to the contents of the TLS handshake protocol, only its delivery mechanism. We avoid problems with UDP fragmentation by using request-based fragmentation, in which the client sends in advance enough UDP requests to provide sufficient room for the server to fit its response with one response packet per request packet. Clients can detect which servers support this without an additional round trip, if the server advertises its support in a DNS HTTPS resource record. Experiments using our software implementation show substantial latency improvements. On reliable connections, we effectively eliminate a round trip without any noticeable cost. To ensure adequate performance on unreliable connections, we use lightweight packet ordering and buffering; we can have a client wait a very small time to receive a potentially lost packet (e.g., a fraction of the RTT observed for the first fragment) before falling back to TCP without any further delay, since the TCP connection was already in the process of being established. This approach offers substantial performance improvements with low complexity, even in heterogeneous network environments with poorly configured middleboxes.

Figures (9)

• Figure 1: TLS 1.3 connection establishment
• Figure 2: TurboTLS connection establishment
• Figure 4: A client and a server each using a proxy to use TurboTLS
• Figure 5: Local: Client and server in same datacenter
• Figure 6: Continental: Client in Paris, server in Belgium