QUIC vs TCP Handshake Calculator
Compares QUIC and TCP+TLS 1.3 handshake duration based on RTT.
—
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.
Related Tools
TCP Window BDP Calculator
Computes ideal TCP window size from bandwidth (Mbps) and RTT (ms) using bandwidth-delay product.
HTTP/3 QUIC Overhead Calculator
Computes useful HTTP/3 payload over QUIC, subtracting UDP, QUIC and TLS overhead.
TCP Window Scaling Factor Calculator
Enter a target receive window in KB to get the TCP window scale shift count needed past the 64 KB limit, plus the maximum effective window in bytes.
TCP Bandwidth-Delay Product
Multiplies link bandwidth in Mbps by round-trip time in milliseconds to size the TCP window that keeps the pipe full, reported in bytes, KB and MB.
Probable Stops
Calculate the probable number of stops of an elevator, S = N × (1 − (1 − 1/N)^P), from the number of served floors N and the number of passengers P in the car. The result is how many floors, on average, the elevator actually stops at during a trip (probabilistically, two passengers may go to the same floor). It is an essential parameter of the round trip time calculation: more stops raise the RTT. The formula assumes passengers choose destination floors randomly and uniformly. With a full car, S approaches N (stops at almost all). Enter the number of floors and passengers.
TCP MSS from MTU Calculator
Estimates TCP MSS from link MTU, subtracting IP and TCP headers.
The results provided by this tool are for general informational and educational purposes only and do not constitute professional, financial, medical, legal, tax or accounting advice. Always confirm important decisions with a qualified professional and official sources.