TCP and UDP are the two main ways computers send data over a network. They sit at the same layer (the transport layer) and both use ports, but they behave very differently. This guide explains the difference in plain language, with everyday analogies and real examples.
Table of Contents
The quick analogy
The easiest way to remember the difference:
- TCP is like a phone call. You dial, the other person picks up and says “hello,” and you talk back and forth—each side confirming they heard the other. If the line is noisy, you repeat yourself. Nothing is lost, and everything arrives in order. But setting up the call takes a moment.
- UDP is like mailing postcards (or shouting across a room). You just send your message and hope it arrives. There’s no “hello,” no confirmation, and if a postcard gets lost, you won’t know. But it’s fast and there’s no setup.
Neither is “better”—they’re built for different jobs.
What is TCP?
TCP (Transmission Control Protocol) is connection-oriented and reliable. Before any data is sent, the two computers establish a connection using a three-way handshake:
- The client says “Let’s talk” (SYN).
- The server replies “Okay, let’s talk” (SYN-ACK).
- The client says “Great” (ACK).
Only then does data flow. TCP also numbers every chunk of data, re-sends anything lost, and puts everything back in the right order. For a deeper look, see how a TCP connection works.
TCP guarantees:
- Delivery — lost data is detected and re-sent.
- Order — data arrives in the sequence it was sent.
- Error checking — corrupted data is caught.
The trade-off is a bit more overhead and slightly higher latency.
See the TCP handshake
If you capture traffic while opening a web page, you can watch the three-way handshake:
sudo tcpdump -nni any 'tcp port 443'
IP 192.168.1.10.50432 > 93.184.216.34.443: Flags [S], seq 12345 # SYN
IP 93.184.216.34.443 > 192.168.1.10.50432: Flags [S.], seq 67890, ack 12346 # SYN-ACK
IP 192.168.1.10.50432 > 93.184.216.34.443: Flags [.], ack 67891 # ACK
The [S], [S.], and [.] flags are the handshake—the “hello” of the phone call before any real data is exchanged.
What is UDP?
UDP (User Datagram Protocol) is connectionless and lightweight. There’s no handshake and no confirmation—the sender just fires off a packet (called a datagram) and moves on. If it’s lost, UDP doesn’t notice or resend it.
See also: Mastering the Linux Command Line — Your Complete Free Training Guide
UDP offers:
- Speed — no setup, no waiting for acknowledgments.
- Low overhead — a tiny 8-byte header versus TCP’s 20+ bytes.
- No guarantees — packets can be lost, duplicated, or arrive out of order.
That sounds worse, but for many jobs it’s exactly what you want. In a live video call, re-sending a lost frame from two seconds ago is pointless—it’s better to skip it and keep going. Speed matters more than perfection.
See a UDP exchange
A DNS lookup is a classic UDP example—one question, one answer, no handshake:
sudo tcpdump -nni any 'udp port 53'
IP 192.168.1.10.51520 > 8.8.8.8.53: 12345+ A? example.com. (29)
IP 8.8.8.8.53 > 192.168.1.10.51520: 12345 1/0/0 A 93.184.216.34 (45)
Just a query and a reply—no SYN, no ACK, no setup. (DNS uses UDP for speed; see what is DNS.)
Example: what happens when a packet gets lost?
This is where the difference really shows. Imagine sending 5 pieces of data and piece #3 goes missing on the way.
With TCP (downloading a file):
- Pieces 1, 2, 4, 5 arrive, but 3 is lost.
- The receiver notices #3 is missing and doesn’t have piece 3’s acknowledgment.
- TCP re-sends piece 3.
- The receiver reassembles 1-2-3-4-5 in order.
Result: the file is perfect, even though it took a little longer. Losing a byte of a ZIP file or a web page would corrupt it, so this retry is exactly what you want.
With UDP (a live video call):
- Pieces 1, 2, 4, 5 arrive, but 3 is lost.
- UDP doesn’t notice or care—there’s no re-send.
- The video player just skips ahead.
Result: you see a tiny glitch for a split second, then the call continues live. Re-sending frame #3 two seconds later would be useless—by then the moment has passed. Here, staying in real time beats being perfect.
TCP vs UDP: side-by-side
| Feature | TCP | UDP |
|---|---|---|
| Connection | Connection-oriented (handshake first) | Connectionless (just send) |
| Reliability | Guaranteed delivery | No guarantee |
| Ordering | Data arrives in order | May arrive out of order |
| Speed | Slower (more overhead) | Faster (minimal overhead) |
| Error recovery | Re-sends lost data | None |
| Header size | 20+ bytes | 8 bytes |
| Analogy | Phone call | Postcard / shouting |
Real-world examples: who uses what?
Applications that use TCP (they need every byte, in order):
- Web browsing — HTTP/HTTPS (ports 80, 443)
- Email — SMTP, IMAP (ports 25, 143)
- Secure shell — SSH (port 22)
- File transfer — FTP (port 21)
- Databases — PostgreSQL, MySQL
Applications that use UDP (they need speed and can tolerate a little loss):
- DNS lookups (port 53)
- DHCP address assignment (ports 67, 68)
- Video and voice calls — VoIP, streaming
- Online gaming
- Time sync — NTP (port 123)
A good rule of thumb: if losing data would corrupt the result (a file, a web page, an email), use TCP. If a little loss is fine but delay is not (live audio, video, games), use UDP.
When should you choose each?
- Choose TCP when correctness matters more than speed: downloading a file, loading a website, logging in over SSH, sending an email.
- Choose UDP when speed matters more than perfection: live video, voice calls, gaming, or simple request/response lookups like DNS.
Summary
- TCP = reliable, ordered, connection-based. Like a phone call—slower to start but nothing gets lost.
- UDP = fast, lightweight, connectionless. Like a postcard—no guarantees, but quick.
Both are essential; the “right” one simply depends on whether your application values accuracy (TCP) or speed (UDP). To watch either in action, capture live traffic with tcpdump—see filtering UDP packets with tcpdump and understanding network ports.
