TCP vs UDP: How the Internet's Transport Protocols Differ
Almost everything you do online travels over one of two transport protocols. The TCP vs UDP choice comes down to a simple trade-off: careful reliability versus raw speed.
When your device sends data across the internet, the raw information is wrapped up and handed to a transport protocol that decides how it should be delivered. The two workhorses of the modern internet are TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). The TCP vs UDP decision shapes how a web page loads, how a video call sounds, and whether a lost packet gets noticed or quietly ignored. Both sit on top of the IP addressing system that gets data to the right machine, and both use port numbers to reach the right program on that machine.
What TCP and UDP actually do
IP, the Internet Protocol, is very good at one thing: getting a packet from one address to another. What it does not promise is that packets arrive in order, arrive only once, or arrive at all. That is where the transport layer steps in. TCP and UDP are two different answers to the same question: given an unreliable delivery service, how should a program send its data?
TCP treats a conversation like a phone call. Before any real data flows, the two sides agree to talk, and from then on TCP tracks every byte, re-sends anything that goes missing, and puts everything back in the right order. UDP treats a message more like a postcard. It writes the address, drops the packet in the mail, and moves on without waiting to hear whether it arrived.
How TCP works: the reliable connection
TCP is a connection-oriented protocol. It begins with a three-step exchange known as the three-way handshake, often summarised as SYN, SYN-ACK, ACK. In plain terms, one side says "let's talk," the other says "sure, let's talk," and the first side confirms. Only then does data begin to flow.
Once the connection is open, TCP does a lot of quiet bookkeeping:
- Acknowledgements: the receiver confirms the data it got, so the sender knows what still needs re-sending.
- Ordering: each segment carries a sequence number, so data that arrives out of order is reassembled correctly.
- Retransmission: if an acknowledgement never comes back, TCP assumes the data was lost and sends it again.
- Flow and congestion control: TCP slows down when the network is busy and speeds up when there is room, to avoid overwhelming the path.
All of this makes TCP dependable, which is exactly what you want for a web page, an email, or a file download where a single missing byte could corrupt the result.
How UDP works: fire and forget
UDP is connectionless. There is no handshake and no ongoing conversation. A program simply builds a small message, called a datagram, and sends it. UDP adds only a thin wrapper: the source and destination ports, a length, and a checksum to catch obvious corruption. It does not track what was sent, does not re-send lost packets, and does not care about order.
That sounds careless, but it is a feature. For live audio and video, a packet that arrives late is useless anyway, so there is no point stopping everything to re-send it. Skipping all the bookkeeping means UDP has far less overhead and much lower delay. If reliability is needed, the application itself can add just the pieces it wants on top, which is exactly what modern protocols like QUIC do.
TCP and UDP each maintain their own separate set of 65,535 port numbers. That is why a service like DNS can listen on UDP port 53 and TCP port 53 at the same time without any conflict.
TCP vs UDP at a glance
| Characteristic | TCP | UDP |
|---|---|---|
| Connection | Connection-oriented (handshake first) | Connectionless (no setup) |
| Reliability | Guaranteed delivery, re-sends lost data | Best effort, no re-sends |
| Ordering | Data arrives in order | No ordering guarantee |
| Speed / overhead | Higher overhead, more delay | Low overhead, low delay |
| Data flow | Continuous byte stream | Individual datagrams |
| Typical uses | Web, email, file transfer | Video calls, live streaming, gaming, DNS |
Which one gets used where
You rarely choose TCP or UDP yourself; the application does it for you. But knowing which is which explains a lot about how the internet feels.
TCP carries most of the traffic you think of as "the web." When you load a page over HTTP or HTTPS, download a file, send an email, or connect to a server over SSH, TCP is doing the work. Its reliability is worth the extra round-trips because you would rather a page load correctly than load slightly faster with holes in it.
UDP shines when timeliness beats completeness. Voice and video calls, live streaming, online games, and many DNS lookups favour UDP because a fresh-but-slightly-lossy stream feels better than a perfect one that stutters and buffers. A dropped frame in a video call is gone in a blink; waiting to re-send it would only make the whole conversation lag.
The line has blurred in recent years. HTTP/3 runs on QUIC, which is built on UDP but layers on its own reliability and encryption, so it captures UDP's speed while keeping TCP-style guarantees. It is a reminder that the two protocols are tools, not tribes.
Where TCP and UDP fit in the bigger picture
Both protocols live at the transport layer, one rung above IP in the networking stack. If you picture data moving as described in how data travels the internet, IP handles the addressing and routing between machines, while TCP or UDP handles what happens to the data once it arrives at the destination host. Together with ports, they let a single computer juggle dozens of conversations at once without mixing them up. For the full layered view, the OSI model is a helpful map.
The next time a video call stays smooth while a download crawls, or a web page loads perfectly while a game shrugs off a hiccup, you are watching the TCP vs UDP trade-off in action. Want to see the addressing side of the story? Head back to IP Animals to check your own IP.
Frequently asked questions
Is TCP or UDP faster?
UDP is generally faster because it skips the connection setup, acknowledgements and retransmissions that TCP performs. That lower overhead is why UDP suits live audio and video, where a tiny bit of lost data matters less than staying up to date.
Does HTTPS use TCP or UDP?
Traditional HTTP and HTTPS run over TCP. Newer HTTP/3 uses a protocol called QUIC that is built on top of UDP but adds its own reliability and encryption, so it gets UDP's speed with TCP-like guarantees.
Can the same port number be used for both TCP and UDP?
Yes. TCP and UDP keep separate sets of port numbers, so a service could listen on TCP port 53 and UDP port 53 at the same time without conflict. DNS is a real example that uses both.
Why does DNS use UDP?
Most DNS lookups are short question-and-answer exchanges that fit in a single packet, so UDP's low overhead makes them fast. DNS falls back to TCP for larger responses or zone transfers where reliability and size matter more.