CompTIA Network+ (N10-008): Common Ports, Protocols, and Secure Alternatives Explained

1. Introduction: Why ports and protocols matter in Network+

If you understand ports, protocols, and their secure alternatives, you can answer a big chunk of Network+ questions with confidence.

Honestly, you’ll bump into this stuff everywhere — when you’re troubleshooting a weird outage, building firewall rules, checking what’s actually listening on a server, or just trying to tighten the whole environment up from a security angle.

It also matters in the real world: a server can respond to ping and still have a broken application because the service port is blocked, the daemon is down, or TLS is failing.

The best study pattern is: service → port → transport → purpose → secure alternative → troubleshooting clues. That keeps you from memorizing random numbers with no context and helps you think like an admin instead of a flashcard machine.

2. Foundations: ports, protocols, and how traffic is identified

A protocol is a set of communication rules. A port is a logical number used by TCP or UDP to deliver traffic to the correct application. An IP address gets traffic to the right host; the port gets it to the right service.

Ports are commonly grouped into:

• Well-known: 0-1023
• Registered: 1024-49151
• Dynamic/ephemeral: 49152-65535

For a listening service, you usually care about destination IP + transport protocol + destination port, such as 192.168.10.20:443/TCP. For an actual conversation, the connection is tracked by a 5-tuple: source IP, source port, destination IP, destination port, and protocol.

Example: a client might connect as 10.1.1.50:51514 → 10.1.10.20:443 TCP.

The client uses an ephemeral source port, while the server is sitting there listening on 443.

That matters a lot when you’re dealing with NAT, stateful firewalls, and real-world troubleshooting.

Return traffic is allowed because the firewall tracks the session state, not because you opened every ephemeral port inbound.

An open port only means something is listening.

That listener could be the actual app, a proxy, a load balancer, or even a port-forward rule sitting on the firewall.

It does not prove the full transaction works.

3. TCP/IP context and transport behavior

At Network+ level, think in layers: application protocols such as HTTP, DNS, SMTP, and LDAP ride on TCP or UDP; those are carried by IP. ICMP is carried within IP and is used for control and diagnostics.

TCP is connection-oriented and reliable. It uses the three-way handshake: SYN, SYN-ACK, ACK.

It also gives you sequencing, acknowledgments, retransmissions, and flow control, which is why it’s the better choice when delivery really matters. That’s why it’s the go-to when you can’t afford to just lose data and hope for the best.

That reliability is why TCP is used for web sessions, SSH, email, LDAP, SMB, and many admin tasks.

UDP is connectionless and lightweight. UDP doesn’t give you built-in delivery guarantees. That lower overhead is exactly why it works so well for DNS queries, DHCP, NTP, SNMP, and real-time media like RTP. UDP is not automatically “better”; it is simply better for traffic that values low latency or simplicity over guaranteed delivery.

ICMP helps with diagnostics.

Ping is a good example here — it uses ICMP echo request and echo reply.

Traceroute behavior varies by tool: Windows tracert typically uses ICMP, while many Unix/Linux traceroute implementations use UDP high ports by default; some tools can also use TCP. If ping works but the app fails, IP reachability exists, but the transport or application layer may still be broken.

4. Core ports and protocols you need to know

5. High-yield protocol groups and exam traps

Remote access: Telnet 23 is plaintext; SSH 22 is the secure replacement. RDP uses TCP/UDP 3389; lock it down with VPN access, MFA, and ideally Network Level Authentication.

Web: HTTP 80 is plaintext; HTTPS 443 uses TLS. HTTPS depends on certificate validity, hostname matching, trust chain, and correct system time.

File transfer: FTP uses TCP 21 for control and traditionally TCP 20 for active-mode data. In passive FTP, the server opens a negotiated high port for data, which is why FTP often breaks through firewalls and NAT if not handled correctly. SFTP is SSH-based and usually simpler to secure. FTPS keeps the FTP model but adds TLS. SCP is still used, but SFTP is usually preferred for flexibility and modern support. TFTP 69 is lightweight but insecure.

Email: SMTP 25 is mainly relay between servers. Client submission commonly uses 587 with STARTTLS or 465 with implicit TLS. POP3 on 110 or 995 is used to retrieve mail, and it’s usually the more download-oriented option. IMAP on 143 or 993 keeps mail synced across multiple devices, which is why it’s usually the better fit if someone checks mail from a phone, laptop, and tablet. Exam trap: SMTP sends, POP3/IMAP retrieve.

Infrastructure: DNS 53 uses UDP for most queries and TCP for zone transfers or larger responses.

DHCP uses UDP 67 and 68, and the basic flow is DORA: Discover, Offer, Request, Acknowledge.

If DHCP fails in IPv4, a client may self-assign a 169.254.x.x link-local/APIPA address. In IPv6, fe80::/10 link-local is normal and not the same thing as DHCP failure. NTP 123 keeps time aligned for logs, Kerberos, and TLS.

Management and monitoring: SNMP uses UDP 161 for polling and 162 for traps. SNMPv1/v2c rely on community strings; SNMPv3 adds authentication and privacy. Syslog traditionally uses UDP 514, but secure syslog commonly uses TCP 6514 with TLS.

Directory and authentication: LDAP commonly uses TCP 389. In practice, think TCP first, not UDP. It can be secured with StartTLS on 389 or LDAPS on 636. Kerberos uses TCP/UDP 88 and depends heavily on accurate time and working DNS.

Voice: SIP 5060/5061 handles signaling. The actual audio usually rides over RTP/RTCP on dynamically negotiated UDP ports. Securing SIP with TLS protects signaling only; SRTP is used to protect media. Exam trap: successful registration does not guarantee working audio.

6. Quick technical depth: DNS, DHCP, and TCP behavior

DNS: Know common record types: A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail), PTR (reverse lookup), and TXT.

Most clients ask a recursive resolver first, and if that resolver doesn’t already have the answer, it handles the iterative lookups behind the scenes.

Split DNS means internal and external answers may differ for the same name.

DHCP: Across VLANs, broadcasts do not cross routers by default, so you often need a DHCP relay/IP helper. Common failure points are exhausted scopes, missing relay configuration, rogue DHCP servers, and bad reservations.

TCP states: On a host, tools such as netstat or ss may show LISTEN, ESTABLISHED, or TIME_WAIT. Those states help you tell the difference between “service not listening,” “connection active,” and “session recently closed.”

7. Troubleshooting workflow and practical commands

Use a layered workflow: link/IP reachability → name resolution → port reachability → application behavior → security/TLS.

Useful tools:

• Windows: ping, tracert, ipconfig /all, nslookup, netstat -ano, Test-NetConnection host -Port 443
• Linux/macOS: ping, traceroute, ip a, ss -tulpen, dig, nc -zv host 443, curl -vk , openssl s_client -connect host:443

A TCP port test proves connectivity only. It does not prove HTTPS, LDAPS, or SMTP over TLS is healthy. For TLS services, use a browser or command-line validation tools to check certificates, hostname matching, protocol versions, and trust.

Common patterns:

• Ping works, app fails: likely blocked port, service down, or TLS/application issue.
• Name fails, IP works: DNS problem, not basic routing.
• Can send mail but not receive: SMTP works; IMAP/POP3 or secure settings are wrong.
• VoIP registers but has one-way audio: SIP signaling works; RTP media ports are blocked.
• Monitoring sees no alerts: check SNMP 161 vs 162 confusion, ACLs, and SNMP version.

8. Firewall, NAT, and hardening considerations

Open only what is required, and restrict by source, destination, and network zone. Stateful firewalls track sessions, so outbound client connections to server ports such as 443 or 22 do not require inbound ephemeral ports to be manually opened.

NAT/PAT also affects troubleshooting. Example: 10.1.1.50:51514 → 198.51.100.10:443 may be translated at the edge to 203.0.113.25:62001 → 198.51.100.10:443. If inbound publishing is wrong, the public port may respond while the internal service is unreachable.

Hardening priorities: replace Telnet, FTP, and plain HTTP; restrict RDP and SSH to management paths; prefer SNMPv3; disable legacy SMBv1; keep SMB segmented; and protect logging and directory traffic with TLS where possible.

9. Network+ exam prep: what to know cold

Must-memorize ports: 20/21 FTP, 22 SSH/SFTP, 23 Telnet, 25 SMTP, 53 DNS, 67/68 DHCP, 69 TFTP, 80 HTTP, 110/995 POP3/POP3S, 123 NTP, 143/993 IMAP/IMAPS, 161/162 SNMP, 389/636 LDAP/LDAPS, 443 HTTPS, 445 SMB, 3389 RDP, 5060/5061 SIP/SIP-TLS, 88 Kerberos.

Common distractors:

• SSH vs Telnet: secure remote CLI = SSH
• SMTP vs IMAP/POP3: sending = SMTP, retrieval = IMAP/POP3
• IMAP vs POP3: multi-device sync = IMAP
• DNS UDP vs TCP: UDP most queries, TCP zone transfers/large responses
• SNMP 161 vs 162: polling on 161, traps on 162
• LDAP 389 vs LDAPS 636: StartTLS can secure 389; 636 is LDAP over TLS from the start
• SIP vs RTP: SIP sets up the call; RTP carries the media

One final exam tip: Network+ often tests purpose + transport + secure alternative, not just the port number. If you can identify the service, explain whether it uses TCP, UDP, or both, and name the secure version, you are in very good shape.

10. Conclusion

Ports identify services, protocols define behavior, and secure alternatives matter.

For Network+, don’t memorize the numbers in isolation.

Tie each protocol to its purpose, transport, risks, and troubleshooting pattern. If you can look at a symptom and think, “That sounds like DNS on 53,” or “That is secure mail submission on 587,” you are thinking the right way for both the exam and real network administration.