Lesson 2: TCP, UDP, and the Complete A+ Port Set

A port number is a clue.

It is not a diagnosis.

Seeing TCP port 443 associated with a host does not prove the web application is healthy. Seeing port 53 in a DNS conversation does not prove every DNS record is correct. A service can listen on the expected port and still reject the request, fail after connection, or return the wrong data.

Ports become useful when you connect them to transport behavior and the service the user is actually trying to use.

Transport sits between IP and the application

IP helps move packets between network endpoints.

Transport protocols help applications exchange data through logical endpoints.

Two transport protocols dominate A+ networking discussions:

• TCP;
• UDP.

They solve that job differently.

Visual reference

See the system before you troubleshoot it

reference sheetNetwork Devices, Media, and Tools

TCP establishes and tracks connection state

A simplified TCP connection begins with a three-way handshake:

client                         server
  | -------- SYN ------------> |
  | <----- SYN-ACK ----------- |
  | -------- ACK ------------> |

A completed handshake supports the claim that TCP connection establishment completed for that observed endpoint and path.

It does not prove the application returned correct data, the user is authorized, TLS succeeded, or the application's dependencies are healthy.

Transport success is one layer of evidence.

Silence and rejection are different evidence

Compare two traces.

Trace A

client → server  SYN
client → server  SYN
client → server  SYN

No response is visible at this observation point.

Possible explanations include host unavailability, routing failure, filtering, service-path failure, or an incomplete observation point.

Do not jump directly to "the firewall blocked it."

Trace B

client → server  SYN
server → client  RST,ACK

Now something responded.

In a simple case, that can be consistent with the destination being reachable but no accepting TCP listener being available at that endpoint.

The pattern is different from silence.

Evidence changes the hypothesis.

UDP does not use the TCP handshake

A UDP application can send a datagram without first building TCP-style connection state:

client -------- UDP datagram --------> server

If no response appears, several possibilities remain: the datagram never arrived, filtering dropped it, the service is absent, the application does not respond that way, the response was lost, or the observation point missed it.

Do not translate TCP assumptions directly onto UDP.

The complete A+ service-port set

Recognize these common defaults:

These are default associations, not laws of physics.

Administrators can configure services on other ports. A port number alone does not prove what software is present or whether using it is authorized.

Group ports by the human problem

Memorizing disconnected numbers is miserable and not durable.

Naming and configuration

• DNS: 53
• DHCP: 67/68

Web

• HTTP: 80
• HTTPS: 443

Email

• SMTP: 25
• POP3: 110
• IMAP: 143

Remote access

• SSH: 22
• Telnet: 23
• RDP: 3389

File and directory services

• FTP: 20/21
• LDAP: 389
• SMB/CIFS: 445
• NetBIOS/NetBT: 137-139

Now the numbers belong to service families instead of floating around as trivia.

Worked case: host responds, file share does not

Evidence:

client IP config: valid
gateway: reachable
server IP: reachable
DNS name: resolves
SMB share: unavailable

Is "the network is down" defensible?

No.

The lower path works well enough to reach the server and resolve its name.

The investigation moves toward the SMB service, TCP 445 path, share name, authentication, permissions, or server application state.

Worked case: TCP 443 connects, page still fails

Suppose the TCP handshake succeeds to port 443, but the application returns an error afterward.

What did the handshake prove?

Transport establishment.

What remains unproven?

• TLS or application negotiation;
• authentication;
• web service logic;
• upstream dependency health;
• content correctness.

This is why "the port is open" is technically incomplete and often practically unhelpful.

Turn the port into a service question

For DNS, HTTPS, SMB, SSH, RDP, and DHCP, record:

• default port or ports;
• TCP or UDP clue;
• user-visible function;
• one thing successful transport evidence would prove;
• one thing it would not prove.

Then classify the remaining A+ ports by service family.

Before you move on

Use this model:

IP path works?
    ↓
transport endpoint reachable?
    ↓
expected service listening/responding?
    ↓
application function works?
    ↓
user authorized and result correct?

Every step is a larger claim.

Do not skip from one successful packet to "the application works."

Next we move back down to the wireless edge, where another misleading signal appears: strong radio strength with a broken upstream network.