TCP and UDP for CompTIA A+ Core 1: Ports, Protocols, and Practical Troubleshooting

Why TCP and UDP Matter for the A+ Exam

If you’re studying for CompTIA A+ Core 1, TCP and UDP are not just terms to memorize. They’re basically the transport methods behind a lot of the services we troubleshoot every day — web access, email, file sharing, DNS, DHCP, remote access, and monitoring. In other words, if you’ve ever stared at a ticket that says “the app is broken,” there’s a pretty good chance TCP or UDP is part of the story. On the exam, you are expected to recognize what these protocols do, which ports are associated with common services, and how symptoms point you toward the right protocol, port, or service.

The key idea is simple: TCP and UDP are transport-layer protocols. In the OSI model, they operate at Layer 4. In the TCP/IP model, they are also in the transport layer. Application protocols such as HTTP, HTTPS, DNS, SMTP, SMB, and DHCP use TCP or UDP to move data between applications on different hosts.

One of the biggest beginner mistakes is mixing up three related but different ideas:

Protocol = the communication rules
Port = the transport-layer endpoint number associated with an application/service on a host
Service = the application function or server process using that port

Remember this: TCP and UDP describe how data moves. Ports tell the system where that transport traffic should be delivered. Services are the applications using those ports.

Where TCP and UDP Fit in Networking

Think of the stack in layers. The application layer defines what the service is, the transport layer carries the conversation, and IP handles the addressing and routing across networks. That’s the simple version, and honestly, that’s usually enough for A+ questions. Ethernet or Wi-Fi handles local delivery on the network segment.

That means a browser opening a secure website is not “using TCP instead of HTTPS.” It is using HTTPS at the application layer, which is commonly carried over TCP 443. Likewise, DNS is an application-layer protocol that commonly uses UDP 53, but sometimes TCP 53.

Basic stack view:

Application Layer: HTTP, HTTPS, DNS, SMTP, DHCP, SMB, RDP
Transport Layer: TCP or UDP
Network/Internet Layer: IP
Link Layer: Ethernet, Wi-Fi

This layer awareness matters in troubleshooting. A user may say, “The internet is down,” when the real issue is DNS. Or they may say, “The server is online,” because ping replies, even though TCP 445 for SMB is blocked. Good technicians isolate the layer instead of guessing.

Ports, Port Ranges, and Session Flow

Ports let one host run many networked applications at the same time. This is part of the transport layer’s job of multiplexing and demultiplexing: combining many application conversations on one host, then delivering each one to the correct application.

Port ranges are commonly grouped like this:

Well-known ports: 0-1023
Registered ports: 1024-49151
Dynamic/ephemeral ports: 49152-65535

In practice, client devices usually use a temporary ephemeral source port, while the server listens on a known destination port. Exact ephemeral ranges can vary by operating system, but the idea is the same: the client gets a high-numbered temporary port for the session.

Example flow:

192.168.1.50:51544 → 203.0.113.10:443 TCP

That means the client at 192.168.1.50 used ephemeral source port 51544 to connect to a server listening on TCP 443.

This also explains how NAT/PAT works in many real networks. A router can translate a whole pile of internal client sessions because each one is tracked by source and destination IP, source and destination port, and protocol. Return traffic is matched back to the correct client session using that mapping.

Important distinction: a service may be a listening server process on a well-known port, but clients also use ports dynamically during outbound connections. So not every port you see in a connection list represents a server “listening service.”

What Is TCP?

TCP stands for Transmission Control Protocol. It is connection-oriented and designed to provide reliable, ordered delivery using acknowledgments and retransmission.

Before data is sent, TCP typically establishes a session with the three-way handshake:

1. SYN – the client requests a connection
2. SYN-ACK – the server acknowledges and agrees
3. ACK – the client confirms

After that, data can be exchanged. TCP tracks sequence numbers so data can be reassembled in order. It uses acknowledgments so the sender knows what arrived. If data is lost, TCP can retransmit it. It also uses flow control and windowing to avoid overwhelming the receiver.

At a high level, TCP also manages connection teardown when the session ends. You do not need deep packet analysis for A+, but it helps to know TCP manages both setup and termination.

Why does this matter in support? Because packet loss, congestion, or filtering can produce user symptoms like slow file copies, stalled web sessions, or applications that partially load and then hang. TCP’s reliability features help recover from loss, but retransmissions also increase delay.

Typical TCP uses include web browsing, email, file transfer, file sharing, SSH, and most remote administration tasks.

What Is UDP?

UDP stands for User Datagram Protocol. It is connectionless. It does not establish a session with a handshake and does not provide built-in delivery guarantees, ordering, or transport-layer retransmission.

That lower transport overhead can support lower-latency application designs, but it does not mean UDP is automatically faster in every situation. Actual performance depends on the application, the network path, congestion, and how the application handles loss.

Why use UDP at all? Because some traffic values timeliness more than perfect recovery. Voice, streaming, gaming, SNMP, DHCP, and many DNS queries fit that model. A late voice packet may be less useful than a dropped one. Some applications also add their own recovery logic at the application layer instead of relying on TCP.

UDP troubleshooting can be trickier because there is no connection handshake to confirm. Failures may look “silent”: the client sends traffic, but no response comes back, and there is no built-in session state like TCP has.

Real-world note: modern web traffic may also use QUIC/HTTP/3 over UDP. For A+ exam purposes, you should still memorize HTTPS as TCP 443, but it is useful to know that some modern web implementations also use UDP in practice.

TCP vs UDP at a Glance

Technician takeaway: TCP and UDP are not competitors so much as different tools. The application chooses the one that best fits its needs.

Common Ports, Protocols, and Their Purposes

For the A+ exam, ports are high-yield memorization. The best way to learn them is by grouping them by function and connecting each one to a likely support symptom.

Important real-world clarifications:

DNS 53: commonly uses UDP for standard queries and TCP for zone transfers, truncated responses, and some fallback or larger exchanges.
SMTP 25: important for A+ memorization, but modern client submission often uses 587 and sometimes 465.
RDP 3389: for A+ memorization, know it as TCP 3389; in modern environments, RDP may also use UDP 3389 for performance improvements.
LDAP 389 vs LDAPS 636: standard directory access commonly uses 389, while secure directory access commonly uses 636.
SMB 445 vs NetBIOS 137/138/139: modern SMB uses TCP 445 directly; 137/138/139 are legacy NetBIOS over TCP/IP functions.

Special Cases You Should Actually Understand

DHCP: uses UDP 67 on the server side and UDP 68 on the client side. Initial lease acquisition is broadcast-based, so DHCP may fail across VLANs or subnets unless a DHCP relay/IP helper is configured.

DNS: if a user can reach a site by IP but not by name, suspect DNS first. If standard queries work but zone transfers fail, that points toward TCP 53 issues.

FTP: uses TCP 21 for control. In active FTP, the server traditionally initiates the data connection from TCP 20. In passive FTP, the client initiates both connections and the server uses a negotiated high port for data. Passive mode usually works better through firewalls.

SNMP: UDP 161 is typically for polling/queries, and UDP 162 is for traps. Also remember that SNMPv1/v2c rely on community strings and are weaker, while SNMPv3 adds authentication and encryption.

Secure vs Legacy Protocols

Exam questions often test whether you can identify the secure option. In support work, this matters because open ports are not just functionality; they are also attack surface. Expose only the services you need, and prefer secure protocols whenever possible.

Think like a technician: if a management protocol is internet-exposed, ask whether it should be behind a VPN, restricted by firewall rules, or disabled entirely.

Troubleshooting by Symptom

Most exam questions start with a symptom, not a protocol name. Here is the practical mapping:

Can ping by IP, but cannot browse by name: likely DNS, port 53, usually UDP.
Client gets 169.254.x.x APIPA: likely DHCP failure, UDP 67/68, scope issue, relay issue, or service problem.
Host responds to ping, but RDP fails: check TCP 3389, firewall rules, service state, NLA settings, VPN or Remote Desktop gateway dependencies, and whether RDP is enabled.
Host is online, but file share is unavailable: check TCP 445, Server service, permissions, authentication, name resolution, and firewall or access control path.
Email sends but does not receive: SMTP may work while POP3 or IMAP is failing.
Monitoring stops but device is reachable: suspect UDP 161/162, community string or SNMP configuration, or filtering.

Also remember the inverse of a common beginner assumption: a failed ping does not always mean the host is down. ICMP may be filtered even when the host and application are reachable.

A Repeatable Troubleshooting Workflow

When you are under pressure, follow a process:

1. Verify local IP settings with ipconfig /all or equivalent
2. Confirm gateway and local network reachability
3. Test name resolution with nslookup or dig
4. Test remote reachability with ping or tracert/traceroute
5. Test the specific service port with Test-NetConnection, nc, or application-aware tools
6. Verify the service is actually listening with netstat or ss
7. Check host firewall rules
8. Check network firewall, access control lists, and NAT/PAT behavior
9. Confirm the application itself is healthy and the user is authorized

This order helps you separate host reachable, port reachable, service listening, and application/authentication working. Those are not the same thing.

Useful Commands and What They Really Tell You

ping tests ICMP reachability. Helpful, but it does not prove a TCP or UDP service works. A failed ping may simply mean ICMP is blocked.

nslookup or dig tests DNS resolution. You can also query a specific DNS server to compare results.

Example:

nslookup example-domain using a specific DNS server address

Test-NetConnection host -Port port is a strong Windows choice for testing TCP port reachability.

Example:

Test-NetConnection 192.168.1.20 -Port 445

If TcpTestSucceeded : False, the host may be reachable while the service port is blocked or not listening.

netstat -an on Windows or ss -lntup on Linux helps confirm whether a local service is listening.

Example listening output:

TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING

If a local service is listening but remote tests fail, suspect a firewall, access control list, or NAT issue along the path.

telnet host port can test TCP connectivity, but it is legacy and often not installed by default. On modern Windows systems, Test-NetConnection is usually preferred. On Linux or similar systems, nc -vz host port is a common alternative.

Command Lab: Local vs Remote Testing

Scenario: A server should allow RDP.

Local check on server:
netstat -an shows TCP 0.0.0.0:3389 LISTENING

Remote check from client:
Test-NetConnection server01 -Port 3389 returns TcpTestSucceeded : False

Conclusion: the RDP service is listening locally, but the path is blocked or filtered. Check Windows Firewall, network firewall, access control lists, VPN policy, or NAT and port forwarding if remote access crosses boundaries.

Exam Traps and High-Yield Reminders

Common traps:

HTTP is not TCP; HTTP uses TCP.
DNS is not UDP-only; it commonly uses UDP and also TCP.
DHCP uses UDP, not TCP.
Ports identify transport endpoints on a host, not the host itself.
Ping success does not prove an application works.
Ping failure does not always prove a host is down.
SMB 445 is different from legacy NetBIOS 139.
RDP is memorized as TCP 3389 for A+, even though real environments may also use UDP 3389.

Must memorize for 220-1101:
20/21 FTP
22 SSH
23 Telnet
25 SMTP
53 DNS
67/68 DHCP
80 HTTP
110 POP3
123 NTP
137/138/139 NetBIOS
143 IMAP
161/162 SNMP
389 LDAP
427 SLP
443 HTTPS
445 SMB
3389 RDP

Quick memory groups:
Web: 80, 443
Remote access: 22, 23, 3389
Mail: 25, 110, 143
Addressing and naming: 53, 67/68
Windows sharing: 445, plus legacy 137/138/139

Mini Practice Questions

1. A user can open a website by IP address but not by hostname. What protocol and port should you check first?
Answer: DNS, port 53.

2. A PC has an address of 169.254.14.22. What service is the first suspect?
Answer: DHCP, using UDP 67/68.

3. A server responds to ping, but a shared folder cannot be mapped. Which port is most likely relevant?
Answer: SMB on TCP 445.

4. Which secure protocol replaces Telnet?
Answer: SSH on TCP 22.

5. Why might DNS use TCP instead of UDP?
Answer: Zone transfers, truncated responses, or some larger fallback exchanges.

6. For A+ memorization, what port is associated with RDP?
Answer: TCP 3389.

Final Review

Here is the clean summary: TCP and UDP are Layer 4 transport protocols. TCP is connection-oriented and provides reliable, ordered delivery with acknowledgments and retransmission.smission. UDP is connectionless and uses lower overhead, making it useful for time-sensitive or lightweight traffic that can tolerate loss or handle recovery another way.

Ports identify the transport endpoints associated with applications and services. Servers usually listen on well-known ports, while clients usually use ephemeral source ports. Understanding that relationship is what makes protocol troubleshooting make sense.

For the A+ exam, lock in the common ports, know whether they use TCP or UDP, and connect each one to its purpose. Then remember the practical logic: if IP works but names fail, think DNS. If you get APIPA, think DHCP. If ping works but the app fails, test the service port. If the local service is listening but remote access fails, think firewall, access control list, or NAT path.

That is exactly the kind of reasoning the exam is trying to measure, and it is also the kind of reasoning that makes you useful on a real support desk.