CCNA online course

TCP and UDP Port Numbers and Well-Known Services

Learn how TCP and UDP ports identify applications, how client-server sessions use source and destination ports, and memorize common CCNA service ports.

Transport-layer ports allow a host to identify the application that should send or receive network traffic. An IP address identifies a host, while a port number identifies an application or service on that host. Together, an IP address and port provide an endpoint for communication.

This lesson covers TCP and UDP port fields, client-server behavior, sockets, port ranges, common CCNA service ports, troubleshooting, and security considerations.

Why Transport-Layer Ports Are Needed

At Layer 3, an IP address identifies a host. For example, 192.168.0.50 identifies one device on an IPv4 network. However, that device might run a web browser, DNS resolver, SSH client, email application, and many other processes at the same time.

An IP address alone cannot tell the receiving host which application should receive a packet. A port number is a 16-bit transport-layer identifier for an application or service endpoint. The combination of the IP address and port directs traffic to a particular process.

For example, a packet sent to 192.168.0.10 reaches the correct host, but the destination port determines whether the packet is intended for a web server, SSH server, DNS service, or another process.

TCP and UDP Port Fields

Both TCP and UDP headers contain a source port and a destination port. The source port is associated with the sending application. The destination port identifies the target application or service.

• Each port field is 16 bits long.
• The full numeric range is 0 through 65535.
• TCP and UDP have separate port-number spaces.
• TCP port 53 and UDP port 53 are different transport endpoints.

A packet sent to UDP port 53 is not delivered to a process listening only on TCP port 53. The operating system uses both the transport protocol and port number when delivering traffic.

TCP is a connection-oriented transport protocol with port addressing. UDP is a connectionless transport protocol that also uses port addressing. Port numbers do not make UDP connection-oriented; they identify the application endpoint in either protocol.

Client-Server Port Behavior

In the client-server model, a client requests a service and a server provides it. A server application normally opens a listening port, which is a local port where the process waits for incoming requests.

1. The server listens on a known service port, such as TCP 443 for HTTPS.
2. The client selects a temporary locally available source port, called an ephemeral port.
3. The client sends traffic to the server IP address and the service's destination port.
4. The server sends replies from its service port to the client's temporary port.

For a request, the client source and destination values might be:

Source:      192.168.0.50:1200
Destination: 192.168.0.10:21
Protocol:    TCP

The reply reverses the direction:

Source:      192.168.0.10:21
Destination: 192.168.0.50:1200
Protocol:    TCP

FTP Port-Mapping Example

Suppose an FTP client at 192.168.0.50 selects TCP source port 1200. It contacts an FTP server at server-address using TCP destination port 21, the traditional FTP control port.

The client socket is 192.168.0.50:1200. The complete flow identification includes both endpoint sockets and the transport protocol: client IP, client port, server IP, server port, and TCP.

Traffic Identification and Demultiplexing

A communication flow is distinguished by a combination commonly called a five-tuple:

• Source IP address
• Destination IP address
• Source port
• Destination port
• Transport protocol, TCP or UDP

Multiplexing is the transport-layer process of combining traffic from multiple applications for transmission. Demultiplexing is the receiving process of examining protocol and port information and delivering each segment or datagram to the correct application.

This is why many simultaneous sessions can use the same server. For example, two browser tabs can both connect to the same HTTPS server at TCP port 443 while using different client-side source ports:

Client A: 192.168.0.50:51000  ->  203.0.113.10:443  TCP
Client B: 192.168.0.50:51001  ->  203.0.113.10:443  TCP

The differing source ports make the flows distinct. The receiving operating system uses the flow information to deliver each reply to the correct browser connection.

Sockets and Socket Pairs

A socket is an endpoint represented by an IP address combined with a port number. For example, 192.168.0.50:1200 identifies one endpoint.

A socket pair consists of the two communicating endpoint sockets:

Client socket: 192.168.0.50:1200
Server socket: 192.168.0.10:21

To uniquely identify traffic, protocol information is also needed. TCP and UDP maintain separate port spaces, so the complete identification includes both sockets and TCP or UDP.

Port-Number Categories

IANA, the organization responsible for coordinated protocol parameter assignments, maintains service-name and port registries. These categories are useful for study and reference, although operating systems can configure their actual ephemeral-port selection differently.

A well-known port is in the 0-1023 range. A registered port is in the 1024-49151 range. A dynamic port is in the 49152-65535 range. An ephemeral port is a temporary client-side port selected for a session; it is commonly drawn from a high-numbered range.

Common TCP and UDP Ports for CCNA Study

Protocol-Specific Distinctions

DNS Uses UDP and TCP

A service name does not by itself determine the transport protocol. DNS commonly sends queries using UDP port 53 because UDP has low overhead. DNS also uses TCP port 53 for situations such as larger responses, truncated responses, and some DNS operations.

Firewall rules and troubleshooting checks must therefore distinguish UDP 53 from TCP 53. Allowing one does not automatically allow the other.

FTP Control and Data Connections

Traditional FTP uses TCP 21 for the control connection and TCP 20 for the data connection in active FTP. Active and passive FTP behave differently: the data connection's ports and direction depend on the selected mode. A successful login on TCP 21 does not prove that file transfers will work.

HTTP, HTTPS, Telnet, and SSH

• HTTP conventionally uses TCP 80.
• HTTPS conventionally uses TCP 443.
• Telnet conventionally uses TCP 23, but it sends data without encryption.
• SSH conventionally uses TCP 22 and is preferred for secure remote administration.

Recognizing a port helps identify intended traffic, but the port number does not prove that the protocol is secure or that the service is authorized.

Security and Operational Relevance

Firewalls and access control lists commonly match source and destination addresses together with the transport protocol and port number. A rule might permit TCP traffic to a web server at destination port 443 while denying other inbound services.

An open listening port means that a service is reachable on that endpoint. It does not automatically mean the service is safe, patched, authorized, or correctly configured. Good operational practice includes:

• Disable unnecessary services and close unused listening ports.
• Prefer secure protocols such as SSH over Telnet.
• Limit management ports to trusted source networks.
• Review firewall and ACL rules for both protocol and port.
• Monitor listening sockets and investigate unexpected services.

Inspecting Ports and Testing Reachability

On Windows, netstat -ano displays active connections, listening ports, and associated process IDs.

netstat -ano

On Linux, ss -tulpen displays listening TCP and UDP sockets with process and port information.

ss -tulpen

On supported Cisco IOS platforms and releases, these commands can help inspect device services:

show ip sockets
show control-plane host open-ports

To test TCP reachability to a destination port from a system with Netcat installed:

nc -vz <host> <tcp-port>

A successful TCP test shows that a TCP connection could be established at that moment. It does not prove that the application is functioning correctly, and it does not test UDP behavior.

Troubleshooting Port Problems

Host Is Reachable but the Service Does Not Work

Being able to reach a server IP address does not prove that the intended service is available. Possible causes include:

• The service is not listening on the expected port.
• The client used the wrong destination port.
• A firewall or ACL blocks the required protocol and port.
• The service listens only on a different IP address or interface.

Verify the destination IP, transport protocol, and destination port. Then inspect listening sockets on the server and review firewall, ACL, and NAT rules.

DNS Is Inconsistent or Large Responses Fail

UDP 53 may be permitted while TCP 53 is blocked. A firewall rule might match port 53 but accidentally apply only to one transport protocol. Check both UDP 53 and TCP 53 when the DNS design requires both, and inspect firewall logs or packet captures.

FTP Login Works but File Transfer Fails

The control connection on TCP 21 may be allowed while the data channel is blocked. Determine whether the client uses active or passive FTP, then review the firewall's handling of the required data connection and negotiated ports.

A Port Scan Reports Closed or Filtered

No process may be listening, a firewall may be rejecting or silently dropping traffic, or the scan may use the wrong transport protocol. Confirm whether the service uses TCP or UDP, check the server's listening state, and compare host firewall and network ACL policies with the expected service.

Exam-Relevant Summary

For related Layer 3 and protocol-layer context, review the OSI reference model and computer networking fundamentals.