October 28, 2026 · CertCrack Blog

TCP vs UDP Explained: Which Protocol Does What — and When to Use Each

Almost every application on a network talks over one of two transport-layer protocols: TCP or UDP. Both carry data between applications using port numbers, but they make opposite trade-offs. TCP is the careful courier: it checks that every package arrives, in order, and resends anything lost. UDP is the fast courier: it sends packages as quickly as possible and does not wait around to confirm delivery. Knowing which one a service uses — and why — is a core skill for Network+, CCNA, and Security+ students, and it explains a lot of real-world behaviour, from why a video call glitches instead of freezing to why a file download never arrives corrupted.

What TCP and UDP have in common

TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) both sit at the transport layer of the networking model, above IP. IP gets a packet to the right computer; the transport protocol gets it to the right application on that computer. That is what port numbers are for: a destination port identifies the service, such as port 443 for HTTPS web traffic or port 53 for DNS. Both protocols use ports, and both are identified by a protocol number in the IP header (TCP is 6, UDP is 17). The difference is what happens after the data leaves the sender.

TCP: reliable, ordered, and connection-oriented

TCP sets up a connection before any application data flows, using the three-way handshake: the client sends a SYN packet, the server replies with SYN-ACK, and the client answers with ACK. Only then does data move. Each segment carries a sequence number, and the receiver acknowledges what it has received. If a segment goes missing, the sender retransmits it. TCP also manages flow control (the receiver advertises a window size, telling the sender how much data it can accept) and congestion control (the sender slows down when the network is congested). The connection is closed with a four-way exchange built around FIN and ACK packets.

That reliability has a cost: a minimum 20-byte header per segment, plus the handshake round trips and the delay of retransmissions. TCP is the right choice whenever losing or reordering data would break the result — web browsing (HTTP and HTTPS), email (SMTP, IMAP, POP3), file transfer (FTP), remote administration (SSH), and database connections. If a single byte of a downloaded file or a web page arrived out of order or missing, the result would be corrupt, so TCP's guarantees are worth the overhead.

UDP: fast, simple, and connectionless

UDP does none of that. There is no handshake, no sequence tracking, no retransmission, and no congestion control. An application hands UDP a message, UDP adds a small 8-byte header and sends it as a datagram. If it is lost, it is lost; if datagrams arrive out of order, the application deals with it — or does not care. That sounds reckless until you consider the use cases. A video call would rather drop one frame than pause everything while a late frame is retransmitted; by the time the retransmission arrived, the moment would have passed. The same logic applies to live video streams, online games (where the next game state matters more than a stale one), and voice calls.

UDP also suits short request-and-response traffic where a handshake would cost more than the data itself. DNS lookups are the classic example: a single query and a single response, usually over UDP port 53. DHCP (ports 67 and 68), SNMP (port 161), and NTP time synchronisation (port 123) all use UDP for the same reason. Note one detail exam questions love: the UDP checksum is optional in IPv4 but mandatory in IPv6.

TCP vs UDP at a glance

So which one should an application use?

Ask one question: what breaks if a packet is lost or late? If the answer is "the data is wrong," use TCP. If the answer is "a tiny glitch nobody notices, but delay would ruin it," use UDP. That single rule answers most exam questions and most design questions. There is also a modern twist worth knowing: QUIC, the protocol behind HTTP/3, runs over UDP and rebuilds TCP-like reliability (ordered streams, retransmission, encryption) inside the application layer — proof that UDP's simplicity is a platform other protocols can build on, not just a shortcut.

Exam connection

TCP vs UDP appears across the entry-level certifications this site covers. CompTIA Network+ (N10-009) and Cisco CCNA (200-301) both test it under networking fundamentals and IP connectivity: expect questions that give you a port number or a scenario and ask which protocol fits, or that ask what the three-way handshake accomplishes. CompTIA Security+ (SY0-701) tests it from the security side: firewall rules, for example, must allow or block TCP and UDP separately — opening TCP port 53 does not open UDP port 53, and a DNS rule that forgets UDP will break name resolution. Common exam traps include: assuming UDP is "unreliable" in the sense of "broken" (it is a deliberate design choice, not a flaw); confusing the three-way handshake with the four-way teardown; and forgetting that DNS uses both protocols — UDP for ordinary queries, TCP for zone transfers and for responses too large for a single UDP datagram.

Practical takeaway

When you troubleshoot, check the protocol before you blame the network. A web page that loads slowly but completely points at TCP behaviour — retransmissions or a small receive window. A video call that stutters but keeps going points at UDP doing exactly what it was designed to do: keep moving. And when you write a firewall rule, always ask whether the service needs TCP, UDP, or both.

FAQ

Is UDP less secure than TCP?

Not inherently. Both can carry encrypted data, and both can be abused — UDP's connectionless nature does make it easier to spoof a source address, which is why UDP-based amplification attacks exist, but security comes from encryption, authentication, and firewall rules, not from the transport protocol alone.

Can one application use both TCP and UDP?

Yes. DNS is the best-known example: ordinary queries go over UDP, while zone transfers between DNS servers and oversized responses use TCP. Many games also mix them, using UDP for fast game state and TCP for chat or login.

Why does a download use TCP if UDP is faster?

Because a download must be bit-perfect. UDP's speed advantage disappears the moment you have to rebuild reliability yourself — which is exactly what TCP already does, including retransmission, ordering, and congestion control.