A port number is a 16-bit unsigned integer carried in the header of transport protocols such as TCP and UDP that identifies which application or service on a host should send or receive a given segment or datagram. In networking, the IP address delivers a packet to the right machine, and the port number delivers its payload to the right process on that machine.
Every transport-layer exchange uses two port numbers, a source port and a destination port. Together with the source and destination IP addresses and the protocol, they form the five-tuple that uniquely identifies a connection or flow, which is why a single server can handle thousands of simultaneous clients on one well-known port.
How a port number directs traffic in transport protocols
A port number works as a demultiplexing key: when a segment arrives, the operating system reads the destination port and hands the payload to the socket bound to that port. Because the field is 16 bits wide, the valid range is 0 to 65535, although port 0 is reserved and never appears on the wire as a real destination.
A server process calls bind on a fixed port and listens, while a client usually receives a temporary source port chosen by its operating system. Replies reverse the pair, so the client port becomes the destination. This asymmetry explains why firewalls track connection state rather than simply opening every high port.
The following table shows where the port fields sit and what accompanies them in a transport header.
| Field | Size | Purpose |
|---|---|---|
| Source port | 16 bits | Identifies the sending process for replies |
| Destination port | 16 bits | Selects the receiving service or socket |
| Protocol (in IP header) | 8 bits | Separates TCP port 53 from UDP port 53 |
| IP addresses (in IP header) | 32 or 128 bits each | Complete the five-tuple with the ports |
Port ranges and their assignment
The port space is divided into three ranges managed by IANA. The well-known ports from 0 to 1023 are reserved for core services, and on Unix-like systems binding to them traditionally requires elevated privileges. Registered ports serve vendor applications, while dynamic ports are left for temporary use.
| Range | Name | Typical use |
|---|---|---|
| 0-1023 | Well-known or system ports | HTTP, HTTPS, SSH, DNS, SMTP |
| 1024-49151 | Registered or user ports | Databases, application servers, vendor services |
| 49152-65535 | Dynamic or private ports | Ephemeral client source ports |
Operating systems do not always follow the recommended dynamic range. Many Linux distributions default to an ephemeral range of 32768 to 60999, configurable through net.ipv4.ip_local_port_range, while current Windows versions use 49152 to 65535. The size of this range limits how many concurrent outbound connections one host can open to a single destination address and port.
A port number is a convention, not an enforcement mechanism. Any service can listen on any free port, so seeing traffic on port 443 proves only that something speaks on that port, not that it is genuine HTTPS.
Common port numbers in practice
A small set of ports covers most everyday traffic, and recognizing them speeds up firewall review and troubleshooting. The table lists frequently encountered assignments and their transport protocol.
| Port | Protocol | Service |
|---|---|---|
| 22 | TCP | SSH and SFTP |
| 53 | UDP and TCP | DNS queries and zone transfers |
| 80 | TCP | HTTP |
| 443 | TCP and UDP | HTTPS and HTTP/3 over QUIC |
| 25, 587 | TCP | SMTP relay and mail submission |
| 3306, 5432 | TCP | MySQL and PostgreSQL |
| 123 | UDP | NTP time synchronization |
Note that TCP and UDP maintain separate port spaces. A DNS server listens on both TCP port 53 and UDP port 53, and these are two distinct sockets. Since HTTP/3 runs over QUIC, UDP port 443 now matters for web traffic as much as TCP port 443.
Port number compared with socket and five-tuple
The port number is only one part of the addressing that transport protocols need, and it is often confused with the socket or the whole connection. The comparison below separates these related concepts.
| Concept | What it identifies | Example |
|---|---|---|
| Port number | A service endpoint on one host | 443 |
| Socket address | IP address plus port | 192.0.2.10:443 |
| Socket | The operating system object bound to an address | A listening file descriptor |
| Five-tuple | One unique connection or flow | Protocol, two IPs, two ports |
Because a TCP connection is identified by the full five-tuple, a web server listening on port 443 can accept many connections on the same port. Each accepted connection differs in the client address or the client source port, so the operating system keeps them apart.
Pitfalls when working with port numbers
Most port problems come from mismatched expectations between a service, a firewall and network address translation. The typical failures are listed below.
- Ephemeral port exhaustion: a proxy or load balancer opening many short connections to one backend can run out of source ports while sockets wait in TIME_WAIT.
- Port already in use: a second process cannot bind the same address, port and protocol unless options such as SO_REUSEPORT are set deliberately.
- Wrong protocol opened: a firewall rule for TCP 53 does nothing for ordinary DNS queries that use UDP.
- Port translation by NAT: a home router or carrier-grade NAT rewrites source ports, so the port seen by the server is rarely the one chosen by the client.
- Security through obscurity: moving SSH to a high port reduces automated noise but is not a security control on its own.
In plain words
Think of a computer as a large office building. The IP address is the street address, and the port number is the room number inside. A letter needs both to reach the right person.
When you open a website, your browser knocks on room 443 of the server, and the server answers back to a temporary room your own computer picked for that conversation. The key idea is simple: one address, many doors, each leading to a different program.
A real-world example
A small company runs a web shop and a PostgreSQL database on separate virtual servers. The administrator allows TCP 443 from the internet to the web server, and allows TCP 5432 only from the web server’s address to the database server. Everything else is blocked by default.
During a sales event, the web application starts failing with connection errors to the database. Checking the socket table shows almost 28,000 connections in TIME_WAIT, which nearly fills the Linux ephemeral range. The application opened a new database connection for every request instead of reusing them.
The team adds a connection pool of 40 persistent connections. Source port usage drops to a few dozen, the errors disappear, and the firewall rules stay as tight as before. The outcome: the shop handles the peak without opening any additional ports.