Do not study ports as orphan numbers
The useful unit of knowledge is not “443 = HTTPS.” It is “HTTPS commonly uses TCP 443, usually protects web application traffic with TLS, and a failed TCP/443 connection after successful DNS points toward path, policy, listener, TLS, or application state.” That fuller connection turns memorization into troubleshooting and firewall reasoning.
High-value services and what they actually tell you
| Service | Common transport/port | Role | Useful troubleshooting clue |
|---|---|---|---|
| DNS | UDP/TCP 53 | Name resolution | Successful query proves resolver behavior, not application health |
| DHCP | UDP 67/68 | Dynamic IPv4 configuration | APIPA suggests expected lease was not obtained |
| HTTP | TCP 80 | Unencrypted web traffic | Port success does not prove HTTPS |
| HTTPS | TCP 443 | TLS-protected web traffic | DNS success + 443 failure moves beyond name resolution |
| SSH | TCP 22 | Secure remote administration | Prefer over plaintext Telnet for admin access |
| Telnet | TCP 23 | Legacy remote terminal | Lacks modern transport confidentiality |
| FTP | TCP 21 control | File transfer | Control success does not prove data path |
| SFTP | TCP 22 | File transfer over SSH | Not FTP with a different port |
Swipe horizontally to see the service matrix.
DNS can use both UDP and TCP on port 53
Many ordinary DNS lookups use UDP, but TCP is also part of DNS behavior. Students should avoid the oversimplification that DNS is “UDP only.” The right question is whether the required DNS transaction succeeds and whether the answer is the expected one.
Different DNS failures support different branches
Timeout
Resolver may be unreachable, filtered, overloaded, or otherwise not responding.
Wrong record
DNS works, but the returned data may be stale or misconfigured.
Expected answer
Move beyond DNS if the application still fails.
DHCP works before the client has ordinary configuration
Classic IPv4 DHCP uses UDP 67 and 68. A new client may not yet have its intended address, so DHCP interacts with broadcast behavior and relay design. A remote DHCP server can still serve a client through a relay.
APIPA tells you the affected client did not obtain expected IPv4 configuration. It does not prove the DHCP server itself is down.
Port 80 and port 443 represent different application expectations
HTTP commonly uses TCP 80. HTTPS commonly uses TCP 443 and adds TLS protection. A firewall rule allowing 80 does not automatically allow 443, and successful HTTP does not prove HTTPS works.
DNS succeeds, but TCP/443 fails
Do not keep troubleshooting DNS. The unresolved branch is now route/policy/listener/TLS/application. A packet capture, firewall log, or server listener check can provide much more information than another DNS query.
Secure administration is about more than memorizing 22 and 23
SSH commonly uses TCP 22 and provides encrypted remote administration. Telnet commonly uses TCP 23 and lacks the confidentiality expected for secure administration. The exam-relevant distinction is not only the number, but which protocol is appropriate for a secure management requirement.
SFTP is not FTP with encryption added
SFTP is a subsystem of SSH and commonly uses TCP 22. FTP commonly uses TCP 21 for its control channel and has separate data-channel behavior. FTPS is FTP protected with TLS and retains FTP's architectural behavior.
| Protocol | Architecture | Common port clue |
|---|---|---|
| FTP | FTP control + separate data behavior | TCP 21 control |
| FTPS | FTP protected with TLS | FTP-derived behavior |
| SFTP | SSH subsystem | TCP 22 |
Swipe horizontally to compare file-transfer protocols.
Control-channel success does not prove the data path
Calling “the network down” ignores a known-good checkpoint.
SMTP, IMAP, and POP3 solve different mail problems
SMTP handles mail transfer/submission contexts. IMAP provides mailbox access with server-side synchronization. POP3 provides mailbox retrieval with a simpler model. Secure variants and deployment-specific ports matter, but the durable skill is matching the protocol role to the requirement.
Ping does not use a TCP or UDP application port
Ping commonly uses ICMP. Therefore “open port for ping” is conceptually wrong in a TCP/UDP port sense, even though firewalls can certainly permit or block ICMP traffic.
ARP is local neighbor resolution, not an application port
ARP maps local IPv4 addresses to MAC addresses on the local Layer 2 network. It is not a TCP or UDP application. ARP evidence is useful when diagnosing local neighbor reachability, duplicate IPs, or unusual Layer 2 mappings.
TCP provides connection-oriented transport behavior
TCP adds sequencing, acknowledgments, retransmission, flow control, and congestion behavior. A successful TCP connection proves more than simple IP reachability because it shows the path and service were able to complete transport establishment.
UDP is connectionless—but “always faster” is too simplistic
UDP does not provide TCP-style session establishment, retransmission, sequencing, or flow control. Applications that use UDP may implement their own recovery or may accept loss for timeliness. Protocol choice depends on application requirements, not a universal speed rule.
Turn service knowledge into narrow policy
Port memorization becomes operationally useful when it lets you write least-privilege rules and verify both allowed and denied flows.
Refusal and timeout are different clues
A TCP refusal often means the path reached a host or device capable of rejecting the connection, commonly because no process is listening or policy actively rejected it. A timeout means only that no timely response returned. Those symptoms should not be treated as equivalent.
Refused
Active rejection or closed listener becomes stronger.
Timeout
Filtering, loss, route, listener, or return-path issues remain possible.
Connected
Transport path works; application behavior may still fail.
Lower-layer success does not guarantee higher-layer success
DNS returns the right address; HTTPS still fails
DNS is substantially proven for that query. The next evidence should target TCP/443, firewall policy, route, listener, TLS, or application state—not another DNS configuration change.
SFTP is required, but TCP/21 is opened
This is an architectural mismatch. SFTP uses SSH semantics and commonly TCP 22. Opening FTP control port 21 does not satisfy an SFTP requirement.
Guest clients need DNS and HTTPS but no management access
Verification should include successful DNS and HTTPS plus a negative control showing management access remains blocked.
FTP login works but directory listing fails
The control path is known-good. Investigate data-channel behavior, NAT/firewall handling, and server configuration instead of declaring the entire path unavailable.
What a protocol test proves—and what it does not
| Successful test | What it proves | What remains unresolved |
|---|---|---|
| DNS query | Resolver answered that query | Application service |
| Ping | Useful ICMP/IP reachability | TCP/UDP service |
| TCP connect | Transport establishment to that port | Application correctness |
| SSH login | SSH service and authentication path work | Other management services |
| FTP login | Control channel works | Data channel |
Swipe horizontally to see the evidence matrix.
For every protocol, record six things
Purpose
What job does the protocol perform?
Transport
TCP, UDP, ICMP, or neither?
Common port
Where applicable.
Security
Encrypted? Legacy? Management-sensitive?
Failure clue
What symptom would fit?
Best artifact
Which test confirms the dependency?
Strong answers connect the service to the evidence
Instead of writing “HTTPS is 443,” write: “HTTPS commonly uses TCP 443. DNS already returns the expected server IP, so the next test should target TCP/443 or the server listener. A failed DNS hypothesis is weaker because name resolution already succeeded.”
24 Ports & Protocols digital flashcards
Practice DNS, DHCP, HTTP/HTTPS, SSH, Telnet, FTP/FTPS/SFTP, mail roles, ICMP, ARP, TCP vs. UDP, firewall policy, refusal vs. timeout, and evidence limits.