TCP vs UDP: What the Difference Actually Means

Two computers want to talk over the internet. Before they can, they have to agree on how. Do they carefully confirm every message got through, resending anything that dropped, or do they just blast data across the wire and accept that some of it will vanish? That single choice is the whole story of TCP vs UDP, the two transport protocols nearly all internet traffic runs on.

Here is the short version. TCP is the careful one. It sets up a connection, numbers everything, waits for confirmation, and resends whatever got lost, so your data arrives complete and in order or not at all. UDP is the fast one. It fires off packets and never looks back, no setup, no confirmation, no resending. Most people learn this as “TCP is reliable and UDP is unreliable” and stop there. That framing is technically fine and completely misses the point, because the “unreliable” one is what your video calls, your games, and increasingly the web itself are built on.

What both of them actually sit on top of

Before TCP or UDP enter the picture, there is IP, the Internet Protocol. IP is the part that gets a packet from one address to another across the network. It is genuinely unreliable in the plain engineering sense: a packet can get lost, arrive out of order, or show up twice, and IP does nothing about it.^[1] IP is just the postal system moving envelopes. It does not promise delivery.

TCP and UDP are the two ways of dealing with that. They both ride on top of IP, and they represent the two honest answers to the question “IP might drop my data, now what?” TCP says: I will build a reliable layer on top and handle every failure for you. UDP says: I will not, that is your problem, here is your speed back. Neither is wrong. They solve different problems.

TCP: the handshake and the promise

TCP is connection-oriented, which means before any real data moves, the two sides shake hands. It is a three-step exchange: one side sends SYN, the other replies SYN-ACK, the first sends ACK.^[2] Only after that round trip does the actual conversation start. That handshake is TCP setting up shared state, sequence numbers and buffers, so both ends can track exactly what has been sent and what has been received.

Once the connection is up, TCP makes a real promise. Every byte is numbered. The receiver acknowledges what it got. If an acknowledgement does not come back, TCP assumes the data was lost and sends it again. If packets arrive out of order, TCP reassembles them into the right sequence before handing them to your application.^[2] You get a clean, ordered stream of bytes, exactly what was sent, in the order it was sent. Your application never sees the mess underneath.

That reliability is not free. The handshake costs a round trip before anything useful happens. The acknowledgements and retransmissions add overhead and, worse, they add waiting. If one packet in a stream goes missing, everything behind it has to wait for the resend before your application sees any of it. That is head-of-line blocking, and it is the price TCP pays for perfect order.

UDP: fire and forget on purpose

UDP is the opposite philosophy. It is connectionless, so there is no handshake. You do not open a session, you just send a datagram to an address and port, and it goes.^[3] No setup round trip, no shared state to establish. The first packet carries real data instead of a hello.

And UDP makes no promises. It does not number packets, does not wait for acknowledgements, and does not resend anything. If a datagram gets lost, UDP never knows and never cares. Packets can arrive out of order or not at all, and it is entirely up to your application to notice and decide whether that matters.^[3] The header is tiny, just source port, destination port, length, and a checksum, which is a big part of why it is so lightweight.

This sounds reckless until you think about what a lot of applications actually need. A live video frame from two seconds ago is worthless. A game position update that is now stale helps nobody. For that kind of data, waiting on a retransmission is worse than just dropping the packet and using the next fresh one. UDP hands you that option. TCP does not.

Where each one wins

The split follows one question: does every byte have to arrive, or does fresh data matter more than complete data? If you need every byte, you need TCP. Loading a web page over HTTP and HTTPS, sending email, transferring a file, running a database query. A single missing or scrambled byte would corrupt the whole thing, so ordered, guaranteed delivery is non-negotiable. That is TCP territory, and it is most of what people think of as “the internet.”

UDP owns the other half. Live video and audio streaming, online multiplayer games, voice and video calls over VoIP, and DNS lookups all run on UDP.^[3]DNS is a great example of why. A DNS query and its answer each fit in a single small packet, so opening a full TCP connection with a handshake just to ask “what is the IP for this domain” would be pure overhead. UDP sends the question, gets the answer, done. If the answer never comes back, the resolver just asks again.

The plot twist: the modern web moved to UDP

Here is the part that surprises people. For decades, the web was TCP, full stop. HTTP/1.1 and HTTP/2 both ride on TCP. Then Google, and later the IETF, did something that sounds backwards: they rebuilt web transport on top of UDP.

That rebuild is QUIC, and HTTP/3 runs on it.^[4] The logic is sharp once you see it. TCP's reliability is great, but its guarantees are baked into the operating system kernel and slow to change, and its head-of-line blocking hurts when you are loading dozens of resources at once. So QUIC starts from UDP, which gives it a fast, minimal base with no built-in rules, then rebuilds reliability, ordering, and congestion control itself in user space, where it can iterate and tune per-stream.^[4] It gets TCP's guarantees plus faster connection setup and no cross-stream blocking. The connection speaks directly to how a CDN shaves latency off every request, because the transport handshake is one of the round trips they are fighting to eliminate.

Why UDP being “dumb” is the feature

The way I think about it, TCP and UDP are not a quality ladder with TCP on top. They are two starting points. TCP hands you a fully built reliability system and says take it or leave it. UDP hands you a blank slate and says build what you need. Most of the time you want TCP's prebuilt guarantees and you should just use them. But when you have specific needs, a game that wants the newest position and does not care about old ones, a video call that would rather glitch for a frame than freeze for a second, a web transport that wants per-stream reliability without kernel-level blocking, UDP's refusal to make decisions for you becomes the advantage.

This is the same pattern you see all over good systems design. The lower, dumber layer that makes no assumptions ends up more useful than the smarter one, because everyone can build their own thing on top of it. IP is dumber than TCP and it is the foundation of the entire internet. An Ethernet cable does not know or care whether it is carrying TCP, UDP, or QUIC, and that ignorance is exactly why it works for all of them. Simplicity at the bottom buys flexibility at the top.

What I'd do

If you are building something and wondering which one to reach for, the default is easy. Use TCP. Almost everything you write, an API, a web service, a database client, wants guaranteed ordered delivery, and TCP hands it to you for free. Do not reinvent reliability you can get from the operating system. Ninety percent of the time, TCP is the correct and boring answer, and boring is good.

Reach for UDP when you have a real reason: latency-sensitive real-time data where stale packets are worthless, tiny request-response exchanges like DNS where a handshake is pure waste, or a case where you genuinely need to build your own delivery logic on a minimal base, which is what QUIC did. And drop the habit of calling UDP “unreliable” like it is an insult. It is not a worse TCP. It is a different tradeoff, and the fact that the modern web now runs on it through QUIC should settle the argument. UDP was never the weak sibling. It was the clean foundation the smart stuff got built on.