ExamFinch.com My Study

Study guide

Common Ports & Protocols

Practice this exam

CompTIA A+ 220-1201 & 220-1202

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

About the CompTIA A+ Certification Exam Domains & Study Strategy

2 Core 1 Domain 1: Mobile Devices (13%)

Laptop Hardware & Components Laptop Features & Display Types Mobile Device Connectivity & Accessories Mobile Operating System Features Mobile Device Synchronization & Data Transfer

3 Core 1 Domain 2: Networking (23%)

TCP/IP Fundamentals & the OSI Model Common Ports & Protocols Wireless Networking Standards Network Hardware & Devices Network Configuration & Internet Connections Network Types & Topologies

4 Core 1 Domain 3: Hardware (25%)

Cables & Connectors RAM Types & Storage Devices Motherboards, CPUs & Power Supplies Printers & Multifunction Devices Peripheral Devices & Expansion Cards Network Cable Tools & Testing

5 Core 1 Domain 4: Virtualization & Cloud Computing (11%)

Virtualization Concepts Cloud Computing Models & Services Client-Side Virtualization in Practice

6 Core 1 Domain 5: Hardware & Network Troubleshooting (28%)

CompTIA Troubleshooting Methodology Hardware Troubleshooting Network Troubleshooting Printer Troubleshooting Display & Mobile Device Troubleshooting

7 Core 2 Domain 1: Operating Systems (28%)

Windows Editions & Features Windows Administrative Tools & Utilities Windows Command Line & PowerShell macOS & Linux Basics Windows Networking & File Sharing Windows Installation & Upgrade Methods

8 Core 2 Domain 2: Security (28%)

Physical & Logical Security Measures Malware Types & Threat Mitigation Wireless & Network Security Encryption & Data Protection

9 Core 2 Domain 3: Software Troubleshooting (23%)

Windows OS Troubleshooting Mobile OS & Application Troubleshooting Browser & Application Troubleshooting

10 Core 2 Domain 4: Operational Procedures (21%)

Documentation & Change Management Backup & Recovery Methods Safety & Environmental Procedures Scripting & Remote Access Technologies Privacy, Licensing & Organizational Policies

Common Ports & Protocols

Key Takeaways Explain This Topic AI

Port numbers run 0-65,535, split into well-known (0-1023), registered (1024-49151), and dynamic/ephemeral (49152-65535) ranges.

Memorize the core ports: FTP 20/21, SSH/SFTP 22, Telnet 23, SMTP 25, DNS 53, DHCP 67/68, HTTP 80, POP3 110, IMAP 143, HTTPS 443, SMB 445, RDP 3389.

Secure variants use distinct ports: HTTPS 443, IMAPS 993, POP3S 995, LDAPS 636, and SMTP submission over STARTTLS 587.

DNS resolves names to IP addresses; a DNS failure looks like a total internet outage even when Layer 3 connectivity is fine.

DHCP hands out IP, mask, gateway, and DNS via the four-step DORA process (Discover, Offer, Request, Acknowledge).

Last updated: June 2026

Port Number Ranges

A port is a 16-bit number that identifies a service or a client-side conversation so multiple connections can share one IP address.

  • Range Category Description
  • 0-1,023 Well-known Reserved for standard servers (HTTP, DNS, SSH)
  • 1,024-49,151 Registered Vendor/application services (RDP 3389, SQL 1433)
  • 49,152-65,535 Dynamic/ephemeral Temporary source ports for client connections
  • Ports You Must Memorize
  • Web & file transfer
  • Port Protocol Notes TCP/UDP
  • 20 FTP data File transfer payload channel TCP
  • 21 FTP control Commands and authentication TCP
  • 22 SSH / SFTP / SCP Encrypted shell and file copy TCP
  • 23 Telnet Plaintext remote terminal (insecure) TCP
  • 80 HTTP Unencrypted web TCP
  • 443 HTTPS Web over TLS TCP
  • Email
  • Port Protocol Notes TCP/UDP
  • 25 SMTP Mail relay between servers TCP
  • 110 POP3 Download mail (no sync) TCP
  • 143 IMAP Server-side mail sync TCP
  • 587 SMTP (STARTTLS) Modern authenticated mail submission TCP
  • 993 IMAPS IMAP over TLS TCP
  • 995 POP3S POP3 over TLS TCP
  • Network services & remote access
  • Port Protocol Notes TCP/UDP
  • 53 DNS Name resolution TCP & UDP
  • 67/68 DHCP Server 67 / client 68 UDP
  • 137-139 NetBIOS Legacy Windows name/session services TCP/UDP
  • 161/162 SNMP / SNMP trap Device monitoring UDP
  • 389/636 LDAP / LDAPS Directory lookups (636 secure) TCP
  • 445 SMB/CIFS Windows file sharing TCP
  • 3389 RDP Windows Remote Desktop TCP

Exam trap: match plaintext protocols to their encrypted upgrades. Telnet (23) -> SSH (22); HTTP (80) -> HTTPS (443); FTP (21) -> SFTP (22) or FTPS (990); LDAP (389) -> LDAPS (636).

DNS - Port 53

DNS (Domain Name System) maps human names to IP addresses. It usually uses UDP for fast lookups and TCP for large responses or zone transfers.

  • Record Purpose Example
  • A Hostname -> IPv4 example.com -> 93.184.216.34

AAAA Hostname -> IPv6 example.com -> 2606:2800:220:1::...

  • MX Mail exchanger example.com -> mail.example.com
  • CNAME Alias to another name www -> example.com
  • TXT Text/verification (SPF, DKIM) "v=spf1 ..."
  • PTR Reverse lookup (IP -> name) 34.216.184.93.in-addr.arpa

Diagnostic move: if ping 8.8.8.8 succeeds but ping google.com fails, connectivity is fine and DNS is broken. Use nslookup to confirm and ipconfig /flushdns to clear stale records.

DHCP - Ports 67/68

DHCP (Dynamic Host Configuration Protocol) automates client configuration via the DORA exchange:

Discover - client broadcasts a request for an address.

Offer - a DHCP server proposes an available lease.

Request - client formally requests the offered address.

Acknowledge - server confirms and records the lease.

A DHCP scope delivers the IP address, subnet mask, default gateway, DNS servers, and a lease time . When DHCP fails, the client falls back to a 169.254.x.x APIPA address - a classic exam tell for "DHCP server is down."

FTP - Ports 20/21

FTP separates control from data. Port 21 carries commands and authentication; port 20 carries the file data in active mode.

Active mode: the server opens the data connection back to the client - often blocked by client-side firewalls.

Passive mode: the client opens both connections - firewall-friendly and the modern default.

Security note: plain FTP and Telnet send credentials in cleartext. Prefer SFTP (22) or FTPS (990) and SSH (22) instead.

TCP vs. UDP at the Port Level

A single port number can mean different services depending on whether it rides TCP or UDP, so the exam often pairs a port with a transport protocol. DNS is the classic example: it uses UDP 53 for ordinary lookups because a single small query and answer fit in one datagram with no handshake overhead, but it falls back to TCP 53 for responses larger than 512 bytes and for zone transfers between name servers. DHCP runs entirely over UDP (server 67, client 68) because the client has no address yet and must broadcast, which connectionless UDP supports and connection-oriented TCP cannot.

Most other services - HTTP, HTTPS, SSH, SMTP, RDP, and SMB - are TCP because they need reliable, ordered delivery.

Why Secure Variants Exist

Early internet protocols carried everything, including passwords, in plaintext. Anyone capturing traffic with a tool such as a packet sniffer could read Telnet sessions, FTP credentials, or POP3 mailboxes. The modern fix is a TLS-protected variant on its own port: HTTP became HTTPS on 443, IMAP became IMAPS on 993, POP3 became POP3S on 995, and LDAP became LDAPS on 636. Some protocols instead upgrade the existing port in place using STARTTLS , which is why authenticated mail submission uses port 587 - the connection opens in the clear, then negotiates encryption before any credentials are sent.

On the exam, when a question asks how to secure an existing plaintext service, the answer is almost always "switch to the encrypted variant on its dedicated port" rather than "hide the service" or "change the password."

A Port-Troubleshooting Scenario

A user can reach an internal web server by IP on port 80 but a new HTTPS site times out. Because plain HTTP works, Layer 3 connectivity and the route are fine; the failure is specific to port 443. The most common causes are a firewall rule blocking 443 inbound, a missing or expired TLS certificate on the server, or the service simply not listening on 443. Running netstat on the server reveals whether anything is bound to port 443, and checking the firewall rule set confirms whether 443 is permitted. This isolates the problem to the transport/application layers rather than the physical link.