7.1 TCP, UDP & Well-Known Ports

Transport-layer protocols decide how data moves between applications once IP has figured out where packets go. For the Cyber Test, two protocols dominate: TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). You must know how they differ, when each is used, and which well-known ports map to common services.

Why Ports Matter

An IP address identifies a host. A port identifies an application or service on that host. Together, IP + port form a socket — the endpoint of a conversation. Without ports, a server could not tell whether an incoming packet is meant for a web server, an SSH daemon, or a mail service.

IANA divides port numbers into ranges:

The Cyber Test focuses on the well-known list. Memorize the mappings below cold — they reappear in firewall, troubleshooting, and protocol questions.

---

TCP vs UDP: Head-to-Head

Exam framing: TCP trades overhead for reliability. UDP trades reliability for speed and simplicity. Neither is "better" in all cases — match the protocol to the application's needs.

---

TCP Deep Dive

TCP establishes a session before exchanging application data. The classic three-way handshake is:

1. SYN — Client proposes starting a connection and sends an initial sequence number.
2. SYN-ACK — Server acknowledges and sends its own sequence number.
3. ACK — Client acknowledges the server; the connection is established.

After that, data segments travel with sequence numbers and acknowledgments. If a segment is lost, TCP retransmits. If the receiver is slow, TCP can slow the sender (flow control). When either side finishes, a FIN/ACK teardown (or RST for abrupt reset) closes the session.

When TCP Fits

Use TCP when missing or reordered bytes break the application:

• Downloading a file or patch
• Loading a web page (HTTP/HTTPS)
• Sending email (SMTP) or reading mailboxes (IMAP/POP3)
• Interactive remote shells (SSH; historically Telnet)

If one byte of a configuration file or password exchange is wrong, the whole operation fails — so reliability matters.

---

UDP Deep Dive

UDP sends datagrams with almost no ceremony: source port, destination port, length, checksum, and payload. There is no handshake, no retransmission, and no congestion control inside UDP itself. Applications that need reliability must implement it above UDP — or accept occasional loss.

When UDP Fits

• DNS queries: A short question/answer; if lost, the client simply retries.
• DHCP: Broadcast-heavy lease discovery; connection state would add little value.
• Voice/video: Late packets are useless; dropping is better than waiting for retransmission.
• Simple status broadcasts: Low-overhead sensors or discovery protocols.

Remember: DNS commonly uses UDP port 53 for ordinary queries, but can fall back to TCP port 53 for large responses or zone transfers. The port number alone does not always pin the transport.

---

Must-Memorize Well-Known Ports

Drill this table until you can recite it under time pressure:

Memory Hooks

• 20/21 FTP: "data then control" — two ports for one legacy file protocol.
• 22 SSH vs 23 Telnet: SSH is one number earlier and is encrypted; Telnet is the insecure classic.
• 25 SMTP: Mail sending between MTAs.
• 53 DNS: Same number as the OSI "session" mnemonic people invent — just memorize "DNS is fifty-three."
• 67/68 DHCP: Server is 67, client is 68 ("server first").
• 80 / 443: Web cleartext vs web encrypted.
• 110 POP3 / 143 IMAP: Both retrieve mail; IMAP keeps mail on the server.
• 3389 RDP: Windows remote desktop — a common lateral-movement target in security scenarios.

Related Distinctions

• HTTP vs HTTPS: Same application idea; HTTPS wraps HTTP in TLS and uses 443.
• POP3 vs IMAP: POP3 tends to download-and-remove (or download with limited server sync); IMAP is designed for multi-device mailbox access.
• SSH vs Telnet: Same remote-admin role, opposite security posture. Prefer SSH; treat open Telnet as a finding.

---

Firewalls, ACLs, and Exam Traps

Security questions often ask which port to allow or block:

• Allow 443 outbound for secure web browsing; blocking it breaks most modern sites.
• Allow 53 UDP (and sometimes TCP) for name resolution; without DNS, users "have no internet" even if IP routing works.
• 22 open to the world is a risk; restrict by source when possible.
• Seeing 23 or cleartext 80/110 in production often signals weak hygiene.

Trap: Confusing FTP 20/21 with SSH 22, or mixing SMTP 25 with POP3/IMAP. Another trap: assuming every service on a port is always TCP — DHCP and many DNS queries are UDP.

---

Putting It Together

When a browser opens https://example.com:

1. The OS resolves the name (often via DNS/UDP 53).
2. The client picks an ephemeral source port and connects to the server's 443/TCP.
3. TCP completes the three-way handshake.
4. TLS negotiates encryption; then HTTP requests ride inside that secure channel.

If any of those pieces fail — wrong port, blocked UDP DNS, TCP RST — the page does not load. Understanding ports and transport behavior turns vague "network is down" stories into diagnosable steps — exactly the aptitude the Cyber Test is probing.

Quick Self-Check List

Before moving on, you should be able to:

1. Contrast TCP and UDP on reliability, connection state, and overhead.
2. List the three-way handshake steps in order.
3. Map every port in the table above to its service without looking.
4. Explain why DNS and DHCP favor UDP while HTTPS favors TCP.