TCP vs UDP — The Differences, the Ports, and the Exam Traps

Every packet that crosses a network has to be handed to the right program on the right machine, and something has to decide whether lost packets get resent. That job belongs to the transport layer, and two protocols do nearly all of it. Understanding why both exist, rather than memorizing a two-column table, is what makes the exam questions easy: each one is really asking whether the scenario needs completeness or timeliness. This guide covers the mechanics, the headers, the port numbers worth knowing and the traps that cost points on CompTIA Network+ and Cisco CCNA.

What is the difference between TCP and UDP?

The short version is in the table. Everything else in this article explains why each row is true.

Two rows deserve emphasis because they are misunderstood. First, TCP is a byte stream: it does not preserve message boundaries, so two writes of 100 bytes may arrive as one read of 200 bytes. UDP preserves boundaries, so one send produces one datagram. Second, “unreliable” does not mean “bad”. It means the protocol itself makes no promise, and the application chooses whether it cares.

Where do TCP and UDP fit in the stack?

Both live at Layer 4, the Transport layer of the OSI model, above IP (Layer 3, in either IPv4 or IPv6; see IPv4 vs IPv6) and below the application. IP delivers a packet to the right host; the transport layer delivers the data to the right process on that host using a port number. A conversation is identified by five values: protocol, source IP, source port, destination IP and destination port. That five-tuple is also exactly what a stateful firewall, a NATtable and Wireshark's “Conversations” view use to track traffic. If the layered model is still fuzzy, read our OSI model guide first, then come back.

How does the TCP three-way handshake work?

Before any application data moves, TCP synchronizes sequence numbers on both ends. Three segments do it:

1. SYN: the client sends a segment with the SYN flag set and a randomly chosen initial sequence number (ISN).
2. SYN-ACK: the server replies with SYN and ACK both set. The ACK acknowledges the client's ISN plus one; the SYN carries the server's own ISN.
3. ACK: the client acknowledges the server's ISN plus one. The connection is now ESTABLISHED on both sides and data can flow.

The handshake is why TCP connections cost one full round trip before the first byte of application data (more with TLS on top), and why a server can be attacked with a SYN flood: many SYNs with no final ACK leave half-open connections consuming memory. SYN cookies and rate limiting are the standard defenses. Seeing the connection states yourself is easy; netstat -an lists them as LISTEN, SYN_SENT, SYN_RECEIVED, ESTABLISHED and TIME_WAIT, among others.

How does TCP guarantee delivery and order?

Every byte in a TCP stream has a sequence number. The receiver sends back an acknowledgement number naming the next byte it expects. If an acknowledgement does not arrive before a retransmission timer expires, the sender resends. If the receiver gets segments out of order, it holds them in a buffer and reassembles by sequence number before passing data up. A receiver that sees a gap keeps acknowledging the last in-order byte, and three duplicate ACKs trigger a fast retransmit without waiting for the timer.

This machinery is why a web page loads intact even over a lossy Wi-Fi link, and also why a lossy link feels slow under TCP: each loss costs a retransmission and shrinks the sending rate. For an exam, the keywords map directly: sequencing, acknowledgement, retransmissionand checksum are all TCP answers; none of them applies to UDP's own mechanism.

What are flow control and congestion control?

These are two different protections that exam questions deliberately blur:

UDP has neither. A UDP sender can transmit as fast as the application produces data, which is why large UDP streams without their own rate control can starve other traffic, and why protocols built on UDP (QUIC, RTP with RTCP feedback) add congestion awareness at a higher layer.

How does a TCP connection close?

Closing is normally a four-segment exchange because each direction is shut down independently: one side sends FIN, the other ACKs it, then the other side sends its own FIN and receives a final ACK. The side that closes first lingers in TIME_WAIT for a short period so that stray delayed segments cannot be mistaken for a new connection. A connection can also be aborted instantly with a RST segment, which is what a host sends when it receives a segment for a port with nothing listening, or when it wants to drop a session without the polite exchange.

What do the TCP and UDP headers contain?

Header size is a favorite exam fact, and the contents explain the behavior:

Look at what UDP omits. No sequence numbers means it cannot reorder; no acknowledgement number means it cannot know what arrived; no flags means no connection state. Those missing fields are the missing features. On a 1,500-byte Ethernet MTU, the 12 extra header bytes TCP carries are small, but for tiny messages such as a DNS query, avoiding the handshake and extra segments is the real saving.

What does UDP actually give you?

Beyond port numbers and an optional checksum, UDP adds almost nothing to IP, and that is its design goal. It gives you three useful properties. First, no connection setup: the first datagram carries data. Second, no connection state on the server, so one UDP socket can serve enormous numbers of clients, which suits DNS and NTP. Third, broadcast and multicast: because there is no connection, one datagram can be addressed to many receivers, which is how DHCP discovery and many streaming and discovery protocols work.

What you must handle yourself: loss, duplication, reordering and rate. Applications that need some of those build only the pieces they want. RTP adds sequence numbers and timestamps so a player can reorder and conceal gaps; TFTP adds simple acknowledgement of each block; QUIC rebuilds a full reliable transport over UDP.

When is each protocol used?

The decision rule: if a late packet is still useful, use TCP; if a late packet is garbage, use UDP.

Notice that “streaming” is not purely UDP. Video-on-demand services often deliver chunks over HTTP, which means TCP or QUIC, and rely on buffering to hide delay. Live, interactive media is where raw UDP dominates.

Why does HTTP/3 use UDP?

This is a modern point worth knowing because it shows that “UDP is unreliable, TCP is reliable” is a statement about the protocol, not the application. QUIC (RFC 9000) is a transport that runs on UDP and supplies its own reliability, congestion control and mandatory TLS 1.3 encryption, and HTTP/3 (RFC 9114) runs on top of it. Two practical benefits drive the design. A QUIC connection can complete transport and cryptographic setup together, saving round trips. And because QUIC multiplexes independent streams, one lost packet only stalls the stream it belongs to, whereas with HTTP/2 over TCP a single lost segment stalls every stream sharing the connection. Using UDP also lets QUIC evolve in user space without waiting for operating systems and middleboxes to update their TCP implementations.

For the exam, remember the headline: HTTPS is TCP 443, HTTP/3 uses UDP 443, and a firewall that blocks UDP 443 simply makes browsers fall back to TCP.

Which port numbers should I memorize?

Ports are 16-bit numbers. IANA assigns 0 to 1023 as well-known ports, 1024 to 49151 as registered ports, and 49152 to 65535 as dynamic or private ports, which clients draw from for the source side of a connection. The server listens on a fixed port; the client picks a random high one. This list covers the large majority of exam questions:

A memory trick: cleartext protocols have a secure sibling. Telnet 23 became SSH 22, HTTP 80 became HTTPS 443, LDAP 389 became LDAPS 636, and secure mail uses TLS on the submission and retrieval ports. For the full list in cheat-sheet form, see the Network+ cheat sheet and the CCNA cheat sheet. The authoritative source is the IANA registry linked in the sources below.

How do I spot TCP and UDP in Wireshark and packet captures?

Reading a capture is the practical skill that makes the theory stick, and scenario questions often show a short capture excerpt. Wireshark's Protocol column names the transport, and the packet details pane expands the headers described above. These display filters are worth knowing:

What to look for. A healthy TCP session starts with SYN, SYN-ACK, ACK. A SYN that repeats with no SYN-ACK points to a firewall dropping traffic or a dead host; a SYN answered with RST means the host is up but nothing listens on that port. Many retransmissions and duplicate ACKs point to loss on the path. A UDP flow has no handshake at all: you see a request datagram and, if the service is up, a response, and nothing in the protocol tells you whether a missing response was lost, dropped or never sent. Right-click a TCP packet and choose Follow TCP Stream to see the reassembled conversation, and use Statistics → Conversations to see each five-tuple with byte counts.

What are the common exam traps?

• “DNS is UDP.” Mostly, but zone transfers and large responses use TCP 53. If the question mentions transfers between servers, answer TCP.
• Flow control versus congestion control. Flow control protects the receiver (window size in ACKs). Congestion control protects the network. Choose by who is being protected.
• “UDP is faster so use it for file transfers.” Only if the application adds its own reliability. A plain file copy needs TCP.
• TFTP versus FTP. TFTP is UDP 69, simple, unauthenticated and used for boot images and device configs. FTP is TCP 20/21.
• DHCP ports. 67 is the server, 68 is the client; both UDP. Reversing them is a frequent distractor.
• SYN-ACK is one segment. The second handshake step is a single segment with both flags set, so a sequence listing it as two separate packets is wrong.
• Ping and traceroute. Ping uses ICMP, not TCP or UDP. Cisco IOS and Linux traceroute send UDP probes by default, while Windows tracert uses ICMP echo.
• Stateless versus stateful. UDP has no connection, but firewalls still track UDP flows by five-tuple with a timeout, so return traffic is allowed.
• Segment, datagram, packet. A TCP PDU is a segment; a UDP PDU is a datagram; both are carried inside an IP packet. Exams use these words precisely.
• Header sizes. UDP 8 bytes, TCP 20 minimum. Do not swap them.

How do Network+ and CCNA test this?

CompTIA Network+ N10-009 treats TCP versus UDP as foundation knowledge in Domain 1 (Networking Concepts), where you are expected to recognize ports, protocols and traffic types, and then reuses it in troubleshooting and security. Typical forms: match a port to a service and its protocol, pick the right transport for a described application, interpret a port-based firewall rule, and recognize connection problems from a described symptom. The sibling skill is addressing, covered in our subnetting guide, which together with ports forms most of the exam's calculation and recall load. See the full objective breakdown in the Network+ exam guide.

Cisco CCNA 200-301 lists “Compare TCP to UDP” as a named objective in Network Fundamentals, and then applies it in IP services and security: access control lists that permit or deny by protocol and port, NAT/PAT that rewrites ports, and routing protocols with their own transports. For example, OSPF runs directly over IP (protocol 89) and uses neither TCP nor UDP, while BGP runs over TCP 179, a favorite comparison. Our CCNA exam guide covers the full blueprint, and Network+ vs CCNA helps you decide which to take first.

TCP vs UDP practice questions with answers

Answer each one before you open it. For a timed bank of exam-style questions, use the Network+ practice exam or the CCNA practice exam.

Frequently asked questions

Sources and further reading

• RFC 9293: Transmission Control Protocol (TCP)
• RFC 768: User Datagram Protocol (UDP)
• IANA Service Name and Transport Protocol Port Number Registry
• RFC 9000: QUIC, a UDP-Based Multiplexed and Secure Transport
• RFC 9114: HTTP/3
• Wireshark User's Guide
• CompTIA Network+ certification page
• Cisco Learning Network: CCNA 200-301 exam topics