QUIC

Why YouTube reaches your browser over UDP, not TCP

QUIC is a transport protocol that does TCP's job (reliable, ordered delivery with congestion control) inside UDP, the bare 'send a packet and forget it' protocol. HTTP/3 is simply HTTP running over QUIC.

QUIC uses UDP because TCP is built into every operating system's kernel, so changing it takes years, and firewalls often block any protocol that isn't TCP or UDP.

Inside UDP, QUIC adds its own packet numbers, acknowledgements, resends and congestion control, and encrypts almost everything. It runs as a library in the browser or server, so it updates like any app.

QUIC

Open Chrome DevTools on YouTube and the Protocol column says “h3”

Load YouTube or Google Search in Chrome, open DevTools → Network and show the Protocol column: many requests say “h3”, meaning HTTP/3 over QUIC. Cloudflare and other big sites offer it too.

The browser often first connects over TCP, where the server advertises HTTP/3 support; later requests switch to QUIC. If a network blocks UDP, the browser quietly falls back to TCP.

QUIC

One lost packet only stalls the image it belonged to

TCP delivers one ordered byte stream, so if a page fetches three images and a packet of image 2 is lost, images 1 and 3 also wait for the resend. This is head-of-line blocking.

QUIC gives each request its own stream and orders bytes only within a stream. So images 1 and 3 keep arriving, and only image 2 waits for its missing packet.

QUIC also does transport and TLS 1.3 setup in one round trip instead of two, or zero for a returning visitor. And a connection ID, not the IP address, names the connection, so it survives a switch from Wi-Fi to mobile data.