Objective 2.1 is pure memorization wrapped around one important concept. Every network conversation happens over a port — a numbered logical endpoint that identifies which service or application a piece of traffic belongs to — using one of two transport-layer protocols, TCP or UDP, that determine how that traffic is actually delivered. Knowing which port goes with which service, and whether that service rides on TCP or UDP, is foundational vocabulary you'll lean on throughout the rest of the networking domain and well into security topics later in the exam.
There's no way around it: the port numbers themselves simply have to be memorized. But understanding why a protocol uses the port it uses, and why it picked TCP or UDP for its transport, turns rote memorization into something you can reason your way back to if your memory blanks during the exam.
What a Port Actually Is
An IP address gets traffic to the correct device. A port number gets that traffic to the correct service or application running on that device. A single server with one IP address can simultaneously run a web server (port 80/443), a mail server (port 25), and an SSH service (port 22) — the port number in each packet is what tells the operating system which of those services should receive the incoming data.
The following fourteen port assignments are the most heavily tested in the entire networking domain. Each entry below states the port number(s), the transport protocol it uses, and what the protocol/service actually does.
Transfers files between a client and a server. FTP actually uses two ports: port 21 is the control connection, used to send commands (login, navigate directories, initiate a transfer), while port 20 is used for the actual data transfer itself in active mode. FTP transmits credentials and data in plaintext, which is why FTPS (FTP over SSL/TLS) or SFTP (FTP over SSH, port 22) are preferred in security-conscious environments.
Provides an encrypted command-line connection to a remote device, allowing secure remote administration of servers, network equipment, and other systems. SSH replaced the older, insecure Telnet protocol for this purpose because all traffic — including login credentials — is encrypted. SSH is also commonly used as the secure transport underneath SFTP (secure file transfer) and SCP (secure copy).
An older protocol providing remote command-line access to a device, functionally similar to SSH but with one critical difference: Telnet transmits everything — including usernames and passwords — in plaintext, with no encryption whatsoever. Telnet is considered obsolete and insecure for any sensitive use today, retained mostly for legacy equipment or specific diagnostic purposes, and is almost universally replaced by SSH in modern practice.
Handles the sending and relaying of email between mail servers, and from a mail client to its outgoing mail server. SMTP is a "push" protocol — it's responsible for getting a message from sender to recipient's mail server, but it does not handle a client retrieving/reading mail from a mailbox (that's the job of POP3 or IMAP, covered below).
Resolves human-readable domain names to IP addresses (and vice versa), as covered in objective 2.3. DNS primarily uses UDP for standard, fast lookup queries, since speed matters more than guaranteed delivery for a quick name lookup (and a client will simply retry if no response comes back). DNS falls back to TCP for larger transfers, such as zone transfers between DNS servers or responses too large to fit in a single UDP packet.
Automatically assigns IP addressing information to clients via the DORA process (objective 2.6). Port 67 is used by the DHCP server, while port 68 is used by the DHCP client. DHCP uses UDP because, at the moment a client needs an address, it has no IP address yet at all — UDP's connectionless, broadcast-friendly nature fits this "I don't even have an address yet" bootstrapping scenario far better than TCP, which requires an established connection between two addressed endpoints first.
Transfers web page content — HTML, images, scripts — between a web server and a client's browser, as introduced in objective 2.3. HTTP traffic is sent in plaintext, meaning anyone able to intercept the traffic could read it, which is the core reason HTTPS (below) has become the standard for the modern web.
Allows a mail client to retrieve email from a mail server. POP3's defining behavior: by default, it downloads messages to the local client and then deletes them from the server, making mail essentially local to whichever single device retrieved it. This made sense in an era of one computer per person, but is a poor fit for anyone who checks email from multiple devices — which is exactly the gap IMAP fills.
Also retrieves email from a mail server, but unlike POP3, IMAP keeps mail synchronized on the server — messages, folders, and read/unread status remain on the server and are mirrored across every device that connects, rather than being downloaded and removed. This is why IMAP is the standard choice today: a user can check the same mailbox from a phone, laptop, and webmail interface and see a consistent state everywhere.
A legacy Windows networking protocol suite used for name resolution, datagram services, and session services on local networks — historically the basis for early Windows file/printer sharing before SMB took over those responsibilities more directly. Port 137 handles name service, port 138 handles datagram service, and port 139 handles session service. NetBIOS is largely legacy at this point but is still occasionally encountered, especially in older or mixed-OS environments.
Used to access and maintain distributed directory information services — most commonly associated with Microsoft Active Directory, where it's used to query and authenticate against information like user accounts, group memberships, and organizational structure. LDAP is central to how centralized authentication and authorization (AAA, objective 2.3) works in a Windows domain environment. A secure variant, LDAPS (LDAP over SSL/TLS), typically runs on port 636.
The encrypted version of HTTP, using TLS (Transport Layer Security) to encrypt traffic between the browser and the web server, protecting against eavesdropping and tampering. HTTPS is now the default expectation for virtually all websites, particularly anything involving logins, payments, or personal data — modern browsers actively flag plain HTTP sites as "Not Secure."
The protocol behind Windows file and printer sharing — when a user maps a network drive or accesses a shared folder on a Windows network (objective 2.3's fileshare role), SMB is doing the work underneath. CIFS is an older, specific dialect/implementation of SMB; the two terms are frequently used interchangeably, though "SMB" is the more current and accurate umbrella term for the modern protocol used by Windows file sharing today.
A Microsoft protocol that provides a full graphical remote desktop session to a Windows machine — unlike SSH or Telnet, which provide command-line-only access, RDP lets a remote user see and interact with the entire graphical desktop as if sitting in front of the machine. Widely used for remote IT support and remote work scenarios involving Windows systems.
Exam Angle
Expect direct recall questions ("Which port does RDP use?") as well as scenario questions that require you to work backward from a symptom to a port — "a user cannot remotely access their Windows desktop graphically" points to port 3389 (RDP) being blocked; "a user's email client can send mail but not receive new messages" points to a problem with port 110/143 (POP3/IMAP) rather than port 25 (SMTP, which only handles sending).
Every port above rides on top of one of two transport-layer protocols. Understanding the fundamental difference between them — and being able to explain why a given service chose one over the other — is the conceptual core of this entire objective.
TCP is a connection-oriented protocol that guarantees reliable, ordered delivery of data. Before any actual data is sent, TCP performs a three-way handshake to establish a connection between sender and receiver, and throughout the conversation it tracks every packet, requests retransmission of anything lost, and reassembles packets in the correct order even if they arrive out of sequence.
UDP is a connectionless protocol that sends data without first establishing a connection, without guaranteeing delivery, and without guaranteeing that packets arrive in the order they were sent. There's no handshake, no acknowledgment of receipt, and no automatic retransmission of lost data — UDP simply sends the data and moves on, trusting the application above it to handle any problems if it cares to.
This sounds like a disadvantage, and for many applications it would be — but for certain use cases, UDP's lack of overhead is exactly the point. UDP is dramatically faster and lighter-weight than TCP precisely because it skips all the reliability machinery, which makes it the right choice whenever speed matters more than guaranteed delivery, or whenever an application can tolerate occasional lost data better than it can tolerate delay.
| Characteristic | TCP | UDP |
|---|---|---|
| Connection | Connection-oriented (three-way handshake) | Connectionless (no handshake) |
| Reliability | Guaranteed delivery; lost packets retransmitted | No delivery guarantee; lost packets are simply lost |
| Ordering | Packets reassembled in correct order | No ordering guarantee |
| Speed/overhead | Slower; more overhead from reliability features | Faster; minimal overhead |
| Error checking | Extensive — acknowledgments, retransmission | Basic checksum only; no recovery mechanism |
| Best for | Web browsing, email, file transfer — anything where every byte must arrive correctly | Streaming media, VoIP, online gaming, DNS lookups — anything where speed matters more than perfection |
The Phone Call vs. Postcard Analogy
TCP is like a phone call: you establish the connection first ("hello, can you hear me?"), confirm receipt of what's said, and ask the other person to repeat anything you missed. UDP is like sending a postcard: you write it and send it, with no confirmation it ever arrives, no way to know if it arrived out of order relative to other postcards you sent, and no built-in way to resend it if it's lost. Both are valid depending on what you need — a contract needs the phone call's reliability; a quick "running 5 minutes late" doesn't need that overhead.
Exam Angle — Why DHCP and DNS Use UDP
Two of the most commonly misunderstood UDP choices: DHCP uses UDP because a device requesting an address has no IP address yet — TCP's connection-oriented model requires two addressed endpoints, which doesn't fit a "bootstrapping" broadcast scenario. DNS primarily uses UDP because a typical lookup is a single small request/response — establishing a full TCP connection for that would add unnecessary delay, and if a UDP query fails, the client simply re-sends it, which is cheap and fast for such a small exchange.
Final Exam Reminders
FTP = 20 (data) / 21 (control), TCP. SSH = 22, TCP, encrypted. Telnet = 23, TCP, unencrypted — never use for sensitive access.
SMTP (25) sends mail; POP3 (110) and IMAP (143) retrieve mail. POP3 deletes from server after download; IMAP keeps everything synced on the server.
DNS (53) = mostly UDP, TCP for large transfers. DHCP (67/68) = UDP, because the client has no IP address yet.
HTTP (80) = unencrypted. HTTPS (443) = encrypted via TLS. Always prefer 443 for anything sensitive.
SMB/CIFS (445) = Windows file/printer sharing. LDAP (389) = directory services, commonly Active Directory.
RDP (3389) = full graphical remote desktop, distinct from SSH/Telnet's command-line-only access.
TCP = connection-oriented, reliable, ordered, slower (three-way handshake). UDP = connectionless, no guarantees, faster, lower overhead.
TCP use cases = web, email, file transfer. UDP use cases = streaming, VoIP, gaming, DNS lookups, DHCP.