Study guide
1.4 TCP vs. UDP
Cisco Certified Network Associate CCNA
Track your progress as you read
Finished sections get a check mark.
1 Introduction
About the CCNA 200-301 Exam Domains and Weights Study Strategies and Tips
2 Chapter 1: Network Fundamentals (20%)
1.1 Network Components 1.2 Network Topology Architectures 1.3 Physical Interfaces and Cabling 1.4 TCP vs. UDP 1.5 IPv4 Addressing and Subnetting 1.6 IPv6 Addressing and Prefix 1.7 Wireless Principles 1.8 Virtualization Fundamentals 1.9 Switching Concepts 1.10 OSI and TCP/IP Reference Models 1.11 Verifying IP Parameters on Client Operating Systems
3 Chapter 2: Network Access (20%)
2.1 VLANs — Configuration and Verification 2.2 Trunking and 802.1Q 2.3 Layer 2 Discovery Protocols (CDP and LLDP) 2.4 EtherChannel (Link Aggregation) 2.5 Spanning Tree Protocol (STP) and RSTP 2.6 Wireless Architectures and AP Modes 2.7 Network Access Troubleshooting 2.8 Inter-VLAN Routing — Deep Dive
4 Chapter 3: IP Connectivity (25%)
3.1 Routing Table Components 3.2 Router Forwarding Decisions 3.3 IPv4 and IPv6 Static Routing 3.4 Single-Area OSPFv2 — Concepts 3.5 Single-Area OSPFv2 — Configuration 3.6 First Hop Redundancy Protocols (FHRP) 3.7 Troubleshooting IP Connectivity 3.8 OSPF Troubleshooting Scenarios
5 Chapter 4: IP Services (10%)
4.1 NAT (Network Address Translation) 4.2 DHCP and DNS 4.3 NTP, SNMP, and Syslog 4.4 QoS Fundamentals 4.5 TFTP/FTP and Remote Access 4.6 IP Services — Comprehensive Review
6 Chapter 5: Security Fundamentals (15%)
5.1 Key Security Concepts 5.2 Device Access Control and Password Policies 5.3 VPN Fundamentals 5.4 Access Control Lists (ACLs) 5.5 Layer 2 Security Features 5.6 Network Security Best Practices and Hardening 5.7 Threat Mitigation and Incident Response
7 Chapter 6: Automation and Programmability (10%)
6.1 Impact of Automation on Network Management 6.2 Controller-Based and Software-Defined Architectures 6.3 AI and Machine Learning in Network Operations 6.4 REST-Based APIs 6.5 Configuration Management Tools 6.6 JSON-Encoded Data 6.7 Automation and Programmability — Comprehensive Review
1.4 TCP vs. UDP
Key Takeaways Explain This Topic AI
TCP is connection-oriented and reliable, establishing sessions with a three-way handshake (SYN, SYN-ACK, ACK).
UDP is connectionless and best-effort with no handshake, acknowledgments, retransmission, or ordering.
TCP uses sequence/acknowledgment numbers, windowing for flow control, and a sliding window for throughput.
Choose UDP for latency-sensitive traffic (VoIP, video, DNS queries) where retransmission would hurt more than help.
Memorize key ports: HTTP 80, HTTPS 443, SSH 22, Telnet 23, FTP 20/21, SMTP 25, DNS 53, DHCP 67/68.
Last updated: June 2026
The Transport layer
Layer 4 (Transport) delivers data between applications on hosts and uses port numbers to identify each application session. The two protocols are TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) .
TCP: reliable and connection-oriented
TCP guarantees that data arrives complete, in order, and error-checked . It achieves this with:
Three-way handshake to open a session: the client sends SYN , the server replies SYN-ACK , the client answers ACK . Memorize this order.
Sequence and acknowledgment numbers that let the receiver reassemble segments in order and detect loss.
Retransmission : any unacknowledged segment is re-sent.
Flow control via windowing : the receiver advertises a window size stating how many bytes it can buffer; a sliding window lets the sender transmit multiple segments before waiting for an ACK, improving throughput.
Connection teardown using FIN/ACK exchanges.
The overhead of acknowledgments and retransmission is the price of reliability. Use TCP when every byte must arrive: web (HTTP/HTTPS), email (SMTP), file transfer (FTP), and remote login (SSH).
UDP: fast and connectionless
UDP simply sends datagrams with no handshake, no acknowledgments, no sequencing, and no retransmission. Its header is only 8 bytes versus TCP's 20+ bytes, so it has minimal overhead and latency. UDP is ideal where speed beats perfect delivery : a dropped VoIP packet should be skipped, not re-sent late, because a late packet arrives after the conversation has moved on.
Side-by-side
- Feature TCP UDP
- Connection Connection-oriented (handshake) Connectionless
- Reliability Guaranteed, retransmits lost data Best-effort, no retransmission
- Ordering In-order via sequence numbers No ordering
- Flow control Yes (windowing) No
- Header size 20+ bytes 8 bytes
- Speed/overhead Higher overhead Lower overhead, faster
- Typical use Web, email, file transfer, SSH VoIP, streaming, DNS, gaming
- Well-known ports to memorize
- Service Port(s) Protocol
- FTP (data/control) 20 / 21 TCP
- SSH 22 TCP
- Telnet 23 TCP
- SMTP 25 TCP
- DNS 53 UDP (queries), TCP (zone transfer)
- DHCP 67 / 68 UDP
- TFTP 69 UDP
- HTTP 80 TCP
- HTTPS 443 TCP
- SNMP 161 / 162 UDP
- Worked example
A real-time video call drops 0.5% of packets. With UDP , the codec conceals the loss and the call continues smoothly. If it ran over TCP , the protocol would pause to retransmit each lost segment, injecting jitter and delay that ruin the call, so VoIP and live video use UDP.
Sockets, sequencing, and windowing in depth
A socket is the pairing of an IP address and a port, and a full connection is identified by four values: source IP, source port, destination IP, destination port. The client picks a high ephemeral port (commonly 49152-65535) as its source while contacting the server's well-known port (0-1023). This is why thousands of browser tabs can all reach port 443, each uses a different source port, so each socket pair is unique.
Sequence numbers count bytes, not segments, letting TCP detect exactly which bytes were lost and reorder out-of-sequence arrivals. The acknowledgment number tells the sender the next byte the receiver expects. Windowing is the receiver advertising how many unacknowledged bytes it can hold; a sliding window then lets the sender keep multiple segments in flight, and the window grows or shrinks dynamically to match the receiver's buffer, this is flow control . Separately, TCP's congestion control (slow start) reacts to network loss, do not confuse the two on the exam.
Ports by transport protocol
A quick way to remember which protocol carries each service:
TCP (reliability matters): HTTP 80, HTTPS 443, SSH 22, Telnet 23, FTP 20/21, SMTP 25.
UDP (speed matters): TFTP 69, SNMP 161/162, DHCP 67/68, most DNS queries 53.
Either : DNS uses UDP 53 normally but TCP 53 for zone transfers and oversized replies.
Ports 0-1023 are well-known , 1024-49151 are registered , and 49152-65535 are dynamic/ephemeral , a range distinction the exam occasionally asks about directly.
Common traps
DNS uses UDP/53 for normal lookups but switches to TCP/53 for large responses and zone transfers, both can appear as correct.
The handshake order is SYN, SYN-ACK, ACK, not SYN, ACK, SYN-ACK.
UDP has no flow control or windowing, do not attribute TCP features to it.
Windowing is flow control (receiver-paced), distinct from congestion control.
A connection is identified by the four-tuple , not by the server port alone.
TCP reliability mechanisms in action
When a segment is lost, the receiver keeps acknowledging the last in-order byte it got (a duplicate ACK ). After the sender sees repeated duplicate ACKs, it performs a fast retransmit , resending the missing segment without waiting for a full timeout. This loss-recovery behavior is what makes TCP reliable but also what makes it a poor fit for real-time media, the recovery delay is unacceptable for a live call. Meanwhile the window size field continuously tunes how much unacknowledged data may be outstanding, throttling a fast sender so it does not overrun a slow receiver's buffer.
Choosing TCP vs UDP: decision guide
Need every byte, in order, intact -> TCP (file transfer, web pages, email, database).
Need lowest latency and can tolerate loss -> UDP (VoIP, live video, online gaming).
Small request/response where retransmission is handled by the app -> UDP (DNS query, DHCP, SNMP).
Bulk reliable transfer of large files -> TCP (FTP, HTTPS downloads).
The exam frequently frames this as a scenario: match the application's tolerance for delay versus loss to the right protocol, rather than memorizing a list. A late packet that arrives after it is useful is worse than a dropped one for real-time media, which is the core reasoning behind every UDP answer.