Back in the OSI post I mentioned that Layer 4's whole job is service-to-service delivery — making sure data reaches the right application on a host, not just the right machine — and that TCP and UDP are the two strategies for doing it. This post is that comparison properly unpacked, because "TCP is reliable, UDP is fast" is the kind of half-explanation that sounds fine until someone asks you what "reliable" actually means at the protocol level, and you realize you don't quite know.
Difference 1: Connection-Oriented vs. Connectionless
TCP is connection-oriented — a TCP conversation has an official start and an official end. Before any actual data moves, the two hosts perform a handshake: one side signals it wants to start talking, the other confirms it's ready, and only then does data start flowing. When the conversation is done, both sides explicitly signal that they're finished. This is the well-known three-way handshake (SYN, SYN-ACK, ACK) you'd see if you opened Wireshark and watched any HTTPS connection begin.
UDP has no such thing. There's no handshake, no formal start, no formal end — a host that wants to send UDP data simply puts it on the wire and moves on. This raises a genuinely interesting question: if there's no official start or end, how do you even define "a UDP connection"? In practice, engineers define it based on a timeout window: any packets sharing the same five-tuple — source IP, source port, destination IP, destination port, and protocol — that arrive within a certain time window of each other are treated as belonging to the same logical connection. That timeout isn't standardized; different vendors and pieces of software use different values, though two minutes is a fairly common default.
Difference 2: TCP's Reliability, Broken Into Three Actual Parts
"TCP is reliable" gets thrown around constantly without anyone explaining what it actually means. It breaks down into three distinct guarantees:
1. Confirmation of delivery. Every time TCP data arrives at the receiving host, that host sends back an acknowledgment. This means the sender always knows whether its data actually got there — and if the expected acknowledgment never arrives, the sender knows something went wrong and can surface that as an error to the application (and from there, to the user). UDP has none of this. A UDP sender puts data on the wire and has no idea, at the protocol level, whether it ever arrived.
2. In-order delivery. Applications hand data to TCP in a certain order, and TCP labels each chunk with a sequence number before sending it. This matters because packets crossing the internet don't necessarily all take the same path — one packet might race across a fast route while another takes a slower, more congested one — so they can genuinely arrive out of order. Because TCP labeled them with sequence numbers, it can reassemble them in the correct order before handing the data to the application, regardless of the order they actually arrived in. UDP has no built-in sequencing at all; if an application using UDP cares about order, it has to handle that itself, or simply not care (a file download doesn't care which byte arrives first, as long as every byte arrives eventually).
3. Awareness of errors. Because of the confirmation mechanism above, TCP knows when something has gone wrong with a transmission and can notify the application. UDP has no equivalent mechanism at Layer 4 — if something goes wrong, UDP itself never finds out, though the application built on top of it might implement its own detection if it needs to.
Difference 3: Flow Control
TCP dynamically adjusts its transmission rate to use as much of the available bandwidth as it safely can, without exceeding it. It starts conservatively, gradually increases its sending rate, and backs off when it detects packet loss — settling into a rhythm that roughly tracks whatever bandwidth is actually available across the entire path, not just the sender's local connection.
UDP does none of this. It sends data as fast as the local connection allows, with no awareness of what the rest of the path can actually handle. If the sender's local link has more bandwidth than a narrower link further along the route, UDP will happily blast data at a rate the far end can't sustain — and the excess simply gets dropped. This is a genuine trade-off, not a flaw: for something like a live video call, sending your best current frame and letting a late one simply get dropped is often preferable to TCP's approach of slowing everything down to guarantee every single frame arrives.
Difference 4: Header Overhead
All of TCP's extra functionality — sequencing, acknowledgment, flow control — has to be tracked somewhere, and that somewhere is the header attached to every single segment.
A UDP header is minimal: source port, destination port, a length field, and an optional checksum — eight bytes total.
A TCP header is significantly larger: source and destination port like UDP, plus sequence numbers, acknowledgment numbers, flags, window size, a mandatory checksum, and more — a minimum of 20 bytes, and up to 60 bytes when optional fields are included. This is the direct, physical cost of everything TCP does that UDP doesn't: more features literally means more bytes spent on bookkeeping with every packet sent.
Four Myths Worth Killing Now
Myth: "UDP is faster." Not true — the actual latency of getting a packet from one host to another is identical regardless of protocol; the network doesn't move UDP packets any quicker than TCP packets. What people actually mean is that UDP has less overhead, which is a real and true statement — it's just a different claim than "faster."
Myth: "TCP is more secure." Also not true, and worth being firm about: neither protocol provides any security at all. Both are equally unencrypted and equally unauthenticated at Layer 4. If you want actual security, it has to come from somewhere else in the stack — IPsec at Layer 3, or TLS/SSH at the layers above Layer 4. Security is simply not a property either transport protocol has.
Myth: "UDP is unreliable." A more accurate phrasing is that UDP doesn't provide reliability at Layer 4 — the actual odds of a given packet successfully crossing the network are identical whether it's sent via TCP or UDP. The difference isn't that UDP packets are more likely to get lost; it's that TCP tells you when they are, and UDP doesn't. An application built on UDP is free to implement its own reliability on top if it needs to — UDP just doesn't hand it to you automatically the way TCP does.
Myth: "TCP guarantees delivery." TCP can't actually guarantee anything gets delivered — if the underlying network path is broken, a TCP packet is exactly as likely to fail to arrive as a UDP one. What TCP actually guarantees is informed delivery: you will always know whether your data arrived or not. That's a meaningfully different promise than "your data will definitely arrive," and it's worth being precise about the difference.
So Which One Do You Actually Use?
Neither protocol is "better" — they're different trade-offs, and the right choice depends entirely on what the application actually needs:
| Use case | Protocol | Why |
|---|---|---|
| Web browsing (HTTP/HTTPS) | TCP | A missing or scrambled byte in a webpage is unacceptable |
| SSH | TCP | You need every keystroke and every byte, in order, guaranteed |
| Email (SMTP) | TCP | Reliability matters more than speed for message delivery |
| File transfer (FTP) | TCP | A corrupted or incomplete file defeats the purpose entirely |
| DNS queries | UDP | Tiny request/response — retry on failure is cheaper than a full handshake |
| Video/voice calls | UDP | A dropped frame is better than the whole call stuttering to wait for it |
| Live streaming | UDP | Same logic — a late frame is worse than a slightly imperfect one |
| Online gaming | UDP | Position updates arrive constantly; an old one is worthless the moment a newer one exists |
The pattern: TCP wins whenever correctness matters more than timeliness. UDP wins whenever timeliness matters more than perfect correctness. Once you frame it that way instead of "reliable vs. unreliable," picking the right one for whatever you're building stops being a guess.
Where This Fits
This is Layer 4 in full — the piece that decides how data actually moves between two applications, sitting right between the end-to-end IP delivery from Layer 3 and whatever application protocol (HTTP, DNS, SMTP) is riding on top of it. Combined with the last three posts, that's the full path a request takes: physical bits, MAC-to-MAC hops, end-to-end IP routing, and now the actual transport mechanics moving the data between two specific applications. Next time something "feels slow" or "keeps dropping," you now have a real question to ask first: is this even the right transport protocol for what it's trying to do?
Top comments (0)