TCP and UDP
How TCP provides reliable, ordered delivery and how UDP trades that for low overhead, with port numbers and protocol numbers used across the CCNA.
TCP versus UDP
TCP versus UDP
| Property | TCP | UDP |
|---|---|---|
| Delivery | Reliable, acknowledged, retransmitted | Best effort, no retransmission |
| Ordering | Sequenced byte stream | No ordering guarantees |
| Connection | Connection-oriented (3-way handshake) | Connectionless |
| Overhead | 20-byte header minimum | 8-byte header |
| Flow control | Sliding window | None |
| Use when | Loss is unacceptable (web, email, file transfer) | Speed/simplicity matters; loss is tolerable or handled above (DNS, DHCP, VoIP, streaming) |
TCP establishes state before data flows: SYN → SYN-ACK → ACK. Each side picks an initial sequence number; every byte afterwards is numbered so the receiver can reorder, deduplicate and acknowledge. Loss is repaired by retransmission — the sender re-sends unacknowledged segments. Teardown uses FIN/ACK in each direction.
- App
- Live voice call between IP phones
- Requirement
- Real-time audio; a re-sent packet is useless late
- Voice tolerates small loss but not delay — retransmission arrives after the audio slot passed.
- UDP's low overhead and no retransmission suit the timing requirement.
- Reliability (if needed at all — e.g., for signaling) is layered on top or uses TCP separately (SIP can run either).
RTP media uses UDP; the call-signaling protocol may still use TCP.
Protocol numbers and ports
A socket pair — source/destination IP plus source/destination port — identifies one conversation. Servers listen on well-known ports (0–1023); clients pick an ephemeral port. The IP protocol number in the packet header (not a port) names the L4 protocol: 6 = TCP, 17 = UDP, 1 = ICMP.
Common IP protocol numbers
| Protocol number | Protocol | Notes |
|---|---|---|
| 1 | ICMP | Ping, errors, path discovery |
| 2 | IGMP | Multicast group membership |
| 6 | TCP | Reliable stream transport |
| 17 | UDP | Lightweight datagram transport |
| 50 | ESP | IPsec encapsulated security payload |
| 51 | AH | IPsec authentication header |
| 88 | EIGRP | Cisco interior routing protocol |
| 89 | OSPF | Link-state routing protocol |
Protocol numbers live in the IP header and name the upper-layer protocol — they are not TCP/UDP ports.
Well-known TCP ports
| Port | Service | Purpose |
|---|---|---|
| 20 | FTP data | Active-mode data channel |
| 21 | FTP control | Commands and replies |
| 22 | SSH | Secure remote access and SFTP |
| 23 | Telnet | Insecure remote access |
| 25 | SMTP | Mail transfer |
| 53 | DNS | Zone transfers and large responses |
| 80 | HTTP | Unencrypted web |
| 110 | POP3 | Mail retrieval |
| 143 | IMAP | Mail access |
| 443 | HTTPS | Encrypted web |
| 179 | BGP | Inter-AS routing (context) |
Well-known UDP ports
| Port | Service | Purpose |
|---|---|---|
| 53 | DNS | Standard name queries |
| 67/68 | DHCP | Server / client |
| 69 | TFTP | Trivial file transfer |
| 123 | NTP | Time synchronization |
| 161 | SNMP | Agent polling |
| 162 | SNMP traps | Manager receives notifications |
| 514 | Syslog | Log forwarding |
| 520 | RIP | Routing updates (context) |
| 1812/1813 | RADIUS | Authentication / accounting |
| 500 | IKE | IPsec key exchange |
Verifying and diagnosing
Verifying transport behavior
- On the host:
netstat -an(Windows/Linux) shows listening ports and established sessions. - On the device: ACL counters and
show access-listsreveal whether TCP/UDP traffic actually matched your permit/deny logic. - A handshake stuck at SYN with no SYN-ACK suggests filtering or a dead listener — check ports, not the routing table first.
Common mistakes
- Confusing the IP protocol number with a TCP/UDP port — they live in different headers.
- Assuming DNS is UDP-only — zone transfers and oversized responses use TCP 53.
- Expecting UDP to recover lost packets — any reliability must come from the application.
- Treating SNMP traps as arriving on the agent's port — traps are received by the manager on UDP 162.
Observation: Ping to the server succeeds; the client times out connecting.
- Service not listening on the expected port
- ACL or firewall filtering the destination port
- Wrong transport (client uses TCP, service is UDP-only)
| Check | Indicates |
|---|---|
netstat -an on the server | Confirms the daemon listens and on which port/transport. |
| Test the port specifically (telnet/nc to the port, or a UDP probe) | Reaches the port → service issue; filtered → path/security issue. |
| ACL counters on the path | Denied hits identify the blocking rule. |
Correction: Open the required port/protocol on the policy or point the client at the correct endpoint.
Connection establishes; netstat shows the session in ESTABLISHED state.
Related resources
Sources
- Cisco CCNA 200-301 v1.1 Exam Topics (official PDF) — reviewed 2026-11-02
- RFC 9293 — Transmission Control Protocol (TCP) — reviewed 2026-11-02
- RFC 768 — User Datagram Protocol — reviewed 2026-11-02
Targets CCNA 200-301 v1.1 objectives. Supplemental blocks are labeled beyond exam scope.