TCP and UDP are the two ways to actually move bytes over IP, and they make opposite trade-offs: TCP guarantees delivery and order at the cost of latency; UDP is fast and simple but delivers nothing you don't explicitly build yourself.
3 min read
Both TCP and UDP sit at the transport layer, both move data between two ports — but they solve "how do I actually deliver bytes reliably" in opposite ways, and almost every "should this use TCP or UDP" question in system design comes down to one question: does losing or reordering a piece of data matter for this use case?
TCP (Transmission Control Protocol) guarantees three things UDP doesn't:
The cost is a real one: establishing a TCP connection requires a handshake before any data moves at all (the next lesson covers this in detail), and a single lost packet can stall everything behind it until it's retransmitted — even data that arrived perfectly fine, a problem called head-of-line blocking that HTTP/2 and HTTP/3 both specifically try to work around (covered two lessons ahead).
UDP (User Datagram Protocol) just fires packets ("datagrams") with no handshake, no acknowledgment, and no guaranteed order. A packet might arrive, arrive twice, arrive out of order, or never arrive at all — UDP itself does nothing about any of that. Anything you actually need on top (retries, ordering) has to be built by the application itself, which sounds worse until you realize: for some use cases, you specifically don't want automatic retries.
A live video call losing one frame from a second ago and retransmitting it late is worse than just dropping it and moving on — a stale frame is useless once the moment has passed. This is exactly why video/voice calls, competitive online gaming, and live-streaming protocols build on UDP: a dropped packet just means a tiny, brief glitch, rather than TCP's alternative of freezing everything until the lost packet is resent and order is restored.
DNS (from two lessons ago) also defaults to UDP — a single DNS query and response is small enough to usually fit in one packet, so TCP's setup overhead would often cost more than the data transfer itself. (DNS does fall back to TCP for larger responses, like zone transfers between nameservers.)
| Use TCP when... | Use UDP when... |
|---|---|
| Every byte matters (file transfer, an API response, a database query) | A late or duplicate value is worse than a missing one (live video/audio) |
| Order matters and can't be reconstructed by the app | The app can tolerate loss, or reconstructs order itself |
| You're building on HTTP (which itself runs on TCP, or QUIC — see HTTP/3) | Latency matters more than completeness |
In practice, as an application developer you rarely choose TCP or UDP directly — you choose a higher-level protocol (HTTP, WebSocket, a video-calling SDK) that has already made this decision for its specific use case. Knowing why it made that choice is what turns "this protocol is just what everyone uses" into an actual understanding of the trade-off underneath it.
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. Why might a live video call deliberately use UDP instead of TCP?
2. Which of these is NOT one of TCP's guarantees over UDP?
3. Why does DNS typically use UDP rather than TCP for ordinary queries?
Networking Fundamentals