This chapter provides a comprehensive comparison of TCP (Transmission Control Protocol) and UDP (User Datagram Protocol), two core transport layer protocols in the TCP/IP suite. For the N10-009 exam, understanding their differences, mechanisms, and appropriate use cases is critical, as transport layer questions appear in roughly 10-15% of exam items. We will cover header fields, connection establishment, reliability features, and practical scenarios to ensure you can select the correct protocol for a given application.
Jump to a section
Think of TCP as a phone call and UDP as sending a postcard. When you make a phone call, you first dial the number, and the other person answers with 'Hello?'—that's the three-way handshake (SYN, SYN-ACK, ACK). Once connected, you talk in sequence; if the line crackles and you miss a word, you say 'Say again?' and the speaker repeats it—that's retransmission. The conversation is ordered and reliable. In contrast, sending a postcard is connectionless: you drop it in the mailbox without knowing if the recipient is there. The postcard might get lost, arrive out of order, or be duplicated—no confirmation. If you send 10 postcards, they might arrive in any order or not at all. TCP is like the phone call: it guarantees delivery, order, and error checking, but it adds overhead (dialing, repeating). UDP is like the postcard: fast and lightweight but no guarantees. In networking, TCP is used for web pages and email where every byte matters, while UDP is used for streaming video and online gaming where speed matters more than occasional lost packets.
Transport layer protocols (Layer 4 of the OSI model) provide end-to-end communication services for applications. TCP and UDP are the two primary protocols in the TCP/IP suite. TCP (RFC 793) is connection-oriented, reliable, and ensures ordered delivery of data. UDP (RFC 768) is connectionless, lightweight, and provides no reliability guarantees. They exist to serve different application needs: TCP for applications that require data integrity (e.g., web, email, file transfer), UDP for applications where speed and low latency are more important than perfect reliability (e.g., streaming, VoIP, gaming).
How TCP Works Internally
TCP provides a reliable byte stream service. Before data transfer, it establishes a connection using a three-way handshake:
The client sends a SYN segment with an initial sequence number (ISN).
The server responds with SYN-ACK, acknowledging the client's SYN and sending its own ISN.
The client sends an ACK, completing the handshake.
After connection establishment, data is segmented into TCP segments. Each segment includes a sequence number for ordering and an acknowledgment number to confirm receipt. TCP uses a sliding window for flow control, and congestion control algorithms (e.g., slow start, congestion avoidance) to prevent network overload. If a segment is lost (detected by timeout or duplicate ACKs), TCP retransmits it. The receiver sends cumulative ACKs; if the sender receives three duplicate ACKs, it triggers fast retransmit without waiting for timeout.
TCP header fields (minimum 20 bytes):
Source Port (16 bits)
Destination Port (16 bits)
Sequence Number (32 bits)
Acknowledgment Number (32 bits)
Data Offset (4 bits)
Reserved (3 bits)
Flags (9 bits): URG, ACK, PSH, RST, SYN, FIN, etc.
Window Size (16 bits)
Checksum (16 bits)
Urgent Pointer (16 bits)
Options (variable)
Key timers:
Retransmission Timeout (RTO): dynamically calculated based on round-trip time (RTT). Default initial RTO is 1 second (RFC 6298).
Keepalive timer: default 2 hours (can be configured).
How UDP Works Internally
UDP is a minimal transport protocol. It provides no connection setup, no reliability, no ordering, and no flow control. Applications using UDP send datagrams directly to the destination. Each UDP datagram is independent; there is no relationship between successive datagrams.
UDP header (8 bytes fixed):
Source Port (16 bits)
Destination Port (16 bits)
Length (16 bits) – includes header and data, minimum 8
Checksum (16 bits) – optional in IPv4 (but usually used), mandatory in IPv6
UDP is often used by applications that can tolerate some data loss, such as:
DNS (port 53)
DHCP (ports 67/68)
TFTP (port 69)
SNMP (ports 161/162)
Streaming media (RTP over UDP)
Online gaming
Key Differences and Interactions
Connection: TCP is connection-oriented; UDP is connectionless.
Reliability: TCP ensures delivery via ACKs and retransmissions; UDP does not.
Ordering: TCP delivers data in order; UDP does not guarantee order.
Flow control: TCP uses window scaling; UDP has none.
Congestion control: TCP implements congestion avoidance; UDP does not.
Overhead: TCP header is 20-60 bytes; UDP header is 8 bytes.
Speed: TCP has higher latency due to handshake and ACKs; UDP is faster.
Configuration and Verification Commands
On Windows:
- netstat -an shows active connections with protocol (TCP/UDP), local/foreign addresses, state.
- netstat -s displays per-protocol statistics (segments sent/received, errors).
On Linux:
- ss -tuln shows listening TCP (-t) and UDP (-u) sockets with numeric addresses.
- netstat -s or cat /proc/net/snmp for protocol statistics.
- tcpdump -i eth0 tcp or udp to capture packets.
On Cisco IOS:
- show ip sockets displays UDP/TCP socket information.
- show tcp brief shows TCP connections.
Interaction with Related Technologies
NAT: TCP and UDP both work with NAT. NAT must track session state for TCP (via sequence/ack numbers) and for UDP uses timers and port mappings. UDP NAT traversal is more complex; applications often use STUN or TURN.
Firewalls: Stateful firewalls track TCP connection state (SYN, SYN-ACK, ACK) and allow return traffic. For UDP, firewalls create temporary pinholes based on source/destination IP and port, with a timeout (typically 30-60 seconds).
QoS: TCP traffic can be shaped using congestion control; UDP traffic often requires traffic policing or rate limiting to prevent starvation of TCP.
IPv6: Both TCP and UDP operate identically over IPv6; the checksum in UDP becomes mandatory for IPv6.
TCP Connection Establishment (Three-Way Handshake)
The client sends a TCP segment with the SYN flag set and an initial sequence number (ISN), say 1000. The server receives it and responds with a segment that has both SYN and ACK flags set, acknowledging the client's ISN (ACK = 1001) and providing its own ISN, say 2000. Finally, the client sends an ACK segment (ACK = 2001) to confirm receipt. After this, the connection is established and data transfer can begin. The handshake ensures both sides are ready and synchronizes sequence numbers. If the client sends a SYN and the server does not respond, the client will retransmit after a timeout (default 1 second, then doubled).
Data Transfer with Sequence and Acknowledgment Numbers
Once connected, data is broken into segments. Each segment carries a sequence number indicating the position of the first byte in the data stream. The receiver sends back an acknowledgment number equal to the next expected byte. For example, if the sender sends bytes 1-100 with seq=1, the receiver sends ACK=101. If a segment is lost (e.g., bytes 101-200), the receiver will keep sending ACK=101 for any subsequent segments, causing the sender to retransmit after three duplicate ACKs (fast retransmit). The sender also maintains a retransmission timer (RTO) that adapts to network RTT.
TCP Connection Termination (Four-Way Handshake)
When one side wants to close, it sends a FIN segment. The other side acknowledges with ACK, then later sends its own FIN. The first side acknowledges that FIN. This is a four-way handshake. For example, client sends FIN, server responds with ACK, then server sends FIN, client responds with ACK. Each FIN requires an ACK. After the final ACK, the client enters TIME_WAIT state for 2*MSL (typically 60 seconds) to ensure the last ACK is received. Premature closure can lead to half-open connections.
UDP Datagram Sending (Connectionless)
The application sends data to the UDP socket, which encapsulates it into a UDP datagram with source and destination ports, length, and checksum. The datagram is then passed to IP for delivery. There is no handshake; the sender simply transmits. The receiver's UDP layer checks the checksum (if used) and delivers the data to the application if the port is open; otherwise, it may send an ICMP Port Unreachable message. No acknowledgment is sent. If the datagram is lost, the application must detect and handle it.
Handling of Lost or Out-of-Order Datagrams
UDP does not track lost datagrams. If a datagram is lost due to network congestion or errors, the sender is not notified. The receiver may receive datagrams out of order because they may take different paths; UDP does not reorder them. The application must implement its own mechanisms if needed. In contrast, TCP will detect loss via timeout or duplicate ACKs and retransmit, and it will buffer out-of-order segments until the missing ones arrive, then deliver in order.
In enterprise networks, TCP and UDP are deployed based on application requirements. For example, a company's web servers (HTTP/HTTPS) use TCP to ensure web pages load completely and correctly. Misconfiguring a firewall to block TCP ACKs would break all web traffic. For VoIP, UDP is used with RTP to minimize latency. A common issue is UDP flooding: if a misconfigured application sends high-rate UDP traffic, it can saturate links and cause TCP flows to back off due to congestion control, leading to poor performance for critical TCP services. Network engineers often implement QoS to prioritize TCP ACKs and limit UDP traffic.
Another scenario is DNS: DNS queries typically use UDP on port 53. If a DNS response exceeds 512 bytes (with EDNS0, up to 4096 bytes), it may switch to TCP. A firewall that blocks TCP port 53 will cause DNS failures for large responses. Engineers must allow both UDP and TCP for DNS.
In cloud environments, load balancers can handle TCP and UDP. For TCP, they perform connection termination and health checks via TCP SYN. For UDP, they rely on application-level health checks (e.g., sending a query and expecting a response). Misconfiguring health checks can cause the load balancer to mark a healthy backend as down.
Performance considerations: TCP's congestion control can cause throughput issues on high-latency links (e.g., satellite). Tuning TCP window size and using window scaling (RFC 1323) is essential. UDP does not have these mechanisms, so applications must implement their own rate control. For example, video streaming applications often use adaptive bitrate over UDP to avoid congestion collapse.
Common misconfigurations: Setting TCP keepalive too low (e.g., 10 seconds) can cause premature connection drops in NAT environments. For UDP, not setting appropriate timeouts in stateful firewalls can cause legitimate traffic to be blocked after idle periods. A typical UDP firewall timeout is 30 seconds; if an application sends packets every 60 seconds, the firewall will drop the session.
The N10-009 exam tests TCP and UDP under Objective 1.1: 'Compare and contrast the OSI model layers and encapsulation concepts' and Objective 1.2: 'Explain the characteristics of network topologies and network types' but primarily under 1.3: 'Summarize the types of cables and connectors and explain which is the appropriate type for a solution'? Actually, transport layer protocols are tested under 1.4: 'Given a scenario, configure a subnet and use appropriate IP addressing schemes'? No, the exact objective is 1.5: 'Explain common ports and protocols, their application, and encrypted alternatives.' But the comparison itself is fundamental and appears in many questions.
Common wrong answers: 1. 'UDP is faster than TCP because it has a smaller header.' While UDP header is smaller, the main speed advantage is lack of handshake and ACKs. Candidates often think smaller header is the primary reason; but the overhead of ACKs and congestion control is larger. 2. 'TCP guarantees delivery by using a checksum.' Checksum only detects errors; retransmissions guarantee delivery. 3. 'UDP does not use ports.' UDP uses ports just like TCP; both have 16-bit source/destination port fields. 4. 'TCP is used for streaming video because it is reliable.' Actually, streaming video often uses UDP to avoid retransmission delays; if a packet is lost, it's better to skip it than wait for retransmission.
Specific numbers to memorize:
TCP header minimum 20 bytes, maximum 60 bytes.
UDP header fixed 8 bytes.
TCP port numbers: HTTP (80), HTTPS (443), FTP (20,21), SSH (22), Telnet (23), SMTP (25), POP3 (110), IMAP (143).
UDP port numbers: DHCP (67,68), DNS (53), TFTP (69), SNMP (161,162), NTP (123).
TCP flags: SYN, ACK, FIN, RST, PSH, URG.
Edge cases: The exam may ask which protocol is used for a specific application. For example, 'Which transport protocol does DHCP use?' Answer: UDP. Or 'Which protocol provides flow control?' TCP. Also, be aware that some applications use both: DNS uses UDP primarily but falls back to TCP for large responses. The exam may present a scenario where a firewall blocks UDP, causing DNS failures for large queries.
How to eliminate wrong answers: If the question mentions 'reliable delivery' or 'guaranteed order', eliminate UDP. If it mentions 'low overhead' or 'no connection setup', eliminate TCP. If it asks about 'three-way handshake', it's TCP. If it asks about 'best-effort delivery', it's UDP.
TCP is connection-oriented, reliable, and ordered; UDP is connectionless, unreliable, and unordered.
TCP uses a three-way handshake (SYN, SYN-ACK, ACK) to establish a connection.
UDP header is fixed at 8 bytes; TCP header is 20-60 bytes.
TCP port 80 (HTTP), 443 (HTTPS); UDP port 53 (DNS), 67/68 (DHCP), 69 (TFTP).
TCP retransmits lost segments; UDP does not.
TCP flow control uses window scaling; UDP has no flow control.
UDP is preferred for real-time applications like VoIP and streaming where low latency is critical.
TCP is used for applications requiring data integrity, such as web browsing, email, and file transfer.
The three-way handshake adds latency; UDP has no setup delay.
Both protocols use port numbers for multiplexing; range 0-65535.
These come up on the exam all the time. Here's how to tell them apart.
TCP
Connection-oriented: requires three-way handshake before data transfer
Provides reliable delivery via acknowledgments and retransmissions
Guarantees in-order delivery of data
Includes flow control (sliding window) and congestion control (slow start, congestion avoidance)
Header size: 20-60 bytes; higher overhead per segment
UDP
Connectionless: no handshake, sends data immediately
No reliability: no ACKs, no retransmissions (best-effort)
No ordering: datagrams may arrive out of order
No flow or congestion control; application must manage
Header size: 8 bytes; minimal overhead
Mistake
UDP is connectionless because it doesn't use ports.
Correct
UDP does use ports (16-bit source and destination ports) to identify applications. It is connectionless because it does not establish a session before sending data.
Mistake
TCP guarantees that data will be delivered without errors.
Correct
TCP guarantees delivery via retransmissions, but errors can still occur if the checksum fails; however, TCP will discard corrupt segments and request retransmission, so the application receives error-free data.
Mistake
UDP is inherently faster than TCP because of its smaller header.
Correct
The primary speed advantage of UDP comes from the lack of connection establishment, acknowledgment overhead, and congestion control. The header size difference (20 vs 8 bytes) is minor compared to the overhead of ACKs and retransmissions.
Mistake
TCP uses a fixed retransmission timeout of 1 second.
Correct
TCP's RTO is dynamically calculated based on measured RTT. The initial RTO may be 1 second (per RFC 6298), but it adapts. After a retransmission, the RTO is doubled (exponential backoff).
Mistake
UDP cannot be used for reliable communication.
Correct
Applications can implement reliability on top of UDP (e.g., using application-layer ACKs, sequence numbers, and retransmissions). QUIC (HTTP/3) uses UDP with reliability built in at the application layer.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
TCP provides reliability by using acknowledgments and retransmissions: if a segment is lost, TCP detects it via timeout or duplicate ACKs and retransmits. UDP does not acknowledge receipt; if a datagram is lost, it is not resent. Therefore, TCP guarantees delivery of all data in order, while UDP does not guarantee delivery or ordering.
DNS queries are typically small (under 512 bytes) and can fit in a single UDP datagram. Using UDP avoids the overhead of a TCP connection (three-way handshake), which would add latency for each query. If a response is larger than 512 bytes, DNS falls back to TCP. Also, DNS is idempotent: if a query is lost, the client can simply retransmit after a timeout.
The three-way handshake is the process used by TCP to establish a connection. It consists of three steps: 1) The client sends a SYN segment with an initial sequence number. 2) The server responds with SYN-ACK, acknowledging the client's SYN and providing its own sequence number. 3) The client sends an ACK to confirm. After this, data can be exchanged. This ensures both sides are ready and synchronizes sequence numbers.
Yes, by implementing reliability at the application layer. For example, TFTP uses UDP but includes application-level acknowledgments and retransmissions. QUIC (used in HTTP/3) runs over UDP but provides reliability, flow control, and encryption. However, this is not part of UDP itself; it is added by the application.
The TCP window size (advertised window) is the amount of data that a receiver can accept without sending an acknowledgment. It is used for flow control. A larger window allows more data in flight, improving throughput, especially on high-latency links. Window scaling (RFC 1323) extends the window beyond 65,535 bytes. On the exam, know that window size is a 16-bit field in the TCP header.
TCP flags are control bits in the TCP header. Common flags: SYN (synchronize for connection setup), ACK (acknowledgment), FIN (finish, close connection), RST (reset connection), PSH (push data immediately), URG (urgent pointer). The exam may ask which flag is used to initiate a connection (SYN) or to gracefully close (FIN).
Streaming video is time-sensitive; if a packet is lost, it's better to skip it than to wait for a retransmission, which would cause a delay and buffer underrun. UDP's lack of retransmission reduces latency. Additionally, TCP's congestion control can reduce throughput, causing video quality to drop. However, some streaming services use TCP with adaptive bitrate to adjust quality based on network conditions.
You've just covered UDP vs TCP Transport Comparison — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?