Ports and protocols for CompTIA Network+ (N10-009)

What does Network+ test about ports and protocols?

Objective 1.4 asks you to explain common ports, protocols, services, and traffic types. It lives in Domain 1.0, Networking Concepts, which is 23 percent of the N10-009 exam, so this is not a corner you can skip. You can confirm the current weights on CompTIA's Network+ page.

That objective is recall dressed up as scenarios. A question might describe a technician who needs to manage a switch over an encrypted remote session and ask which port to allow through the firewall. The answer is 22, but only if you know SSH is the encrypted option and that it uses port 22. You are never tested on numbers for their own sake. Every port on the list maps to a service you will touch on a help desk or a network team, from resolving a hostname to pushing a firmware image to a router. So learn the number and what it does together, because the exam and the job both ask you to reason, not recite.

What is a port, and why does it need a number?

A port is a numbered doorway on a device that lets one machine run many network services at once. The protocol is the language spoken through that doorway, and the port number is how a packet finds the right service after the IP address finds the right host. A single server can answer web, mail, and remote-login requests at the same time because each one lands on a different port.

Ports run from 0 to 65535, and CompTIA cares most about the well-known range, 0 to 1023, where the classic services live. That is why almost every number on your study list sits under 1024. The registered range, 1024 to 49151, holds a few you still need, like SQL Server on 1433 and RDP on 3389. Above that is the dynamic or ephemeral range, which clients borrow briefly for the return half of a conversation. The practical takeaway: a low, memorable number is almost always a standard server service, and those are exactly the ones the exam lists.

One more habit pays off here. When a port number on a question is large and unfamiliar, it is often an ephemeral client port or a distractor, not the server service the scenario is really asking about. The service you are being tested on almost always answers on the low, fixed number, while the client picks a throwaway high port for its side of the exchange. Keep your attention on the server port and the noise falls away.

Group the ports by the job they do

Do not learn the ports in numeric order. Group them by function: naming and addressing, web, email, remote access, file transfer, directory services, and network management. Related services cluster together, and clusters are far easier to hold in memory than a random string of numbers.

Naming and addressing is DNS on 53 and DHCP on 67 and 68. Web is HTTP on 80 and HTTPS on 443. Email splits into sending, which is SMTP on 25, and retrieving, which is POP3 on 110 and IMAP on 143. Remote access is SSH on 22, Telnet on 23, and RDP on 3389. File transfer is FTP on 20 and 21, with the lightweight TFTP on 69. Directory services is LDAP on 389. Network management collects SNMP on 161 and 162, Syslog on 514, and NTP on 123 for clock synchronization. When a scenario describes a task, name the job first and the port follows almost on its own. Working these in short, spaced reps beats one long cram, which is how Study mode is designed to run.

Which ports are UDP, and which are TCP?

Here is the shortcut that saves the most time on exam day: memorize the short list of UDP protocols, then assume everything else on the must-know list is TCP. The UDP set is small, so learning it as the exception is far faster than tagging every single port.

The core UDP protocols are DHCP on 67 and 68, TFTP on 69, NTP on 123, SNMP on 161 and 162, and Syslog on 514. These are the fire-and-forget services: address leases, quick file grabs, time updates, device polling, and log shipping. They do not need TCP's three-way handshake or its delivery guarantees, so they trade reliability for speed and low overhead. A couple of protocols mix transports. DNS on 53 runs over UDP for ordinary lookups and shifts to TCP for zone transfers and responses too big for a single UDP datagram. SIP is a mixed case too: 5060 carries signaling over UDP or TCP, while 5061 is SIP over TLS and rides TCP. Everything else you must know, including SSH, HTTP, HTTPS, SMTP, POP3, IMAP, LDAP, SMB, RDP, and SQL Server, runs over TCP. Learn the UDP handful cold and the rest defaults into place.

• DHCP: 67 and 68 (UDP)
• TFTP: 69 (UDP)
• NTP: 123 (UDP)
• SNMP: 161 and 162 (UDP)
• Syslog: 514 (UDP)
• DNS: 53 (UDP and TCP)
• SIP: 5060 (UDP or TCP) and 5061 (TCP, SIP over TLS)

How do insecure and secure protocols pair up?

Many protocols come in two versions, an older plaintext one and a newer encrypted one, and pairing them is half the battle. When a scenario mentions encryption, security, or anything exposed to the internet, reach for the secure member of the pair.

Telnet on 23 sends everything, passwords included, in the clear, and its replacement is SSH on 22, which encrypts the whole session. Plain FTP on 20 and 21 has the same exposure, and SFTP rides inside SSH on 22 to close it. HTTP on 80 became HTTPS on 443. For mail, IMAP on 143 gets its encrypted form on 993, POP3 on 110 moves to 995, and LDAP on 389 becomes LDAPS on 636.

Notice there is no clean arithmetic between the plain and secure numbers. 143 does not add a fixed amount to reach 993. What actually happened is that when these older protocols were wrapped in TLS, several were given brand new dedicated ports for the encrypted version, which is why 993, 995, and 636 exist as separate entries rather than reusing the original. SNMP is the exception that proves the rule: its security comes from version 3, not a new port, so it stays on 161 and 162. Once you can explain why the secure port differs instead of only memorizing it, firewall rules and troubleshooting with the right tools get much easier.

Firewall rules are where this knowledge earns its keep, because a rule is just a port, a direction, and an allow or deny. Say you stand up a public web server. You allow inbound TCP 443 so browsers on the internet can reach the encrypted site, and you leave inbound TCP 80 either redirected to 443 or closed so nothing rides in over plaintext. On that same edge you block inbound TCP 23, because Telnet would hand an attacker your admin credentials in the clear the moment someone sniffs the link. If you need remote management, you allow SSH on TCP 22 instead and scope it to trusted addresses. Direction matters as much as the number: inbound governs who can reach you, outbound governs what your host may start. That inbound and outbound split is also why an exam question about a blocked service usually points at one specific rule and one specific port, not the whole firewall.

Which ports are the highest yield?

If you are short on time, drill these first: SSH 22, DNS 53, HTTP 80 and HTTPS 443, SMTP 25, IMAP 143, DHCP 67 and 68, SMB 445, and RDP 3389. They show up most often in questions and in daily work, and they anchor the rest of the list once they become automatic.

Once those are reflexive, backfill the rest: 23 Telnet, 69 TFTP, 110 POP3, 123 NTP, 161 and 162 SNMP, 389 LDAP, 514 Syslog, 636 LDAPS, 995 POP3 over TLS, 1433 SQL Server, and 5060 and 5061 SIP. Flashcards help, but pairing each new port with a job and a transport helps more, because that is exactly the shape the questions take. Say the service, the number, and TCP or UDP in one breath, and you will recognize the answer even when the wording tries to trip you.

• 22 SSH, encrypted remote access (TCP)
• 53 DNS, name resolution (UDP and TCP)
• 80 HTTP and 443 HTTPS, web traffic (TCP)
• 25 SMTP, sending mail (TCP)
• 143 IMAP and 993 IMAP over TLS, retrieving mail (TCP)
• 67 and 68 DHCP, automatic addressing (UDP)
• 445 SMB, Windows file and printer sharing (TCP)
• 3389 RDP, remote desktop (TCP)

Turn the list into recall you can trust

Ports and protocols is one of the few Network+ topics you can genuinely finish. Group the ports by the job they do, memorize the short UDP list and let the rest default to TCP, and learn every insecure protocol right next to its secure twin. Do that and objective 1.4 stops being a wall of numbers and becomes a handful of patterns you can reason through. When you want to check whether it has stuck, run a timed round in Study mode or map out the full Network+ certification path before you book the exam. The numbers reward the student who reviews a little every day, so keep the reps small, keep them steady, and let the pattern do the heavy lifting.