Same IP underneath. Two very different promises.
UDP adds ports, a length and a checksum, then stops. TCP adds sequence and acknowledgment numbers, flags and a window, so it can resend, reorder and pace.
Is UDP simply faster?
Bad: “UDP is just faster”
On a warm connection, TCP answers in one round trip too.
Good: Lose it, or wait?
UDP wins only when you’d rather lose data than wait for it.
240 ms
to first byte on a new HTTPS connection
Say a round trip from Delhi to Singapore takes 80 ms. TCP handshake, TLS 1.3, request — three of them. A faster link won’t help.
One lost packet stalls everything behind it
TCP hands bytes over strictly in order, so requests that already arrived wait for the resend. QUIC stalls only the stream that lost data.
Middleboxes drop unfamiliar protocols; operating systems update slowly. How do you ship a better TCP?
QUIC
Build it on UDP, in user space. Setup with TLS takes one round trip; a loss stalls only its stream.
One video call, three transports
Choose per data flow. Join and mute must arrive in order; a resent video frame arrives too late to play. Blocked UDP falls back to TCP.
On UDP, the rest is your job
- Number datagrams; newest wins, late ones drop
- Pace your sends: there’s no congestion control
- Never answer small requests with big replies
- Keep a TCP fallback for blocked UDP
Remember
Every byte must arrive, in order: TCP, or QUIC with HTTP/3. Late data is useless: UDP. Choose per data flow, and reuse connections, because setup costs round trips.