4.3.26 · D1Computer Networks

Foundations — HTTP - 3 — QUIC, UDP-based, why

1,752 words8 min readBack to topic

Before you can appreciate why HTTP/3 exists, you must be fluent in the vocabulary the parent note throws at you: packets, RTT, streams, handshakes, the 4-tuple, probabilities like . This page builds every one of them from nothing. Read top to bottom — each idea is a brick for the next.


1. What is a "packet"?

The picture to hold in your head: instead of mailing one giant crate, you mail a stack of numbered postcards. Each postcard finds its own way and might arrive out of order — or not at all.

Why the topic needs this: everything about HTTP/3 — loss, retransmission, head-of-line blocking — is a story about individual packets arriving, getting lost, or getting stuck. If you think of a web page as one solid file, none of the arguments make sense.


2. Round-trip time:


3. A "handshake" (and why TCP needs one)

TCP's handshake is a 3-way exchange: SYN → SYN-ACK → ACK. Count the arrows: you send, they reply, you confirm. That confirming message can carry your first data, so the effective waiting cost is one round-trip. See TCP — three-way handshake and reliability for the full walk-through.

The key takeaway for HTTP/3: this handshake is pure overhead — you are not yet loading the page, you are just introducing yourselves. QUIC's whole setup argument is about cutting these introductions down.


4. Reliability, ordering, and the "single ordered stream"

These two are separate promises, and confusing them is the classic trap. UDP has neither; TCP has both; QUIC rebuilds both on top of UDP but applies ordering per stream instead of across the whole connection.


5. Streams and multiplexing

The whole HTTP/2-vs-HTTP/3 drama lives in this figure. HTTP/2 multiplexes many streams but then squeezes them through one ordered TCP pipe — so a lost packet jams the shared pipe and every stream waits (this is Head-of-line blocking). QUIC keeps the streams genuinely independent: a lost packet only jams its own lane. Compare with HTTP-2 — multiplexing and HPACK to see what HTTP/2 fixed and what it left broken.


6. The 4-tuple (how a connection is identified)


7. The probability symbols: , , and

The parent note's "HOL stall" section uses probability. Let's earn every symbol.

Now the formula , built step by step:


8. The layer stack (where each piece sits)

The one thing HTTP/3 changed is the transport layer: it swapped TCP for QUIC-over-UDP, and folded encryption (TLS 1.3 — handshake and 0-RTT) directly into that transport. Everything above (GET, headers, 200 OK) is untouched. See also Congestion control — slow start, AIMD for the "don't flood the network" service that QUIC also rebuilds, and Middlebox ossification and protocol evolution for why it had to be built on UDP rather than a fresh protocol.


Prerequisite map

Packet - a labelled data chunk

RTT - one round trip

Reliability - detect loss and retransmit

In-order delivery

Streams and multiplexing

Handshake - setup cost in RTT

Loss model p and N

Head-of-line blocking

4-tuple connection identity

Connection migration

HTTP-3 over QUIC-UDP

Protocol layers


Equipment checklist

A packet is...
a small labelled chunk of data that travels the network on its own and may arrive out of order or get lost.
means...
round-trip time — one packet out to the server and its reply back.
Why do we count setup in round-trips?
because each "ask and wait for reply" costs one of pure waiting before real data flows; .
A handshake is...
the opening back-and-forth two computers do to agree they're both ready, before sending real data.
Reliability vs in-order delivery
reliability = lost packets get retransmitted; in-order = bytes released only in original order. They are independent promises.
A stream is...
one independent byte-sequence with its own ordering; one HTTP request/response lives in one stream.
Multiplexing is...
interleaving many streams over one connection at once.
The 4-tuple is...
(your IP, your port, server IP, server port) — the four numbers that name a TCP connection; change one and TCP sees a new connection.
and mean...
= per-packet loss probability (0 to 1); = number of objects/streams sent.
computes...
the probability that at least one of packets is lost.
For this is about...
(a 92% chance of at least one loss).