TCP vs UDP: How They Work and When to Use Each (2026)
Every CCNA candidate hits the same wall early: TCP and UDP both live at the transport layer, both carry your application data, and the exam expects you to know exactly when each one is used and why. Get this wrong and you lose easy marks; understand it and a whole cluster of 200-301 topics (ports, the three-way handshake, DNS, DHCP, VoIP) suddenly clicks.
At CISNET our instructors teach transport-layer concepts the same way they show up in real networks and on the exam: not as definitions to memorize, but as a single trade-off you can reason from. TCP trades speed for reliability. UDP trades reliability for speed. Once you internalize that, you can answer almost any TCP-versus-UDP question without guessing.
TCP vs UDP: The One Trade-Off That Explains Everything
Both protocols sit at Layer 4 of the OSI model and hand your data to IP for delivery. The difference is what they promise about that delivery.
TCP (Transmission Control Protocol) is connection-oriented. Before any data moves, the two hosts complete a handshake, agree on sequence numbers, and set up state on both ends. Every segment is numbered, acknowledged, and re-sent if it goes missing, and the data is reassembled in the exact order it was sent. That machinery is why a web page or a file download arrives complete and correct, and it is also why TCP carries more overhead.
UDP (User Datagram Protocol) is connectionless. There is no handshake, no acknowledgements, no sequence tracking, and no automatic retransmission. UDP just wraps your data in a small header and fires it at the destination. If a datagram is lost, UDP does not notice or care. That sounds reckless until you realize it is exactly what a live voice call or a game needs: a packet that arrives late is worse than useless, so there is no point re-sending it.
The whole comparison collapses into one question the exam loves to ask in disguise: does this application need every byte to arrive in order, or does it need data to arrive fast even if a little is lost?
How the TCP Three-Way Handshake Works
Because TCP is connection-oriented, it cannot send data until both hosts agree to talk. That agreement is the three-way handshake, and it is one of the most tested mechanics on the CCNA.
It happens in three steps, using flags in the TCP header:
- SYN - the client picks an initial sequence number and sends a segment with the SYN (synchronize) flag set. This says "I want to open a connection, and my sequence numbers start here."
- SYN-ACK - the server replies with both the SYN and ACK flags set. It acknowledges the client's sequence number and sends its own initial sequence number.
- ACK - the client acknowledges the server's sequence number. The connection is now established, and data can flow in both directions.
The sequence at the top of this article shows that exchange step by step. Two details examiners like to probe. First, the handshake is why TCP is called connection-oriented: real state exists on both machines before byte one of application data. Second, tearing a connection down uses a similar exchange with the FIN flag. UDP has none of this, which is precisely why it is faster to get started.
What Actually Makes TCP Reliable
"Reliable" is not a marketing word here; it is a set of concrete mechanisms, and the CCNA expects you to name them:
- Sequence numbers label every byte so the receiver can reassemble segments in order, even if they arrive out of order.
- Acknowledgements (ACKs) tell the sender which data was received. Unacknowledged data is retransmitted after a timeout.
- Retransmission re-sends lost segments automatically, so the application never sees the gap.
- Flow control uses a sliding window so a fast sender does not overwhelm a slow receiver.
- Congestion control backs off the send rate when the network is dropping packets.
UDP provides none of these. If your application needs any of them, it either uses TCP or has to rebuild that logic itself (which is what protocols like QUIC do on top of UDP).
Why UDP Is Faster and Leaner
UDP's advantage is everything it leaves out. There is no handshake, so there is no round-trip delay before data can flow. There is no per-connection state, so a server can handle huge numbers of clients cheaply. And the UDP header is only 8 bytes, compared to TCP's 20 bytes minimum, so there is less overhead on every single packet.
That efficiency is the entire point for real-time and high-volume traffic. In a voice call, a 200-millisecond retransmission would arrive after the moment it was meant for, creating a stutter instead of fixing anything. Dropping the lost audio and moving on sounds better. The same logic applies to live video, online games, and DNS lookups, where sending one more small query is cheaper than maintaining a connection.
When to Use TCP vs UDP (and the Ports to Memorize)
For the exam and for real troubleshooting, you should be able to place common services on the right protocol instantly.
| Use TCP when you need reliability | Use UDP when you need speed |
|---|---|
| HTTP / HTTPS (web) - ports 80 / 443 | DNS queries - port 53 |
| SMTP / IMAP / POP3 (email) | DHCP - ports 67 / 68 |
| FTP / SFTP (file transfer) - 20/21 | VoIP and video (RTP) |
| SSH (remote admin) - port 22 | Online gaming and live streaming |
| Any transfer where completeness matters | SNMP monitoring - port 161 |
Two nuances worth knowing. DNS usually uses UDP for fast lookups but switches to TCP for large responses and zone transfers, so "DNS is UDP" is only mostly true. And HTTP/3 runs over QUIC, which is built on UDP but adds its own reliability, showing that the TCP-versus-UDP line is about trade-offs, not a permanent law.
If you can build the ports table from memory and explain why each service sits where it does, you have covered a meaningful slice of the CCNA 200-301 blueprint. Drill it with our free CCNA practice exam and the subnetting guide to round out the network-fundamentals domain.
Frequently Asked Questions
Is TCP or UDP better?
Neither is better in general; they are built for different jobs. TCP is better when every byte must arrive correctly and in order, such as web pages, email, and file transfers. UDP is better when speed matters more than perfect delivery, such as voice calls, live video, gaming, and DNS lookups. The right question is always what the application needs.
Why does the TCP three-way handshake have three steps?
Three steps are the minimum needed for both hosts to agree on starting sequence numbers and confirm each other is reachable. The client's SYN and the server's SYN each need to be acknowledged; the server combines its acknowledgement and its own SYN into one SYN-ACK, so the whole exchange takes three messages instead of four.
Is DNS TCP or UDP?
Both. DNS uses UDP on port 53 for normal queries because they are small and fast, but it falls back to TCP for responses too large for a single UDP datagram and for zone transfers between servers. The CCNA expects you to know it is primarily UDP with a TCP fallback.
Does UDP have any error checking?
UDP has a checksum that lets the receiver detect a corrupted datagram, but that is all. If the checksum fails, the datagram is simply discarded; UDP does not request a retransmission or notify the application. It detects some errors but does not correct them.
How is TCP reliability actually achieved?
Through sequence numbers, acknowledgements, retransmission of lost segments, in-order reassembly, flow control with a sliding window, and congestion control. Together these guarantee that the receiving application gets a complete, correctly ordered stream even when the network loses or reorders packets.
Transport-layer concepts like these are exactly what CISNET's live, instructor-led CCNA training drills with hands-on labs in Packet Tracer, so you can see the handshake and the retransmissions happen instead of just reading about them.
