Ports: Addressing a Process, Not a Machine

IP addresses a host — strictly, an interface. Once the packet is inside the host, the transport layer needs a second address to pick a socket, and that is the port: a 16-bit number (0–65535) in the TCP or UDP header, one for the source and one for the destination. 203.0.113.10:443 therefore means "the process that bound port 443 on the host at 203.0.113.10"; 203.0.113.10:22 on the same machine is a different process entirely. Ports are per transport: TCP 53 and UDP 53 are independent, and DNS listens on both.

A server binds a port and listens so that the kernel knows where to deliver new connections: bind(0.0.0.0:443) then listen(). A client does not choose its port; when it calls connect(), the kernel picks an ephemeral source port from a configured range, which becomes the address replies come back to. A port is not a resource on the network — routers do not see it, and only the two end hosts (and stateful middleboxes such as NATs and firewalls, which is what makes them stateful) care what it is.

Well-known ports (0–1023) are assigned by IANA to specific services, and on Unix-like systems binding one requires root or the CAP_NET_BIND_SERVICE capability — which is why a development server defaults to 8080 or 3000 and why production containers often run unprivileged behind a proxy that owns 80 and 443. Registered ports (1024–49151) are also IANA-listed by convention (5432 PostgreSQL, 6379 Redis, 3306 MySQL, 27017 MongoDB, 9092 Kafka) but any process may bind them. Dynamic / ephemeral ports (49152–65535 per IANA) are for clients; Linux uses a wider range, 32768–60999 by default (net.ipv4.ip_local_port_range), giving 28,232 source ports; Windows and macOS use 49152–65535, about 16,000.

The numbers are conventions, not laws: a web server on port 8443 is still a web server, and a firewall that "allows only HTTPS" by allowing port 443 allows any protocol someone chooses to run there. What is fixed is that the client has to know the port in advance — it is in the URL scheme (https → 443), in the connection string, or in a DNS SRV record.

A TCP connection is identified by four values: (source IP, source port, destination IP, destination port). Add the protocol and it is the 5-tuple that NATs, firewalls and load balancers hash. The server’s side of every connection is the same — 203.0.113.10:443 — and that is fine, because the *client* side differs: 198.51.100.7:62014, 198.51.100.7:62015, 192.0.2.9:41000. The kernel demultiplexes an incoming segment by looking up the full 4-tuple in a hash table of established sockets; only a SYN that matches nothing falls through to the listening socket on port 443.

This answers the question beginners ask: how can one port serve thousands of clients? Because the port is not the connection; the tuple is. A server on port 443 can, in principle, hold 2^16 connections from *each* client IP, and accept() returns a *new* descriptor for each one while the listening socket keeps its port. It also answers the opposite question — why a client runs out: from one source IP to one destination IP:port, only the source port varies, so there are at most ~28,000 (Linux) distinct connections, and a closed connection’s tuple is unusable for the TIME_WAIT period (60 s on Linux) on the side that closed first.

A service that opens a new connection per request to one upstream — a database, a cache, an internal API behind one IP — burns one ephemeral port per request and leaves it in TIME_WAIT for 60 s after closing. At 500 requests per second that is 30,000 tuples in TIME_WAIT at any moment, more than the 28,232 Linux allows to one destination. The next connect() fails with EADDRNOTAVAIL ("Cannot assign requested address"), and the symptom in the application is intermittent connection errors to a perfectly healthy upstream, with the upstream’s own metrics showing nothing wrong.

The fixes are ordered by how much they address the cause. Connection pooling and keep-alive — reuse connections instead of opening one per request — removes the problem; see Connection Pooling and Keep-Alive and Connection Reuse. Widening ip_local_port_range to 1024–65535 roughly doubles headroom. net.ipv4.tcp_tw_reuse=1 lets the kernel reuse a TIME_WAIT tuple for a new *outgoing* connection when timestamps allow. Spreading upstream traffic across several destination IPs multiplies the tuple space. NAT gateways hit the same wall from the other side — all clients share one source IP — which is why a NAT gateway’s connection-per-destination limit is a number in every cloud provider’s documentation.