TCP vs UDP vs QUIC

Published 18 October 2026

TCP is a registered post parcel. Every piece is numbered, the receiver confirms what arrived, anything lost is sent again, and the pieces are handed over in order. UDP is throwing leaflets from a moving car. Each leaflet goes on its own, some never land, some land out of order, and nobody keeps track. QUIC is a courier company that took the leaflet truck and built its own tracking system on top, so it gets the reliability of the parcel service without the parcel service's slow paperwork.

All three sit at the transport layer, between IP (which only moves packets from one machine to another, with no promises) and your application.

TCP: reliable, ordered, careful#

TCP gives your application a byte stream: what you write on one end comes out the other end complete and in order, or the connection fails. To do that it:

• Opens a connection with a three way handshake (SYN, SYN-ACK, ACK) before any data.
• Numbers every byte, has the receiver acknowledge them, and retransmits what is not acknowledged.
• Hands bytes to the application strictly in order. If packet 5 is lost, packets 6 to 50 wait in a buffer until 5 arrives.
• Runs flow control (do not overwhelm the receiver) and congestion control (do not overwhelm the network), slowing down when it sees loss.

That is exactly what you want for a web page, an API response, a file or a database query, where a missing byte means a corrupt result. It is the transport under HTTP/1.1 and HTTP/2, SSH, SMTP, PostgreSQL and MySQL.

UDP: send and forget#

UDP adds almost nothing to IP: port numbers and a checksum, an 8 byte header. No handshake, no acknowledgements, no ordering, no retransmission, no congestion control. Each datagram is on its own.

That sounds bad until you meet data that is worthless once it is late. A video call frame from 200 ms ago, a player's position from three updates back, a sensor reading that has been superseded: resending them wastes time on data nobody wants. UDP lets the application decide what is worth recovering. DNS uses it because a query and its answer each fit in one packet and the client can simply ask again. Video calls (WebRTC in Google Meet and WhatsApp calls), online games, VoIP and live streaming protocols build on it.

QUIC: TCP's guarantees, rebuilt on UDP#

TCP is implemented in operating system kernels and in every router and middlebox on the internet, which makes it nearly impossible to change. Google started QUIC around 2012 to get around that by building a new transport on top of UDP, in user space, where it can evolve with an app update. The IETF standardised it in 2021 (RFC 9000), and HTTP/3 runs on it.

What it changes:

• TLS 1.3 is built in. The transport handshake and the encryption handshake happen together, so a new connection costs one round trip instead of two. A returning client can send data in its very first packet (0-RTT).
• Independent streams. One connection carries many streams, and a lost packet only stalls the stream it belonged to. TCP would stall all of them. This is head of line blocking, and it is shown step by step in HTTP/1.1 vs HTTP/2 vs HTTP/3.
• Connection migration. A TCP connection is identified by four values: two IPs and two ports. Walk out of your office WiFi onto 4G and your IP changes, so every TCP connection dies. QUIC identifies connections by a connection ID, so it carries on.
• Encrypted headers. Middleboxes cannot read or tamper with most of the transport, which is also why some corporate firewalls block it and browsers fall back to TCP.

Handshake round trips matter most where round trips are long, which is a lot of the world: a phone on a congested mobile network, or a user in India talking to a server in the US.

In the interview#

Checkpoint#