Calculate the latency and bandwidth overhead introduced by TLS handshakes and encryption.
TLS introduces two distinct kinds of overhead: a one-time handshake latency (extra round-trips before application data can flow) and a per-record bandwidth overhead (extra bytes added to every encrypted record for headers and authentication tags). TLS 1.3 reduced the handshake from two round-trips (TLS 1.2) to one by combining the key exchange and cipher negotiation into a single round-trip, cutting connection setup latency roughly in half on high-latency links. The per-record data overhead is small and fixed (20-40 bytes) but matters more for streams of small records.
Data overhead percentage
data_overhead% = record_overhead / payload_size × 100
Handshake latency
latency_overhead = extra_RTTs × RTT
TLS 1.2 negotiates the cipher suite and exchanges keys across two round-trips. TLS 1.3 restructured the handshake so the client can send its key share in the very first message, letting the server respond with everything needed to finish in a single round-trip.
The one-time handshake latency becomes negligible relative to total transfer time for large files, but the fixed record-level overhead is proportionally tiny too — bandwidth overhead from TLS is much more noticeable for many small requests (e.g. API calls) than for bulk data transfer.
TLS 1.3 also supports an optional 0-RTT mode for resumed connections, where the client can send data immediately using a previously established session ticket. This calculator models the standard 1-RTT full handshake, not the 0-RTT resumption case, which carries some replay-attack tradeoffs.
They're conceptually similar — both add fixed per-packet/per-record bytes for encryption and authentication — but TLS operates per data record within an already-established TCP connection, while a VPN encapsulates entire IP packets, typically with somewhat larger overhead. See the VPN Overhead calculator for that comparison.