TCP and UDP Ports

Learn how TCP and UDP ports identify application endpoints, how source and destination ports support client-server communication, and how port ranges and default services work.

A network port is a 16-bit numeric identifier used by a transport-layer protocol to direct traffic to a particular application or service on a host. A port number can have a value from 0 through 65535.

Ports work with IP addresses. An IP address identifies a host or network interface, while a port identifies an application-level communication endpoint on that host. The IP address gets traffic to the right computer; the port helps the operating system deliver that traffic to the right process.

For example, one server might provide a web service and an FTP service through the same IP address. The services can coexist because they use appropriate protocol-and-port combinations. A client sends traffic to the server IP, transport protocol, and destination port.

Ports in the TCP/IP stack

IP operates at the network layer and carries packets between hosts. TCP and UDP operate at the transport layer and carry traffic between processes or applications on those hosts. Ports appear in the TCP or UDP header, not in the IP header.

Application data
        |
TCP or UDP header: source port, destination port
        |
IP header: source IP address, destination IP address
        |
Network access technology

The IP header supplies the source and destination addresses needed for host-to-host delivery. The transport header supplies source and destination ports needed for application delivery.

Source and destination port fields

Both TCP and UDP headers contain two port fields:

Source port: the local port used by the sender. It helps the receiver identify where replies should be sent.
Destination port: the port targeted by the packet. On the receiving host, it helps the operating system deliver the packet to the intended listening service or application.

TCP and UDP maintain separate port namespaces. Therefore, TCP port 53 and UDP port 53 are different transport endpoints. The number alone is not enough to identify an endpoint; the transport protocol must also be included.

What the headers contain

A TCP header includes a source-port field and a destination-port field along with other TCP fields used for connection management, sequencing, acknowledgements, and reliability. A UDP header also includes source and destination ports, but UDP has a smaller header and does not provide TCP's connection-management and reliability features.

IPv4 header
  Source IP:      192.168.0.50
  Destination IP: server address

TCP or UDP header
  Source port:      1200
  Destination port: service port

This combination lets the receiving host first use the destination IP to identify the local interface or host, then use the transport protocol and destination port to identify the receiving application.

How a complete endpoint is identified

A socket is commonly described as an IP address combined with a port number. For example, 192.168.0.50:1200 identifies a socket on that host.

A complete TCP or UDP flow is more precisely distinguished by the transport protocol and both address-port pairs:

Protocol:       TCP
Source socket:  192.168.0.50:1200
Destination:    203.0.113.20:21

This information is sometimes called a socket pair, connection tuple, or, when all five values are listed, a five-tuple:

Source IP address
Destination IP address
Source port
Destination port
Transport protocol, such as TCP or UDP

The protocol matters because TCP and UDP have separate port spaces. Two flows can use the same numeric source and destination ports if one is TCP and the other is UDP.

Fields used to direct traffic

Field | Layer or protocol context | PurposeSource IP address | IP header | Identifies the host or interface that sent the packet. Destination IP address | IP header | Identifies the host or interface that should receive the packet. Source port | TCP or UDP header | Identifies the sender's local transport endpoint and gives the receiver a return target. Destination port | TCP or UDP header | Identifies the service or application endpoint targeted on the receiving host. Transport protocol | IP and transport-layer context | Distinguishes TCP delivery from UDP delivery and selects the corresponding port namespace.

Client-server port behavior

A server is an application that listens for incoming requests and responds to them. A listening port is a local port on which that server waits for traffic.

A client is an application that initiates a request. The client chooses the server's IP address, transport protocol, and service port. The client's operating system normally selects an available local source port automatically. This temporary client-side port is often in the dynamic or private range, although the exact selection depends on the operating system and configuration.

Suppose a client uses TCP port 1200 to contact an FTP server on TCP port 21:

In the outbound request, the source IP is 192.168.0.50, the source port is 1200, the destination IP is the FTP server's address, the destination port is 21, and the protocol is TCP. The response reverses the source and destination address-port roles.

Request:
  TCP 192.168.0.50:1200  ->  <FTP-server-IP>:21

Response:
  TCP <FTP-server-IP>:21  ->  192.168.0.50:1200

Port 21 identifies the FTP control service on the server side. Port 1200 identifies the client-side endpoint to which the response must return. Without the source port, the client host could have difficulty associating the response with the process that made the request.

One IP address, multiple services

A single IP address can support several services because each service can listen on a different protocol-and-port combination. For example:

An HTTP service might listen on a conventional TCP port.
An FTP control service conventionally listens on TCP port 21.
A UDP service can use the same numeric port as a TCP service because TCP and UDP port namespaces are separate.

The destination protocol and destination port work together to select the transport endpoint. The destination IP address selects the host or interface. This is why an IP address by itself does not specify which application should receive traffic.

Port-number ranges and categories

The full valid port-number range is 0–65535. Port numbers are commonly grouped into three categories.

Range | Category | Typical use | Notes0–1023 | Well-known ports | Common, established system and network services | Many operating systems restrict binding to these ports to privileged or elevated processes. Port 0 is reserved or special in many APIs rather than a normal service destination. 1024–49151 | Registered ports | Applications and services associated with registered assignments | Registration does not guarantee that a particular host uses the port for that service. 49152–65535 | Dynamic or private ports | Temporary client-side source ports and private applications | Operating systems often select temporary client ports from this range, but the actual ephemeral range can vary.

These categories are conventions, not security boundaries and not proof of service identity. A service can be configured to use a nondefault port, and an application can use a port outside the range normally associated with it.

Default service ports

A default service port is a conventional port that clients commonly try when no alternative port is specified. Defaults simplify configuration because a client and server can agree on a destination without separately entering a port every time.

FTP, the File Transfer Protocol, conventionally uses TCP port 21 for control traffic. An FTP client can therefore contact an FTP server at its IP address on TCP port 21 when the server uses its standard configuration.

HTTP, the Hypertext Transfer Protocol, is another example of a server service commonly associated with a known port. The important principle is that the port is a convention: an administrator can configure the service to listen elsewhere, and clients must then target the configured port.

TCP ports and UDP ports

TCP and UDP both use source and destination ports, but they provide different transport behavior.

TCP, or Transmission Control Protocol, is connection-oriented. It establishes a connection and provides reliable, ordered delivery with mechanisms for acknowledgements and retransmission.
UDP, or User Datagram Protocol, is connectionless. It sends independent datagrams without TCP's built-in connection establishment, ordering, or retransmission behavior.

This article focuses on how ports address applications, not on a full comparison of TCP and UDP. The same numeric port can represent different endpoints depending on the protocol. For example, TCP port 53 and UDP port 53 must be treated separately.

For more detail about the protocols themselves, see Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).

Default ports versus configured ports

Consider a server whose administrator moves an HTTP service from its conventional port to a custom TCP port. A client that assumes the default will contact the wrong destination, even if it has the correct server IP address. The client must specify the service's actual configured port.

Correct IP address plus incorrect protocol or port can still fail to reach the intended service.
A listening service on a custom port may be missed by a scan that checks only common ports.
A conventional port can be used by different software, deliberately or accidentally.

When learning Nmap, remember that a scan reports transport reachability and port states, while identifying the software behind a port is a separate task. See Port States and Interpret Scan Results.

Troubleshooting port-related problems

The host IP is correct, but the client cannot reach the service

Verify the transport protocol and destination port. The correct host address only identifies the machine; it does not identify the intended application endpoint. Also consider whether the service is listening, a firewall is filtering traffic, or the service uses a custom port.

The response does not reach the initiating application

Check that the response preserves the client's source address and source port as its destination values. Return traffic must also be permitted to that endpoint. Network address translation, firewalls, and local application state can affect this return path.

A conventional port is assumed to prove a service is running

Do not treat a port number as a guarantee. Port 21 is conventionally associated with FTP, but administrators can change the FTP port, and another application could listen on TCP port 21. Use appropriate service identification when the software identity must be confirmed.

Two applications appear to use the same port number

Determine whether the applications use different protocols, different local IP addresses, or different hosts. TCP and UDP port spaces are separate, so a TCP service and a UDP service can use the same number without being the same endpoint. On one local IP and protocol combination, two applications generally cannot bind the same listening endpoint unless the operating system and socket options explicitly allow a sharing arrangement.

Practical checklist

Identify the destination host with its IP address.
Identify whether the traffic uses TCP or UDP.
Identify the destination port for the service.
Identify the client's source IP address and temporary source port.
For replies, confirm that the server targets the client's source address and source port.
Remember that default ports are conventions, not proof of service identity.

In short, ports provide transport-layer application addressing. IP addresses move traffic between hosts, while TCP or UDP source and destination ports help each host deliver that traffic to the correct process and return responses to the correct client endpoint.