Imagine you're shipping a package. You can either use a service that guarantees delivery and checks for damage (reliable, but slower) or one that just throws it on a truck and hopes for the best (fast, but unreliable). In networking, TCP and UDP are those two services. This chapter is crucial for the CCNA 200-301 exam because objective 1.5 explicitly requires you to compare TCP and UDP, and you'll face scenario questions asking which transport protocol to use for a given application. Understanding the trade-offs is essential for real network engineering, as the choice impacts application performance, network efficiency, and troubleshooting.
Jump to a section
Think of TCP as a certified mail service. When you send a letter via certified mail, the post office gives you a receipt. The letter travels through a series of sort facilities, each one logging its arrival. If a facility doesn't receive the letter, the previous facility resends it. The recipient signs a delivery receipt, which is returned to you. This process is reliable but slow because every step requires acknowledgment. The post office also ensures letters are delivered in order – if you send three letters, they arrive in the same order. This is TCP: connection-oriented, reliable, ordered, and with flow control (the post office might slow down if the recipient's mailbox is full).
UDP, on the other hand, is like a courier tossing a package onto a conveyor belt at a warehouse. The package is launched without any tracking number or receipt. The recipient might get it, or it might fall off the belt and be lost forever. There's no confirmation of delivery, no order guarantee, and no way to slow down the sender. But it's blazingly fast – the package is on the belt and gone in milliseconds. This is UDP: connectionless, unreliable, unordered, and lightweight. Real-time applications like video calls or online gaming use UDP because they can tolerate some loss but cannot tolerate the delay of retransmissions.
TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) are the two primary transport layer protocols in the TCP/IP suite. They sit between the application layer and the network layer. Their job is to provide end-to-end communication services for applications. TCP is defined in RFC 793, UDP in RFC 768. The key difference is that TCP is connection-oriented and reliable, while UDP is connectionless and unreliable.
TCP: Connection-Oriented and Reliable
TCP establishes a virtual connection between two hosts before any data is sent. This connection is full-duplex, meaning data can flow in both directions simultaneously. TCP provides:
Reliability: It ensures that data sent from one end arrives at the other end intact, in order, and without duplication. If packets are lost, TCP retransmits them.
Flow Control: TCP uses a sliding window mechanism to prevent a fast sender from overwhelming a slow receiver.
Congestion Control: TCP dynamically adjusts its transmission rate based on network congestion to avoid packet loss.
Ordered Delivery: TCP assigns sequence numbers to each byte of data, allowing the receiver to reorder out-of-order segments.
#### TCP Header Fields
The TCP header is 20-60 bytes. Key fields:
Source Port (16 bits) and Destination Port (16 bits): Identify the sending and receiving applications.
Sequence Number (32 bits): The byte number of the first byte of data in this segment. Used for ordering and reliability.
Acknowledgment Number (32 bits): If the ACK flag is set, this field contains the next expected sequence number. It acknowledges receipt of all bytes up to (ACK number - 1).
Data Offset (4 bits): Size of the TCP header in 32-bit words.
Flags (9 bits): Control bits such as SYN, ACK, FIN, RST, PSH, URG.
Window Size (16 bits): The number of bytes the receiver is willing to accept (flow control).
Checksum (16 bits): Error-checking for the header and payload.
Urgent Pointer (16 bits): Points to urgent data if URG flag is set.
#### TCP Connection Establishment (Three-Way Handshake)
SYN: Client sends a TCP segment with SYN flag set, initial sequence number (ISN) = x.
SYN-ACK: Server responds with SYN and ACK flags set, ISN = y, ACK number = x+1.
ACK: Client sends ACK with sequence number = x+1, ACK number = y+1. Connection is established.
#### TCP Connection Termination (Four-Way Handshake)
FIN: Client sends FIN, sequence number = x.
ACK: Server ACKs with ACK number = x+1.
FIN: Server sends FIN, sequence number = y.
ACK: Client ACKs with ACK number = y+1.
#### TCP States
TCP connections go through states: CLOSED, LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT. The TIME-WAIT state lasts 2*MSL (Maximum Segment Lifetime, typically 30 seconds, 60 seconds, or 2 minutes) to ensure delayed segments are discarded.
#### TCP Timers
Retransmission Timer (RTO): Dynamically calculated based on round-trip time (RTT). Default initial RTO is 1 second (RFC 6298).
Persistence Timer: Used to prevent deadlock when window size is zero. Default 5 seconds.
Keepalive Timer: Default 2 hours (7200 seconds). Sends keepalive probes if idle.
#### IOS Verification Commands
R1# show tcp brief
TCB Local Address Foreign Address (state)
0x12345678 192.168.1.1.80 192.168.1.2.54321 ESTABLISHEDR1# show ip socket
Proto Remote Port Local Port In Out Stat TTY OutputIF
17 --listen-- --any-- 0 0 2211 0
17 192.168.1.2.53 192.168.1.1.54322 0 0 2211 0UDP: Connectionless and Unreliable
UDP is a minimal transport protocol. It provides no reliability, ordering, or flow control. It simply sends datagrams (messages) from one host to another. The UDP header is only 8 bytes.
#### UDP Header Fields
Source Port (16 bits): Optional (if not used, set to 0).
Destination Port (16 bits).
Length (16 bits): Length of UDP header + data in bytes.
Checksum (16 bits): Optional in IPv4 (but should be used), mandatory in IPv6.
#### UDP Characteristics
No connection establishment: Data can be sent immediately.
No acknowledgment: Lost packets are not retransmitted.
No ordering: Packets may arrive out of order.
No flow control: The sender can flood the receiver.
Low overhead: 8-byte header vs. 20-byte TCP header.
#### Applications of UDP
DNS (port 53) – uses UDP for queries, TCP for zone transfers.
DHCP (ports 67/68) – uses UDP.
TFTP (port 69) – uses UDP.
SNMP (port 161) – uses UDP.
Voice over IP (RTP over UDP)
Video streaming (some protocols)
Online gaming
#### IOS Verification Commands
R1# show udp
Proto Remote Port Local Port In Out Stat TTY OutputIF
17 --listen-- --any-- 0 0 2211 0
17 192.168.1.2.53 192.168.1.1.54322 0 0 2211 0Comparing TCP and UDP
| Feature | TCP | UDP | |--------------------------|-------------------------------|-------------------------------| | Connection | Connection-oriented | Connectionless | | Reliability | Reliable (acknowledgments) | Unreliable (no acknowledgments) | | Ordered delivery | Yes (sequence numbers) | No (no ordering) | | Flow control | Yes (sliding window) | No | | Congestion control | Yes (AIMD, etc.) | No | | Header size | 20-60 bytes | 8 bytes | | Data boundary | Stream of bytes | Datagram boundaries preserved | | Common uses | Web, email, file transfer | DNS, VoIP, streaming, gaming |
Identify Application Requirements
Before choosing TCP or UDP, ask: Does the application need reliable delivery? If yes, TCP is required. Does the application tolerate some data loss but need low latency? If yes, UDP may be better. For example, web browsing (HTTP) needs reliability, so TCP. VoIP can tolerate occasional lost packets but not retransmission delays, so UDP. Also consider if the application needs ordered delivery; TCP provides it, UDP does not.
Check Port Numbers
Many applications have well-known ports that indicate the transport protocol. For example, HTTP uses TCP port 80, HTTPS uses TCP 443, DNS uses UDP 53 (and TCP for zone transfers), DHCP uses UDP 67/68, TFTP uses UDP 69. On the exam, if you see a port number, you should know whether it uses TCP or UDP. Memorize common ports: FTP (TCP 20/21), SSH (TCP 22), Telnet (TCP 23), SMTP (TCP 25), DNS (UDP 53), DHCP (UDP 67/68), HTTP (TCP 80), HTTPS (TCP 443), etc.
Analyze Application Behavior
Consider how the application sends data. If it sends a stream of bytes (e.g., file transfer), TCP's stream orientation is natural. If it sends discrete messages (e.g., DNS query/response), UDP's datagram service matches. Also, if the application does its own reliability (e.g., some streaming protocols use application-layer acknowledgments), it might use UDP. On the exam, scenario questions often describe an application's tolerance for loss and delay; use that to decide.
Evaluate Network Conditions
If the network is unreliable (high packet loss), TCP's retransmissions may cause excessive delays. UDP doesn't retransmit, so it might be better for real-time apps. On a reliable local network, both work fine. For WAN links with high latency, TCP's handshake adds delay. The exam may ask which protocol is better for a given WAN scenario.
Consider Security and Overhead
TCP has more overhead (larger header, connection state) and is more vulnerable to SYN floods. UDP has less overhead but can be used for amplification attacks (e.g., DNS amplification). For the exam, know that TCP is used when reliability is critical, UDP when speed is critical. If the question mentions 'low overhead' or 'fast transmission,' lean UDP. If it says 'guaranteed delivery,' lean TCP.
Verify with show commands
On Cisco IOS, use `show ip sockets` or `show udp` to see UDP listeners and connections. For TCP, use `show tcp brief`. These commands show local and foreign addresses, ports, and connection state. For example, `show tcp brief` might show an established TCP connection. This helps in troubleshooting which applications are using which transport protocol.
In a typical enterprise network, you'll find both TCP and UDP in use simultaneously. For example, consider a company's data center hosting a web server and a VoIP server. The web server uses HTTP over TCP port 80. When a client requests a webpage, TCP establishes a connection, sends the request, and the server responds. The client's browser expects reliable delivery – if a packet is lost, the page might not load correctly. TCP ensures that by retransmitting lost segments. The network engineer configures firewall rules to allow TCP 80 inbound. They also monitor TCP connection tables to ensure no half-open connections accumulate, which could exhaust resources.
Meanwhile, the VoIP server uses RTP over UDP. Voice packets are sent every 20 ms. If a packet is lost, the receiver might interpolate or simply drop it – retransmission would cause unacceptable delay. The network engineer must configure QoS to prioritize UDP traffic (especially RTP) over TCP traffic to avoid jitter. They also set up firewall rules to allow UDP ports 16384-32767 (typical RTP range). A misconfiguration here, like blocking UDP, would cause one-way audio or no audio at all.
Another scenario is DNS. DNS queries are typically sent over UDP port 53. If the response is larger than 512 bytes (or 4096 with EDNS0), the DNS server may switch to TCP. Network engineers must ensure both UDP and TCP 53 are allowed through firewalls. If only UDP is allowed, large DNS responses will be truncated, causing resolution failures. Similarly, DHCP uses UDP – if a client can't get an IP address, the engineer checks if UDP 67/68 is blocked. In production, misconfiguring transport protocol filters can break critical services. For example, blocking UDP 53 would break DNS, causing all name resolution to fail. Blocking TCP 80 would break web access. Understanding the application's transport needs is essential for proper network design and troubleshooting.
On the CCNA 200-301 exam, objective 1.5 is 'Compare TCP to UDP.' You will see scenario questions asking which protocol to use for a given application. The exam is not about memorizing port numbers for every obscure protocol, but about understanding the characteristics. The most common wrong answers candidates choose:
Choosing TCP for real-time applications because 'reliable is always better.' Wrong – reliability introduces delay and jitter, which is terrible for voice/video. The correct answer is UDP.
Choosing UDP for file transfer because 'it's faster.' Wrong – file transfer requires reliability; if a packet is lost, the file is corrupt. TCP is required.
Thinking UDP guarantees delivery because it has a checksum. The checksum only detects errors, it does not guarantee delivery or retransmit lost packets.
Forgetting that some applications use both TCP and UDP (e.g., DNS). DNS uses UDP for queries, but TCP for zone transfers and large responses. The exam may ask which protocol DNS uses for a typical query – answer UDP.
Specific values to know: TCP header is 20 bytes (minimum), UDP header is 8 bytes. TCP uses a three-way handshake (SYN, SYN-ACK, ACK). TCP sequence numbers are 32-bit. UDP is connectionless. The window size field in TCP is 16 bits (max 65535 bytes). The initial retransmission timeout (RTO) is 1 second.
For scenario questions, use this decision rule:
If the application is real-time (voice, video, gaming) → UDP (tolerates loss, not delay)
If the application requires reliable delivery (file transfer, email, web) → TCP
If the application is a simple query/response (DNS, DHCP) → UDP (unless response is large)
If the application does its own reliability (e.g., some streaming protocols) → UDP
Eliminate answers that contradict these principles. Also, be wary of questions that mention 'connection-oriented' – that's TCP. 'Connectionless' is UDP.
TCP is connection-oriented, reliable, and provides ordered delivery; UDP is connectionless, unreliable, and does not guarantee order.
TCP uses a three-way handshake (SYN, SYN-ACK, ACK) to establish a connection; UDP has no handshake.
TCP header is 20-60 bytes; UDP header is 8 bytes.
Common TCP applications: HTTP (80), HTTPS (443), FTP (20/21), SMTP (25), SSH (22).
Common UDP applications: DNS (53), DHCP (67/68), TFTP (69), SNMP (161), RTP (voice/video).
TCP provides flow control via sliding window (window size field); UDP has no flow control.
TCP uses sequence numbers to order data and detect loss; UDP does not sequence data.
On the exam, if an application requires reliability, choose TCP; if it requires low latency and can tolerate loss, choose UDP.
These come up on the exam all the time. Here's how to tell them apart.
TCP
Connection-oriented (virtual circuit)
Reliable (acknowledgments, retransmissions)
Ordered delivery (sequence numbers)
Flow control (sliding window)
Congestion control (AIMD)
UDP
Connectionless (no virtual circuit)
Unreliable (no acknowledgments)
No ordering (datagrams may arrive out of order)
No flow control
No congestion control (application may implement)
Mistake
UDP is always faster than TCP.
Correct
UDP has lower overhead and no connection setup, so it can be faster for small transfers. However, for large transfers, TCP's congestion control can be more efficient than UDP in avoiding packet loss. The actual speed depends on network conditions.
Candidates see the overhead difference and assume UDP is always faster, ignoring congestion control benefits.
Mistake
TCP guarantees data delivery.
Correct
TCP provides reliable delivery by retransmitting lost segments, but it does not guarantee delivery if the connection is reset or if the network is completely broken. It guarantees in-order, error-checked delivery of a stream of bytes, but the application must still handle connection failures.
The word 'guarantee' is strong; candidates misinterpret 'reliable' as absolute guarantee.
Mistake
UDP has no error checking.
Correct
UDP has a checksum field (optional in IPv4, mandatory in IPv6) that detects errors in the header and data. If the checksum fails, the packet is discarded. However, there is no retransmission.
Candidates think 'unreliable' means no error detection, but checksum provides basic integrity.
Mistake
TCP uses a fixed retransmission timer of 1 second.
Correct
TCP's retransmission timeout (RTO) is dynamic, calculated based on measured round-trip time (RTT). The initial RTO is 1 second per RFC 6298, but it adapts. It can be less than 1 second on fast networks or longer on slow networks.
Candidates memorize the initial value but forget it's adaptive.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
TCP is connection-oriented and reliable, meaning it establishes a virtual circuit, acknowledges data, retransmits lost packets, and delivers data in order. UDP is connectionless and unreliable – it sends datagrams without establishing a connection, no acknowledgments, no retransmissions, and no ordering. TCP is used for applications that require guaranteed delivery (web, email, file transfer). UDP is used for real-time applications that can tolerate some loss (voice, video, gaming) or for simple query/response protocols (DNS, DHCP).
No. UDP is an unreliable protocol. It does not provide acknowledgments or retransmissions. If a UDP packet is lost due to network congestion or errors, it is not resent. The application using UDP must handle loss if needed. However, UDP includes a checksum for error detection; if the checksum fails, the packet is discarded.
The three-way handshake is the process TCP uses to establish a connection. Step 1: The client sends a SYN segment with an initial sequence number (ISN). Step 2: The server responds with a SYN-ACK segment, acknowledging the client's SYN and sending its own ISN. Step 3: The client sends an ACK segment, acknowledging the server's SYN. After this, the connection is established and data can flow. This handshake ensures both sides are ready to communicate.
DNS uses UDP for most queries because it is lightweight and fast. A typical DNS query is a single request and response. Using TCP would add the overhead of connection establishment (three-way handshake) and teardown, which is unnecessary for a simple exchange. However, if the response is larger than 512 bytes (or 4096 with EDNS0), DNS falls back to TCP to ensure reliable delivery of the large response. Zone transfers also use TCP.
The TCP window size is a 16-bit field in the TCP header that indicates the number of bytes the receiver is willing to accept (receive buffer space). It is used for flow control – the sender cannot send more than the window size without receiving an acknowledgment. The window size can be scaled using the Window Scale option (RFC 1323) to allow windows larger than 65535 bytes.
Yes, but it is not common because UDP does not guarantee delivery. Some custom applications use UDP with application-layer reliability (e.g., TFTP uses UDP with its own timeout and retransmission). However, for general file transfer, TCP is preferred because it handles reliability automatically. Using UDP for file transfer would require the application to implement sequencing, acknowledgments, and retransmissions, which essentially reinvents TCP.
TCP has higher overhead than UDP. The TCP header is at least 20 bytes (up to 60 with options), while the UDP header is only 8 bytes. Additionally, TCP requires connection establishment (three-way handshake) and connection termination (four-way handshake), adding latency. TCP also requires state maintenance (sequence numbers, timers, buffers) on both ends. UDP is stateless and has minimal overhead, making it faster for small transactions.
You've just covered TCP vs UDP: When to Use Each — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?