Port numbers matter because they identify the service boundary you should inspect next
Memorizing a port number is only the first step. The real networking skill is translating that number into an operational question: which process should be listening, which firewall tuple should match, which transport protocol is involved, and which successful checkpoint can already be preserved.
Group common ports by function instead of memorizing a random list
Web
TCP 80 HTTPTCP 443 HTTPS
Name & address services
UDP/TCP 53 DNSUDP 67/68 DHCPv4
Management
TCP 22 SSHTCP 23 Telnet
Mail transfer/submission
TCP 25 SMTPTCP 587 Submission
Mailbox access
110 POP3995 POP3S143 IMAP993 IMAPS
File transfer
TCP 21 FTP controlTCP 20 active FTP dataTCP 22 SFTP
TCP 80 and TCP 443 often appear in the same user workflow but represent different checkpoints
Plain HTTP commonly uses TCP 80. HTTPS commonly uses TCP 443. A browser may successfully reach port 80 only to receive a redirect to HTTPS, where the final transaction then fails. That means “port 80 works” is not enough evidence to declare the website healthy.
The failure boundary is now TCP/443, TLS, or the application—not the initial HTTP redirect.
Do not memorize DNS as UDP-only
Many ordinary DNS queries use UDP 53 because it is efficient. TCP 53 is also part of normal DNS behavior, including situations involving truncated or larger responses and other DNS operations.
UDP 67 and UDP 68 make more sense when you attach them to server and client roles
DHCPv4 commonly uses UDP 67 on the server and UDP 68 on the client. Early DHCP exchanges can occur before the client has a normal IPv4 address, which is why broadcasts, VLAN placement, relay configuration, and scope state matter.
A later successful ping to the DHCP server does not prove this earlier client/server exchange was available when the lease was needed.
TCP 22 and TCP 23 represent very different management expectations
SSH commonly uses TCP 22 and provides encrypted remote management. Telnet traditionally uses TCP 23 and lacks equivalent encrypted transport. In a secure management design, remembering the number should also remind you that policy should normally restrict management access to trusted sources.
Sending, submission, retrieval, and synchronization use different service roles
| Role | Common port | Purpose |
|---|---|---|
| SMTP server transfer | TCP 25 | Mail server to mail server |
| Message submission | TCP 587 | Client submits outbound mail |
| POP3 | TCP 110 | Traditional mailbox retrieval |
| POP3S | TCP 995 | POP3 over TLS |
| IMAP | TCP 143 | Mailbox access/synchronization |
| IMAPS | TCP 993 | IMAP over TLS |
Swipe horizontally to see the email-port table.
Similar names can hide completely different protocol designs
Classic FTP commonly uses TCP 21 for control and separate data connections; TCP 20 is traditionally associated with active-mode server data behavior. Passive FTP negotiates data ports differently. SFTP is a separate SSH-based file-transfer protocol, commonly using TCP 22. FTPS is FTP secured with TLS and remains architecturally tied to FTP-style control/data behavior.
A correct port tells you what to inspect, not that the service works
The same logic works in reverse. A listener can exist while routing or firewall policy prevents the client from reaching it.
Least-privilege policy should match source, destination, protocol, and service port
Knowing the port lets you write or interpret a narrow rule instead of a broad “allow everything” policy.
Verification should include both an allowed case and a denied case.
Server socket state is the strongest check when the path reaches the host but the service still fails
If a packet reaches the server and there is no matching listener, investigate the service process, bind address, application configuration, or host firewall. If a listener is present but the client times out, inspect network/host policy and return-path evidence.
TCP and UDP behavior change what failure evidence looks like
TCP establishes connection state and may produce a refusal when no application is accepting the port. UDP is connectionless, so absence of a reply does not look the same. Port memorization is more useful when paired with the transport protocol.
| Observation | Possible meaning |
|---|---|
| TCP refusal | Destination/path actively rejected the connection or nothing is listening |
| TCP timeout | Filtering, path failure, silent drop, or service issue |
| UDP no response | Could be normal silence, filtering, path issue, or application behavior |
Swipe horizontally to see the transport evidence table.
Practice port recall inside real troubleshooting decisions
Answer each question before reading the explanation. The goal is to connect the port to the next listener, firewall, path, or service check.
HTTPS
Which port is commonly associated with HTTPS?
A. TCP 80B. TCP 443C. UDP 53D. TCP 22DNS
Which statement about DNS is strongest?
A. DNS is UDP 53 onlyB. DNS uses TCP 53 onlyC. DNS commonly uses UDP 53 and also TCP 53D. DNS uses TCP 25DHCPv4
Which ports are used by DHCPv4?
A. UDP 67 server / UDP 68 clientB. TCP 67 / TCP 68C. UDP 53 / TCP 53D. TCP 20 / TCP 21SSH
Which port is commonly associated with SSH?
A. TCP 21B. TCP 22C. TCP 23D. TCP 25Telnet
Which port is traditionally associated with Telnet?
A. TCP 23B. TCP 22C. TCP 80D. UDP 67SMTP transfer
Which port is commonly associated with SMTP server-to-server transfer?
A. TCP 110B. TCP 143C. TCP 25D. TCP 993Mail submission
Which port is commonly associated with authenticated message submission?
A. TCP 587B. TCP 25 onlyC. TCP 110D. UDP 53POP3/IMAP
Which pair is correct for traditional unencrypted mailbox protocols?
A. POP3 143 / IMAP 110B. POP3 110 / IMAP 143C. POP3 25 / IMAP 587D. POP3 995 / IMAP 993FTP
Which port is commonly used for classic FTP control?
A. TCP 20B. TCP 21C. TCP 22D. TCP 23SFTP
Which statement about SFTP is correct?
A. It is FTP on TCP 21 with TLSB. It commonly runs over SSH on TCP 22C. It uses UDP 69D. It is the same protocol as FTPSPing works, HTTPS fails
A server answers ping, but HTTPS times out. What is the best next focus?
A. TCP 443 listener/firewall/path evidenceB. Replace DNS immediatelyC. Change DHCP scopeD. Assume the cable is badDNS troubleshooting
A client can reach remote IPs but DNS queries time out. Which service tuple matters most?
A. UDP/TCP 53B. TCP 443 onlyC. TCP 22D. UDP 67/68 onlyDHCP APIPA
A new client has APIPA while peers work. Which service ports belong to the DHCPv4 exchange?
A. UDP 67/68B. TCP 20/21C. TCP 25/587D. TCP 110/143Least privilege
Students need HTTPS to an app server but no administration. Which rule is most appropriate?
A. Allow all TCPB. Allow TCP 443 to the app serverC. Allow TCP 22 to all switchesD. Allow all UDPListener evidence
Firewall logs allow TCP 443 and routing is correct, but the server has no TCP/443 listener. What is strongest?
A. Application/listener failureB. DNS failureC. Wrong VLAN necessarilyD. ISP outageMail secure variants
Which secure mailbox ports are commonly paired correctly?
A. POP3S 995 / IMAPS 993B. POP3S 993 / IMAPS 995C. POP3S 110 / IMAPS 143D. POP3S 25 / IMAPS 587HTTP redirect
TCP 80 succeeds but the site redirects to HTTPS and the browser still fails. What remains important?
A. TCP 443 path/serviceB. Nothing; port 80 proved the site worksC. DHCP onlyD. ARP onlyFTP vs SFTP
Why is SFTP a common distractor in FTP questions?
A. Because SFTP uses SSH/TCP 22 rather than FTP control TCP 21B. Because both always use UDPC. Because SFTP is DNSD. Because FTP never uses TCPDNS TCP
A DNS response is truncated over UDP and the client retries another transport. Which port remains relevant?
A. TCP 53B. TCP 80C. TCP 23D. UDP 68Operational port reasoning
What is the real value of memorizing common ports?
A. Knowing which listener, firewall tuple, log, or service dependency to inspect nextB. Replacing routing knowledgeC. Proving an application works from the port number aloneD. Avoiding all packet/path testingSeparate service identification from path and application proof
| Evidence | What it proves | What remains unproven |
|---|---|---|
| TCP 443 is the expected port | HTTPS service tuple | Reachability/listener/TLS health |
| Firewall allows TCP 22 | Policy permits that flow | SSH daemon is listening |
| DNS query succeeds on UDP 53 | That query worked | TCP 53 behavior |
| Server listens on TCP 25 | SMTP service is locally accepting | Remote routing/policy |
| Ping works | ICMP/IP path | Any specific application port |
Swipe horizontally to see the evidence matrix.
Match firewall logs and listeners to the actual service role
Map A to HTTPS, B to SSH, C to DNS, and D to DHCPv4. Then inspect listener/service state. A correct firewall action does not prove the server process exists, and a listener does not prove the network path or policy is correct.
Study in both directions: service-to-port and port-to-service
Practice “HTTPS → TCP 443” and also “TCP 443 → HTTPS.” Then add one operational sentence: “If TCP 443 fails, inspect the web listener, firewall tuple, route, TLS, and application health.” That extra step turns memorization into troubleshooting knowledge.
24 Network Ports digital flashcards
Practice HTTP, HTTPS, DNS, DHCP, SSH, Telnet, SMTP, submission, POP3, IMAP, FTP, SFTP, transport behavior, firewall policy, and evidence boundaries.