TCP vs UDP: What's the Difference and When Each Is Used

Every time you load a page, send a message, or join a video call, your data is broken into packets and handed to one of two protocols for delivery. One of them checks that every packet arrives, puts them back in order, and re-sends anything that goes missing. The other fires packets off and never looks back. They are TCP and UDP, and the quiet choice between them shapes how fast, and how reliable, an application feels.

Both live in the same layer of the network stack, one rung above the IP that carries them. IP knows how to move a single packet from one address to another. It says nothing about whether that packet actually arrives, or what order a series of them shows up in. TCP and UDP are the two standard answers to that gap, and almost every application you use picks one of them.

This guide explains what each protocol really does, why TCP's guarantees cost something, why UDP's silence is sometimes exactly what you want, and how to tell which one a given service is running on.

Two ways to send data#

TCP, the Transmission Control Protocol, is connection-oriented. Before any real data moves, the two sides formally agree to talk. Its current specification is RFC 9293, published in 2022, which consolidated the original 1981 standard and the two decades of fixes layered on top of it. TCP's promise to the application above it is simple to state and expensive to keep: whatever bytes you hand me, I will deliver to the other end reliably, in order, with nothing missing and nothing duplicated.

UDP, the User Datagram Protocol, is connectionless. It is defined in RFC 768 from 1980, a document so short you can read it over a coffee. UDP makes no promises at all. It takes your data, wraps it in a tiny header, and drops it onto the network. If the packet arrives, good. If it gets lost, reordered, or duplicated along the way, UDP neither notices nor cares. Any recovery is left to the application.

That difference in philosophy explains everything else about the two protocols. TCP does a lot of work on your behalf and adds some delay in exchange. UDP does almost nothing and stays out of the way. Neither is "better"; they are tuned for different jobs.

How TCP guarantees delivery#

TCP earns its reliability through a set of mechanisms that all run automatically once a connection is open.

It starts with the three-way handshake. To open a connection, the client sends a SYN (synchronise) packet, the server replies with a SYN-ACK, and the client answers with an ACK. Only after that three-message exchange does data begin to flow. The handshake lets both sides agree on the starting sequence numbers they will use to track the conversation, and it is why a fresh TCP connection always carries a small setup cost before the first byte of real content.

Once the connection is up, TCP guarantees delivery with three more tools working together:

• Sequence numbers and acknowledgements. Every byte is numbered. The receiver acknowledges what it has received, so the sender knows exactly what got through and what did not.
• Retransmission. If an acknowledgement does not come back in time, the sender assumes the data was lost and sends it again. This is the core of "reliable" delivery.
• Ordering. Because every byte is numbered, the receiver can reassemble packets that arrived out of order into the exact stream the sender produced.

On top of that, TCP adds flow control, which stops a fast sender from overwhelming a slow receiver, and congestion control, which backs off when the network itself looks overloaded. Each segment also carries a checksum, so corrupted data is detected and re-sent rather than silently accepted. All of this is invisible to the application. You write bytes into a socket at one end and read the same bytes out at the other, and TCP handles the messy reality of a lossy network in between.

How UDP stays out of the way#

UDP is defined almost entirely by what it does not do. There is no handshake, so there is no setup delay. There are no sequence numbers, no acknowledgements, and no retransmission, so a lost packet stays lost. There is no ordering, so packets can arrive in any sequence. There is no flow or congestion control, so UDP will happily keep sending as fast as the application asks it to.

What UDP gives you in return is speed and simplicity. A single UDP packet, called a datagram, is self-contained: it goes out immediately with no negotiation, and there is no connection state to set up, maintain, or tear down. For anything where the newest data matters more than the completeness of old data, that trade is worth making.

Think about a live voice call. If one packet carrying 20 milliseconds of audio goes missing, retransmitting it is pointless, because by the time the copy arrives the conversation has already moved on. A tiny gap in the sound is far less disruptive than a stall while the network waits for stale data. UDP lets the application make exactly that choice, where TCP would insist on waiting for the missing piece.

The headers, side by side#

The clearest way to see the gap between the two protocols is to look at what each one attaches to your data.

A UDP header is just 8 bytes, holding four fields of 16 bits each: source port, destination port, length, and checksum. That is the entire protocol. The checksum field is always present, but on IPv4 it is technically optional: a sender that leaves it as all zeros is signalling that it computed no checksum. In practice it is almost always used, and over IPv6 the rules are stricter, an originating node must compute the checksum, and a received packet with a zero checksum is discarded.

A TCP header is 20 bytes at minimum and can grow to 60 bytes when options are present. Those extra bytes are where all the machinery lives: the sequence and acknowledgement numbers, the window size for flow control, the control flags (SYN, ACK, FIN, and the rest), and the options that negotiate features like window scaling. UDP simply has nowhere to put any of that, which is the point. A smaller header means less overhead per packet and nothing to track.

One thing the two headers share is the pair of port numbers. Both use a 16-bit source port and a 16-bit destination port, which is how a single machine keeps dozens of separate conversations straight: the operating system routes each incoming packet to the right program based on the destination port it names.

What each one is used for#

TCP is the default for anything where every byte has to arrive intact. That covers the majority of what most people do online:

• Web browsing over HTTP and HTTPS (HTTP/1.1 and HTTP/2), where a half-downloaded page is useless.
• Email transport over SMTP, along with IMAP and POP for retrieval.
• File transfers, remote shells over SSH, and essentially any protocol where a single dropped byte would corrupt the result.

UDP is the choice when timeliness beats completeness, or when the exchange is so small that a handshake would be pure overhead:

• Live audio and video: voice calls, video conferencing, and much of the real-time streaming that would rather skip a frame than pause.
• Online gaming, where the position of a player half a second ago is not worth resending.
• DNS lookups, which are usually a single small question and answer. DNS runs on port 53 over UDP by default and falls back to TCP when a response is too large to fit, most often above the original 512-byte limit or when the truncation flag is set. Under RFC 7766, supporting both transports is now a required part of any full DNS implementation.

The interesting modern twist is QUIC, the transport underneath HTTP/3. QUIC deliberately runs over UDP, then rebuilds reliability, ordering, and congestion control on top of it in a faster, more flexible form than TCP allows. It is a reminder that "UDP is unreliable" describes the protocol's defaults, not a limit on what you can build with it.

Same port number, different protocol#

A common point of confusion: TCP and UDP maintain separate port number spaces. Port 53 on TCP and port 53 on UDP are two different endpoints, and a service can listen on one, the other, or both. DNS famously uses both. HTTPS traditionally means TCP port 443, but the same number 443 over UDP is where QUIC and HTTP/3 live, which is how a browser can quietly upgrade to HTTP/3 without changing the address in the bar.

This is why a good port reference always tells you the protocol alongside the number. Our port lookup treats each protocol as its own entry, so looking up a well-known port shows what runs on the TCP side, the UDP side, or both, together with the service name and any security notes. If you are auditing what a server exposes rather than just naming a port, the companion guide on open ports and exposure walks through why an unexpected listener matters. For the specific case of web traffic, port 80 vs port 443 covers the HTTP and HTTPS pair in more depth.

How to choose between them#

If you are ever deciding which protocol an application should use, the question is short: does every byte have to arrive, in order, even at the cost of waiting? If yes, use TCP and let it handle the retransmissions and ordering for you. If the freshest data matters more than a complete history, and your application can tolerate or repair the occasional gap itself, UDP will get out of your way and give you lower latency.

For almost everyone, though, the choice is already made by the software they run. Your browser, mail client, and SSH tool speak TCP; your video calls, games, and DNS resolver lean on UDP. Knowing which is which turns a lot of otherwise mysterious behaviour, why a download resumes cleanly but a call drops a syllable, into something you can reason about.