QUIC and HTTP/3 Explained: 1-RTT Handshake, Streams & Inspection Blind Spots (Animated)

QUIC is the modern transport behind HTTP/3, used by Google, YouTube, Meta and most big sites. It runs over UDP, builds TLS 1.3 into the transport, and encrypts almost everything, even the details TCP leaves visible. Faster for users, harder for security tools to inspect.

1. 1-rtt handshake: transport and encryption in one go

The first QUIC packet already carries a TLS 1.3 ClientHello. One round trip later the connection is encrypted and ready.

1. INITIAL (Your laptop → Web server): Padded to at least 1200 bytes to prevent amplification abuse.
2. HANDSHAKE (Web server → Your laptop): The server answers with everything needed to finish.

Wireshark filter:

quic

2. Streams: many requests, no waiting in line

HTTP/3 sends each request on its own stream. If one packet is lost, only that stream waits; with TCP, everything behind the lost packet waits.

1. STREAMS 0,4,8 (Your laptop → Web server): Three requests at once.
2. STREAMS (Web server → Your laptop): Responses arrive independently.

Wireshark filter:

quic.stream_id

3. Inspection blind spot: risk: security tools can’t look inside

Many firewalls, web proxies and data-loss tools inspect HTTPS over TCP. QUIC over UDP often passes them by, so filtering, malware scanning and logging can quietly stop working for that traffic.

1. QUIC (Your laptop → Web server): A large upload over QUIC goes past the data-loss checks that would have caught it over TCP.

Wireshark filter:

udp.port == 443

4. Fall back to tcp: defence: block udp 443 or inspect quic

If your security stack can’t inspect QUIC, block outbound UDP 443. Browsers then fall back to HTTPS over TCP automatically, which your tools can filter and log.

1. INITIAL (Your laptop → Web server): QUIC is blocked.
2. TCP + TLS (Your laptop → Web server): The browser falls back to TCP and the security tools see the traffic again.

Firewall / browser policy:

Deny outbound UDP 443
Managed Chrome: QuicAllowed = false

FAQ