QUIC vs TCP Handshake Calculator

QUIC Handshake RTT vs. TCP+TLS

QUIC is a transport protocol that runs over UDP and folds TLS 1.3 straight into the connection setup. The handshake finishes in one round-trip. A fresh connection costs QUIC_setup = 1 × RTT, and if the client resumes a session from cached parameters it drops to 0 × RTT. The old stack is slower. There you pay TCP_setup + TLS_setup = 3 × RTT, because you wait for the TCP 3-way handshake and then TLS ClientHello/ServerHello plus Finished.

Put numbers on it. Over a link with 80 ms RTT, a QUIC connection starts in 80 ms, the classic TCP+TLS 1.3 path takes 240 ms, and a resumed QUIC session starts in 0 ms. Google prototyped QUIC back in 2012 to speed up Chrome talking to its own services, and the IETF later standardized it as RFC 9000 in 2021. One other thing it fixes is head-of-line blocking at the transport layer: each stream recovers from loss on its own, and that independence is exactly why HTTP/3 only runs on QUIC.

Applications

You'll find QUIC behind HTTP/3 at Cloudflare, Google, Meta and YouTube, and behind Google services like Gmail, Search and Maps. Modern CDNs lean on it too. Mobile apps care about it because a connection can migrate across Wi-Fi and cellular without breaking. And for anything latency-sensitive, shaving off those 2 RTTs shows up as real page-load gains, usually somewhere in the 5-15% range on live sites.

FAQ

Why does QUIC use UDP instead of a new transport? Middleboxes such as firewalls and NATs tend to pass only TCP and UDP. By sitting on top of UDP, QUIC could ship right away instead of waiting years for OS kernels and routers to learn a brand-new protocol.

Is 0-RTT safe? An attacker can replay 0-RTT data, so you should only send it for idempotent requests like GETs. A server either rejects non-idempotent 0-RTT outright or knowingly takes on the replay risk.

Does QUIC fix head-of-line blocking? At the transport layer, yes. Lose a packet in stream A and streams B, C and D keep flowing. HTTP/2 over TCP couldn't do that, since TCP hands bytes up in order no matter which stream they belong to.