QUIC Handshake: Mermaid Sequence Diagram

About Source

QUIC is a modern transport protocol developed by Google and standardized in RFC 9000, designed to eliminate the layered handshake latency of TCP+TLS by combining connection establishment and cryptographic negotiation into a single 1-RTT exchange over UDP.

The fundamental problem QUIC solves is handshake latency stacking. A traditional HTTPS connection requires: 1 RTT for TCP handshake + 1 RTT for TLS 1.3 handshake = 2 RTTs before the first byte of application data can be sent. QUIC collapses this to 1 RTT for a new connection and 0 RTTs for session resumption (0-RTT data).

Why UDP?: QUIC runs over UDP (port 443 by default) rather than TCP to bypass kernel TCP implementations that can't be updated. This lets QUIC evolve faster and deploy improvements via application updates rather than OS upgrades. The protocol implements its own reliability, ordering, and congestion control.

Initial Packet: The client sends a QUIC Initial packet containing a TLS ClientHello. QUIC wraps TLS 1.3 messages directly in its packet format. The Initial packet uses well-known encryption derived from the connection ID (providing minimal protection against off-path attackers).

Server Response: The server responds with its own QUIC packets containing the TLS ServerHello, EncryptedExtensions, Certificate, CertificateVerify, and Finished — all in a single flight. The server also sends HANDSHAKE level packets with further data.

Handshake Complete: After the client verifies the certificate and sends its Finished, both sides can immediately exchange application data. QUIC streams are multiplexed within the connection with no head-of-line blocking between streams (unlike TCP, where one lost packet stalls all streams). This is the foundation of HTTP/3.

Frequently asked questions

QUIC is a transport protocol built on UDP, developed by Google and standardized in RFC 9000. It was created to eliminate the layered handshake latency of TCP+TLS — where two separate round trips are required before sending application data — and to solve TCP's head-of-line blocking, where a single lost packet stalls all streams sharing the connection.

QUIC integrates TLS 1.3 directly into its packet format, so transport negotiation and cryptographic handshake occur simultaneously. The client sends a QUIC Initial packet containing a TLS `ClientHello`. The server responds in a single flight with `ServerHello`, `Certificate`, `CertificateVerify`, and `Finished`. After one round trip, both sides have session keys and can exchange application data.

On a subsequent connection to the same server, the client can include application data in its very first packet using a session ticket from the prior connection — before the handshake completes. This achieves zero round-trip latency for connection setup. However, 0-RTT data is susceptible to replay attacks and should only be used for idempotent GET requests.

A TCP+TLS 1.3 connection requires 2 RTTs before application data: one RTT for TCP's SYN/SYN-ACK/ACK, then one RTT for TLS. QUIC collapses both into 1 RTT for new connections and 0 RTTs for session resumption. Additionally, QUIC's connection migration (identified by Connection ID rather than the IP 4-tuple) allows connections to survive IP changes, while TCP connections drop immediately.

mermaid

sequenceDiagram
    participant Client
    participant Server

    note">Note over Client,Server: QUIC runs over UDP port 443
    note">Note over Client: Generate Connection ID\nGenerate key material

    Client->&gt;Server: Initial packet\n(TLS ClientHello, CRYPTO frame)
    note">Note over Server: Derive initial secrets\nfrom Connection ID

    Server-->&gt;Client: Initial packet (TLS ServerHello)
    Server-->&gt;Client: Handshake packet\n(EncryptedExtensions, Certificate,\nCertificateVerify, Finished)

    note">Note over Client: Verify certificate\nDerive handshake keys
    Client->&gt;Server: Handshake packet\n(TLS Finished) [1 RTT complete]

    note">Note over Client,Server: Application data keys derived
    Client->&gt;Server: 1-RTT packet: HTTP/3 request [encrypted]
    Server-->&gt;Client: 1-RTT packet: HTTP/3 response [encrypted]

    note">Note over Client,Server: Multiple streams multiplexed\nno head-of-line blocking

    note">Note over Server: Session ticket for 0-RTT resumption
    Server-->&gt;Client: NEW_TOKEN frame