Cisco Certified Network Associate (CCNA) 200-301 · Free study guide

Objective 1.5 — Compare TCP and UDP

TCP and UDP provide transport between application endpoints identified by ports. The important comparison is behavior: connection state, reliability, ordering, flow control, congestion response, message boundaries, and overhead.

TCP's reliable byte stream

TCP establishes connection state with a handshake. Sequence numbers track bytes, acknowledgments report received progress, and retransmission repairs detected loss. The receiver can advertise available window space for flow control, while the sender responds to network congestion. Applications receive an ordered byte stream, not preserved application-message boundaries.

This behavior helps file transfer, interactive management, and applications that need complete ordered data. It also adds state and delay when loss requires recovery. A TCP acknowledgment confirms delivery to the remote transport stack, not that a human or application successfully processed the business action.

UDP's datagrams

UDP sends independent datagrams without a transport handshake, acknowledgment, ordering, retransmission, or flow-control mechanism. It preserves datagram boundaries and has a small header. The application can tolerate loss, add its own recovery, or prefer current data over late retransmissions.

UDP is not automatically faster. Congestion, application design, packet size, and loss all matter. Likewise, an application using UDP can implement substantial reliability above it.

Ports and multiplexing

Both protocols use 16-bit source and destination ports. A server commonly listens on a known destination port while the client uses an ephemeral source port. The same numeric port under TCP and UDP identifies different transport namespaces. An ACL or firewall rule must therefore specify protocol as well as port.

Application examples with caveats

DNS commonly uses UDP for ordinary compact queries and can use TCP where the exchange or operation requires it. DHCP uses UDP because a new client lacks normal connection context. SSH uses TCP for a reliable encrypted interactive stream. Real-time media often uses UDP-based designs to avoid retransmitting data that has become stale. Learn the governing requirement rather than assuming one protocol can never appear in another context.

Worked scenario

A voice application receives one late packet and one missing packet. Replaying old audio after retransmission may hurt the conversation more than concealing a small loss, so a UDP-based real-time design can be appropriate. A configuration backup must arrive complete and ordered, so a reliable transport is preferable. The decision follows tolerance for loss and delay.

Common traps

• Saying UDP has no checksum or no ports.
• Treating TCP as proof the application committed a transaction.
• Matching a port number without its transport protocol.
• Calling UDP connection-oriented because an application remembers a peer.
• Memorizing examples without understanding the requirement.

Readiness checklist

• I can narrate handshake, sequence, acknowledgment, and retransmission.
• I can explain datagram versus byte-stream semantics.
• I include transport protocol when discussing ports.
• I can choose a transport behavior from application constraints.