Ever wonder why a webpage always loads completely or not at all, but a video call gets a bit glitchy and just… carries on? That difference comes down to two foundational protocols: TCP and UDP. Almost everything you do online rides on one of them, and the choice between them is a classic engineering trade-off: reliability vs. speed.
Here's the difference, without the networking-textbook headache.
Two ways to send data
Both TCP and UDP move data between computers. The difference is how much they care about it arriving perfectly.
- TCP (Transmission Control Protocol) is the careful courier. It sets up a connection, delivers everything in order, confirms receipt, and re-sends anything lost. You get every byte, correctly ordered — at the cost of some overhead.
- UDP (User Datagram Protocol) is the fast one. It just fires packets off and doesn't wait for confirmation. No setup, no re-sends, no ordering guarantees — but almost no overhead, so it's quick.
TCP: reliable and ordered
TCP starts every conversation with a handshake (the famous "SYN, SYN-ACK, ACK") to establish a connection. Then, as data flows, it:
- Confirms delivery — the receiver acknowledges packets.
- Re-sends lost packets — nothing goes missing.
- Keeps order — packet 2 always arrives before packet 3.
That's why a web page or a file download is all-or-nothing: TCP guarantees you get the whole thing, intact. The trade-off is the overhead of all that bookkeeping.
UDP: fast and connectionless
UDP skips the ceremony. No handshake, no acknowledgements, no re-sending. It just sends. If a packet gets lost, it's gone — UDP doesn't notice or care.
That sounds bad until you think about a live video call: if one frame's worth of data is lost, you do not want the protocol to stop and re-send it three seconds later. You want it to skip that blip and keep going in real time. For that, "fast and slightly lossy" beats "perfect but late."
Side by side
| TCP | UDP | |
|---|---|---|
| Connection | Handshake first | None — just send |
| Reliability | Guaranteed delivery | Best-effort (may drop) |
| Ordering | In order | No guarantee |
| Speed/overhead | More overhead | Very light, fast |
| Analogy | Registered mail (signed for) | A postcard (sent and forgotten) |
When to use which
| Use TCP for… | Use UDP for… |
|---|---|
| Websites (HTTP/HTTPS) | DNS lookups |
| Live video & voice (VoIP) | |
| File transfers | Online gaming |
| APIs | Live streaming |
The rule of thumb: if every byte must arrive correctly, use TCP. If speed and timeliness matter more than perfection, use UDP.
A nuance worth knowing: the newest version of HTTP, HTTP/3, actually runs over UDP (via a protocol called QUIC) — then rebuilds reliability on top, more efficiently than classic TCP. So the line is blurring at the cutting edge, but the core trade-off still holds.
Why it matters for monitoring
The protocol shapes how you check a service. A TCP check can open a real connection and confirm the port is accepting traffic (and time the handshake). A UDP service is trickier — there's no connection to confirm — so you check it by sending a probe and looking for an expected response. Knowing which protocol a service uses tells you how to watch it.
The bottom line
| In one line | |
|---|---|
| TCP | Reliable, ordered, connection-based — the careful courier. |
| UDP | Fast, connectionless, best-effort — the postcard. |
| Choose by | Need every byte? TCP. Need real-time speed? UDP. |
TCP and UDP aren't competitors so much as two tools for two jobs. Once you know which trade-off each makes, "why does my video glitch but my download never does?" stops being a mystery.
Check if a port is open with the free port checker, and watch TCP/UDP services with network monitoring.