Skip to content

CONCEPT Cited by 1 source

QUIC-TLS fused handshake

Definition

The QUIC-TLS fused handshake combines transport-parameter negotiation and TLS 1.3 cryptographic handshake into a single round trip. In the TCP + TLS 1.2/1.3 world, these are sequential and independent protocols — you first establish the TCP connection (1 RTT via concepts/tcp-three-way-handshake), then negotiate TLS on top of it. QUIC fuses them.

Canonical round-trip comparison

Zalando's 2024-06 post states the cold-start cost directly (Source: sources/2024-06-17-zalando-next-level-customer-experience-with-http3-traffic-engineering):

  • Cold HTTP/2: ~5–6 RTTs to first byte
  • 1 × DNS
  • 1 × TCP (three-way handshake)
  • 3 × TLS (full TLS 1.2 handshake)
  • 1 × HTTP (request)
  • Cold HTTP/3: ~3 RTTs to first byte
  • 1 × DNS
  • 1 × QUIC (fused transport + TLS 1.3)
  • 1 × HTTP (request)
  • With effective 1-RTT wait — the QUIC handshake carries application data alongside cryptographic setup.

The post puts it this way:

"The handshake is structured to permit the exchange of application data as soon as possible, achieving actual waiting time to be a single round-trip. Peers establish a single QUIC connection that multiplexes a large number of parallel streams. The handshake is only required once, setup of the stream is an instant operation and does not require any additional handshake."

Once the first connection is up, additional streams within it are free (no extra handshake), and resumption via TLS 1.3 PSK enables 0-RTT reconnect for returning clients (see concepts/tls-1-3-zero-rtt-handshake).

Why fusion matters

Traditional layered architecture was designed for a world where the transport and security layers were owned by different parties. In that world, isolation was a feature — each layer could evolve independently. In the modern web, the cost of that isolation is what Zalando names:

"Traditional layered architecture has an isolated security and transport layer causing significant overhead to negotiate encryption keys and transmit encrypted data. Customers perceive bad experiences when the chain of TLS certificates exceeds 4KB and TLS records are fragmented to multiple packets."

Fusion collapses two RTTs into one, and — as a side effect — eliminates the cert-chain-too-big-for-one-packet class of problem that caused initial-flight fragmentation in TLS-over- TCP. QUIC controls how payload is packetised (see concepts/quic-transport) and can align the handshake flight with its own congestion window.

Packet-level encryption as a consequence

Because transport + TLS are fused, QUIC can apply encryption at the packet level — not just to the payload but to packet headers (packet-number encryption, header protection). Middleboxes cannot rewrite QUIC fields the way they could for TCP. This is protocol-level enforcement of transit-encryption invariants; no unencrypted-QUIC mode exists.

TLS integration details

  • QUIC mandates TLS 1.3 — no support for 1.2 or earlier.
  • 0-RTT resumption is supported via PSK — returning clients can send application data in the first flight, at the cost of replay-safety weaker than a full handshake (see concepts/tls-1-3-zero-rtt-handshake).
  • AEAD encryption applied to every packet; CPU cost is non-trivial at millions of packets per second, making AES-NI / ChaCha20 SIMD paths a hot-path optimisation target for QUIC implementations.

Seen in

Last updated · 501 distilled / 1,218 read