Concept · Networking & APIs
TCP vs UDP
Reliable ordered streams versus fire-and-forget datagrams, and why HTTP/3 runs on UDP.
TCP and UDP are the two transport protocols almost everything on the internet runs on. They make opposite trade-offs.
| TCP | UDP | |
|---|---|---|
| Connection | Handshake first (1 round trip) | None: just send |
| Delivery | Reliable: lost segments are retransmitted | Best effort: lost datagrams stay lost |
| Order | Bytes arrive in order | Datagrams may arrive in any order |
| Shape | A byte stream; the application must frame messages | Discrete datagrams |
| Flow and congestion control | Built in | Up to the application |
| Typical uses | HTTP/1.1 and HTTP/2, databases, SSH | DNS, video calls, games, QUIC (HTTP/3) |
TCP's hidden cost: head-of-line blocking
Because TCP delivers bytes strictly in order, one lost packet holds up everything behind it until the retransmission arrives, even data that belongs to unrelated requests sharing the connection. On a lossy mobile network that stalls every stream on the connection.
Why HTTP/3 uses UDP
QUIC, the transport under HTTP/3, runs on UDP and rebuilds reliability, ordering and congestion control itself — per stream. A lost packet only delays the stream it belonged to. QUIC also combines the transport and TLS handshakes (one round trip, or zero for a resumed connection) and survives a client changing networks, because connections are identified by an ID rather than by IP address and port.
Choosing in a design
- Use TCP (through HTTP, gRPC or a database protocol) for almost everything; you get reliability for free.
- Use UDP when late data is useless — live audio, video, game state — so retransmitting it would only add delay, or when you're using a protocol such as QUIC that provides its own reliability.
- Remember that "UDP is faster" is only true when you don't need what TCP provides; rebuilding reliability badly on UDP is slower than TCP.
See HTTP/1.1, HTTP/2 and HTTP/3; the DevSecOps roadmap's networking lesson covers TCP/IP in depth.