TCP, UDP, Ports, and Common Applications

Why Ports Are Fast Clues

An IP address identifies a host or interface; a transport protocol plus a port identifies the application conversation. A firewall rule that allows TCP 443 isn't "allowing a server" — it allows HTTPS-style traffic to whatever listens on that port. For CC you do not memorize every port, but you must recognize the common ones and infer what a port clue means.

TCP and UDP

Transmission Control Protocol (TCP) is connection-oriented. It opens a session with the three-way handshake (SYN, SYN-ACK, ACK), then uses sequence numbers, acknowledgments, retransmission, and flow control to guarantee ordered, reliable delivery. Applications pick TCP when correctness matters more than overhead: web (HTTP/HTTPS), SSH administration, SMTP mail transfer, FTP control, and RDP.

User Datagram Protocol (UDP) is connectionless. It has no handshake and makes no delivery or ordering guarantee on its own — just a small header and a checksum. Applications pick UDP for low overhead and real-time speed: DNS queries (UDP 53), DHCP, SNMP, and many voice/video and VPN data paths, where retransmitting a stale real-time packet is worse than dropping it.

Avoid the trap "TCP is secure, UDP is insecure." Neither encrypts by itself. Security depends on the application protocol, its configuration, authentication, and encryption — not the transport layer.

Common Ports and Protocols

Reading Direction and Intent

A firewall log showing an internal laptop reaching 203.0.113.10 on TCP 443 is likely outbound HTTPS — normal browsing. The same laptop hitting an internal host on TCP 3389 suggests Remote Desktop. If many clients suddenly query an unknown external resolver on UDP 53, suspect misconfiguration or malware command-and-control. An admin opening TCP 22 from a management subnet to a Linux server aligns with legitimate SSH.

Ports also drive least privilege. A web server should accept inbound TCP 443 from users, make outbound DNS only to approved resolvers, and allow management only from an admin network. It should not expose inbound FTP, RDP, or database ports to the internet. A good rule specifies source, destination, protocol, port, and business purpose.

Choosing Secure Protocols

Many protocols have insecure legacy forms. Telnet sends credentials in cleartext; SSH protects the session — a question asking for "secure command-line administration" points to SSH. HTTP offers no confidentiality; HTTPS uses Transport Layer Security (TLS) — a question about protecting browser sessions points to HTTPS. FTP exposes credentials and data, so use SFTP or FTPS for sensitive transfers. SNMPv1/v2c rely on weak community strings; SNMPv3 adds authentication and encryption.

Practical Scenario

A small office reports users can browse websites but a guest network hands out no addresses. Web browsing proves some paths work, but DHCP is a local broadcast/relay exchange on UDP 67/68, unrelated to HTTPS. Investigate whether the guest VLAN has a DHCP scope, whether a DHCP relay is configured, whether a rogue server interferes, and whether an access rule blocks the exchange. Strong CC reasoning links the port to the function, the function to the symptom, and the symptom to a next step.

Well-Known, Registered, and Dynamic Ranges

Ports are 16-bit numbers (0 to 65535) split into three ranges, and the exam occasionally tests the concept rather than a specific number:

In a single TCP conversation, the server listens on a fixed well-known or registered port while the client picks a random high ephemeral source port. So a firewall log line of "laptop:51234 to server:443" reads as the laptop initiating an outbound HTTPS request — the high number is just the client's temporary port, not a service. Misreading the ephemeral port as the target is a common beginner error the exam likes to expose.

The Handshake and Why It Matters for Security

TCP's three-way handshake (SYN, SYN-ACK, ACK) is not trivia — it underpins security clues. A SYN flood is a denial-of-service attack that sends many SYNs but never completes the handshake, exhausting the server's half-open connection table. A port scanner exploits handshake behavior too: an open TCP port replies SYN-ACK, a closed port replies RST, and a filtered port (blocked by a firewall) gives no reply at all. When a scenario describes "thousands of incomplete connection attempts" or "a host probing sequential ports," connect it to TCP's connection mechanics rather than to an application bug.

Stateful Filtering in One Sentence

A stateful firewall tracks the handshake and connection state, so it can automatically permit the return traffic of a connection it already allowed outbound — which is why you usually write rules for the initiating direction only. This is the practical reason least-privilege rules focus on the source that starts the conversation.