QUIC (RFC 9000 transport protocol)

QUIC is standardized in RFC 9000, with RFC 9001 describing how it uses TLS 1.3. Instead of running TLS records over TCP, QUIC carries TLS handshake messages in its own CRYPTO frames and uses the resulting keys to protect its packets; the TLS record layer is not used. HTTP/3 (RFC 9114) is HTTP mapped onto QUIC.

Why it matters

Because the transport and cryptographic handshakes are combined, a new QUIC connection typically needs one round trip before application data flows, and resumed connections can use 0-RTT. Streams are independent, so one lost packet does not stall every request the way it can with HTTP/2 over TCP. Certificates need no change: QUIC uses the same X.509 certificates and keys as HTTPS over TCP. Clients usually discover HTTP/3 through an Alt-Svc response header or a DNS HTTPS record and negotiate it with the ALPN value h3. Operationally, UDP port 443 must be reachable; where a firewall blocks it, browsers fall back to TCP.

Example

nginx built with HTTP/3 support can serve QUIC next to TCP with the same certificate:

server {
    listen 443 ssl;
    listen 443 quic reuseport;
    http2 on;
    server_name example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;
    add_header Alt-Svc 'h3=":443"; ma=86400';
}

Common misconceptions

• QUIC needs a special certificate. Any certificate that works for HTTPS works for QUIC.
• QUIC is plain UDP, or uses DTLS. QUIC always encrypts and uses the TLS 1.3 handshake directly, not DTLS; there is no plaintext mode and no older TLS version.
• HTTP/3 replaces the TCP listener. Browsers usually connect over TCP first and switch to QUIC after discovering it, so both listeners are needed.