TCP vs UDP: What's the Difference?

What They Are — and Where They Live

Both TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) operate at the Transport layer — Layer 4 in the seven-layer OSI model, or the Transport layer of the four-layer TCP/IP model. Everything below them, at the Network layer, is the job of IP, which addresses and routes packets from one host to another across the network.

The Transport layer's job is different: it manages the conversation between two specific applications. Think of IP as the postal system that gets an envelope to the right building, and TCP or UDP as the mailroom that decides which desk it goes to — and how carefully it's tracked along the way.

Why There Are Two of Them

IP by itself makes no promises. It is best-effort: packets can be lost, duplicated, delayed, or arrive out of order, and IP does nothing to fix any of that. Something has to decide how to handle those imperfections — and different applications want different answers.

That's why the Transport layer offers a choice. TCP is the “clean up the mess for me” option: it detects loss and reordering and repairs them before handing data to the application. UDP is the “just send it and don't slow me down” option. Neither is universally better — they solve the same underlying problem in opposite directions.

How TCP Delivers Reliability

TCP is connection-oriented, which means the two sides establish a connection before any real data flows. They do this with a three-way handshake — SYN, SYN-ACK, ACK — like two people on a phone call saying “hello?” and “yes, I can hear you” before they start talking. Only once both agree the line is open does data transfer begin.

Reliability then comes from a few cooperating mechanisms. Every segment carries a sequence number, so the receiver can reassemble data in the right order and notice if a piece is missing. The receiver sends acknowledgements (ACKs) confirming what it received; anything left unacknowledged is retransmitted. Flow control lets the receiver signal how much it can handle at once, so a fast sender doesn't overwhelm a slow one. All this bookkeeping needs a larger header and extra round-trips — real overhead — but the payoff is data that arrives complete and in order.

How UDP Stays Lean

UDP is connectionless: there's no handshake and no connection to set up. A host simply wraps its data in a datagram and sends it. There are no sequence numbers, no acknowledgements, no retransmissions, and no flow control. If a datagram is lost along the way, UDP neither notices nor cares — recovering from that (or choosing to ignore it) is left entirely to the application.

The reward for giving all that up is speed and simplicity. UDP's header is tiny — just eight bytes — and there's no waiting for handshakes or acknowledgements. It's often described as “fire and forget”: the sender launches the data and moves on.

Ports, and When Each Is Used

Both protocols use 16-bit port numbers to identify which application a piece of data belongs to. If an IP address gets data to the right computer, the port number gets it to the right program on that computer — a web server, a DNS resolver, a game client. The pairing of an IP address and a port is called a socket, and many services listen on well-known ports by convention (HTTP on 80, HTTPS on 443, DNS on 53).

As for choosing: TCP is used where correctness matters more than milliseconds — web browsing (HTTP/HTTPS), email, and file transfers, where a page or file can't be missing pieces. UDP is used where speed and low latency matter more and a little loss is acceptable — DNS lookups, voice and video calls (VoIP), live streaming, and online gaming. In a live call, re-sending a packet from a second ago is useless; it's better to drop it and stay current.

Side by side: TCP is connection-oriented, UDP connectionless; TCP is reliable, UDP best-effort; TCP guarantees ordering, UDP doesn't; TCP carries more overhead, UDP very little; TCP is a bit slower, UDP faster. Same layer, same port concept — opposite priorities.

Common Beginner Gotchas

A few points trip up newcomers. First, “best-effort” doesn't mean UDP is broken or unsafe — it's a deliberate design choice, and for real-time traffic it's usually the right one. Second, TCP and UDP port numbers are separate namespaces: TCP port 53 and UDP port 53 are unrelated, and a single device can listen on both at once, which is exactly what DNS does.

Third, reliability is not the same as security — TCP guarantees delivery, not privacy; encryption such as TLS is a separate layer added on top. Finally, the neat “TCP for files, UDP for real-time” split is increasingly blurred: modern protocols like QUIC (used by HTTP/3) build their own reliability on top of UDP to get the best of both. Treat these as strong tendencies, not unbreakable rules. When you're ready to see it in practice, our step-by-step how-to guides walk through configuring and inspecting this traffic on real gear.