Quick Summary
- TCP is connection-oriented, reliable, and ordered (3-way handshake, acknowledgements, retransmission) -- choose it when every byte must arrive correctly
- UDP is connectionless and lightweight (no handshake, no delivery guarantee) -- choose it when speed and low latency beat occasional loss
- Both are Layer 4 transport protocols on top of IP and both use ports; HTTP/3 and QUIC even add reliability on top of UDP, so the line is blurring
The Courier and the Postcard
Suppose you need to send something important to a friend. You could use a tracked, signature-required courier: the courier confirms the parcel was picked up, scans it at every stop, and if a package is lost along the way it gets re-sent. Your friend signs for each delivery, and everything arrives in the right order. It is dependable -- but all that confirming and tracking takes a little extra time. That is TCP.
Or you could grab a stack of postcards and drop them in the mailbox. No tracking, no signature, no guarantee. Most will arrive, but one might get lost, and two mailed on the same day could show up in either order. The upside is that it is incredibly fast and cheap -- you just write and send. That is UDP.
Both TCP and UDP are Layer 4 (Transport) protocols that ride on top of IP, and both use ports so a single device can run many services at once. The difference is entirely about what guarantees they make. TCP trades a little speed for reliability and order. UDP trades reliability for raw speed. Neither is "better" -- the right choice depends on whether your data cares more about correctness or timeliness.
Side by Side
Here is how the two protocols behave when a packet goes missing. TCP notices and re-sends it; UDP simply moves on:
TCP or UDP? Pick the right protocol
Click a real-world scenario to see which protocol fits and why. Then scroll to the delivery race to watch the trade-off in motion.
Pick a scenario above to see the recommended protocol.
Delivery race: TCP vs UDP
Both lanes send 4 packets and one packet is dropped in transit. Watch what each protocol does about it.
The race makes the trade-off concrete: TCP always delivers a complete, correctly ordered copy, but it has to notice the loss and spend a round trip re-sending the missing piece. UDP is finished sooner, but it never recovers the dropped packet. For a file, TCP's behavior is exactly what you want. For a live call, UDP's behavior is exactly what you want -- you would rather skip a tiny glitch than freeze the conversation to replay old audio.
How They Work, Step by Step
TCP Sets Up a Connection First
Before any data flows, TCP performs a three-way handshake: the client sends a
SYN, the server replies SYN-ACK, and the client answers ACK.
Only then does the connection exist. This is what "connection-oriented" means -- both sides agree to
talk before the conversation starts, and they track the state of that connection for its whole life.
UDP has no handshake at all; it just starts sending.
TCP Acknowledges and Retransmits
As data flows, the receiver sends acknowledgements (ACKs) confirming what it got. If the sender does not see an ACK for some data, it assumes that data was lost and retransmits it. TCP also reorders anything that arrives out of sequence, so the application always reads a clean, in-order byte stream. UDP does none of this -- it offers no acknowledgements, no retransmission, and no reordering.
TCP Manages Flow and Congestion
TCP uses a sliding window for flow control so a fast sender does not overwhelm a slow receiver, and it uses congestion control to back off when the network itself is overloaded. These mechanisms keep the internet stable but add a little latency. UDP has no built-in congestion control, which is part of why it is so fast -- and why applications that use it must be careful not to flood the network.
Headers and Overhead
The cost of TCP's guarantees shows up in its header: a TCP header is about 20 bytes and carries sequence numbers, acknowledgement numbers, window size, and flags. UDP's header is just 8 bytes -- source port, destination port, length, and checksum. That smaller header, plus the absence of handshakes and ACKs, is why UDP has lower overhead and lower latency, making it ideal for short transactions and real-time media.
Who Uses TCP, Who Uses UDP
The protocols an application chooses tell you what it values. Here are three telling examples:
TCP: Web, Email, SSH
HTTP/HTTPS, SSH, SMTP, FTP, and IMAP all
ride on TCP. These are tasks where every byte must arrive correctly and in order -- a corrupted web page,
half an email, or a garbled command would be unacceptable -- so the reliability is worth the extra
overhead.
UDP: DNS, DHCP, VoIP, Streaming
DNS, DHCP, NTP, SNMP, VoIP, and live video and audio
use UDP. Some are tiny request-response exchanges where a handshake would be wasteful; others are
real-time media where low latency matters far more than recovering an occasional lost packet.
The Hybrid: QUIC / HTTP/3
QUIC runs on UDP yet rebuilds reliability, ordering, and encryption in user space, and it
carries HTTP/3. It shows the old "TCP vs UDP" line is blurring: you can start from UDP's
speed and add back exactly the guarantees you need, without TCP's fixed costs.
Common TCP vs UDP Mistakes
These misunderstandings come up constantly when people first learn the difference:
"UDP Is Just Worse Than TCP"
UDP is not a broken TCP -- it is a deliberate design choice. For real-time voice, video, and gaming, UDP's willingness to skip a lost packet is exactly the right behavior, because a late retransmission of old data would hurt more than help. Picking UDP is a feature, not a compromise, when latency matters most.
"UDP Has No Error Checking"
UDP does include a checksum to detect corrupted datagrams (it simply drops bad ones rather than re-requesting them). What UDP lacks is reliable delivery -- acknowledgements, retransmission, and ordering. It can tell a packet is damaged; it just will not fix or re-send it for you.
"HTTPS Always Means TCP"
That was true for years, but no longer. HTTP/1.1 and HTTP/2 use TCP, while
HTTP/3 uses QUIC over UDP. So modern HTTPS may travel over TCP or over UDP
depending on the version your browser and the server negotiate. Assuming "secure web = TCP" can mislead
you when reading traffic.
So Which Should You Choose?
The rule of thumb is short: choose TCP when correctness matters more than speed, and UDP when speed or real-time behavior matters more than the occasional lost packet. If your data is a document, a transaction, a login, or anything where a single wrong byte is a failure, reach for TCP. If your data is a live stream, a game update, a voice call, or a tiny lookup where being on time beats being perfect, reach for UDP. And remember that modern protocols like QUIC blur this boundary by building TCP-like reliability on top of UDP -- so the question is shifting from "TCP or UDP?" to "which guarantees does this traffic actually need?"
The bottom line: TCP and UDP are two tools for the same job -- moving data between applications -- with opposite priorities. Once you can picture the tracked courier versus the stack of postcards, you can predict which protocol any application will pick just by asking whether it cares more about every byte arriving or about arriving fast.
Frequently asked questions about TCP vs UDP
What is the difference between TCP and UDP?
TCP is connection-oriented, reliable, and ordered: it sets up a connection with a three-way handshake, acknowledges every piece of data, retransmits anything lost, and delivers bytes in order, at the cost of more overhead. UDP is connectionless and lightweight: it has no handshake and no guarantee of delivery or ordering, which makes it fast and ideal for real-time traffic where occasional loss is acceptable. Both are Layer 4 transport protocols that run on top of IP and use ports.
Is TCP or UDP faster?
UDP is generally faster and lower-latency because it skips the handshake, acknowledgements, retransmissions, and congestion control that TCP performs, and it uses a smaller 8-byte header compared to TCP's roughly 20-byte header. That speed comes at the price of reliability: UDP does not detect or recover lost packets on its own. TCP is slightly slower but guarantees that every byte arrives correctly and in order.
Why does DNS use UDP?
A typical DNS lookup is a single small request and a single small response, so the cost of setting up and tearing down a TCP connection would dwarf the actual data being sent. UDP lets the resolver fire off the query and get an answer in one quick round trip with minimal overhead. If a response is too large or truncated, DNS falls back to TCP, and DNS zone transfers use TCP as well.
Does HTTPS use TCP or UDP?
It depends on the HTTP version. HTTP/1.1 and HTTP/2 run over TCP, so HTTPS on those versions uses TCP with TLS on top. HTTP/3 runs over QUIC, which is built on UDP and adds its own reliability, ordering, and encryption in user space. So modern HTTPS can use either TCP (HTTP/1.1 and HTTP/2) or UDP via QUIC (HTTP/3).
When should I use UDP instead of TCP?
Choose UDP when speed and low latency matter more than perfect delivery, and when your application can tolerate or recover from occasional loss. Classic examples are live voice and video calls, online gaming, live streaming, and lightweight request-response protocols like DNS, DHCP, NTP, and SNMP. Choose TCP whenever correctness is essential, such as web pages, file downloads, email, and remote shells, where every byte must arrive intact and in order.
See transport protocols in action
You just learned how TCP and UDP trade reliability for speed. Now build a topology, open TCP and UDP ports on your servers, and trace traffic to them by protocol and port to see where each flow is accepted, refused or filtered.
Launch the network lab →