TCP vs UDP Ports, Well-Known Numbers & Socket Port Exhaustion Guide

In the OSI and TCP/IP networking models, IP addresses (Layer 3) identify a specific physical or virtual network interface on the global Internet. However, a single server or workstation typically runs dozens of independent networked processes simultaneously—such as a web server (Nginx), database engine (PostgreSQL), and SSH daemon.

To route incoming packets to the correct application process, the Transport Layer (Layer 4) introduces Port Multiplexing. A port is a 16-bit unsigned integer (ranging from 0 to 65,535). By pairing an IP address with a port number, operating systems create a network Socket that uniquely identifies an end-to-end communication channel.

The Internet Assigned Numbers Authority (IANA) partitions the 65,536 available port numbers into three standardized functional categories:

1. Well-Known Ports (0 – 1023): Reserved for foundational Internet services and system protocols (HTTP 80, HTTPS 443, SSH 22, DNS 53, SMTP 25). On Unix and Linux operating systems, binding a process to a port below 1024 requires privileged permissions (root or CAP_NET_BIND_SERVICE).
2. Registered Ports (1024 – 49151): Assigned by IANA to specific commercial software and database engines upon request (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017).
3. Dynamic / Ephemeral / Private Ports (49152 – 65535): Dynamically allocated by the client operating system kernel when initiating an outbound connection to a remote server.

A pervasive architectural myth is that a web server listening on port 443 can only accept a maximum of 65,535 concurrent client connections. In reality, a TCP connection is defined not by a single port, but by a 4-Tuple:

{ Source IP, Source Port, Destination IP, Destination Port }

Because the Destination IP and Destination Port (e.g., 203.0.113.1:443) remain constant, every distinct combination of client Source IP and client Source Port represents an independent socket descriptor. Consequently, a single web server with sufficient file descriptors and RAM can comfortably maintain hundreds of thousands of concurrent open connections.

While servers easily scale inbound connections, microservices acting as clients frequently suffer from Ephemeral Port Exhaustion:

When a backend service initiates rapid, short-lived HTTP requests to an upstream microservice without connection pooling (HTTP Keep-Alive), each request consumes an ephemeral port. When the client closes the TCP connection, the TCP state machine places the socket into the TIME_WAIT state for 60 to 120 seconds (2 * Maximum Segment Lifetime) to ensure delayed in-flight packets do not corrupt subsequent connections.

Under high throughput, all available ephemeral ports (~28,000 ports in Linux default range 32768–60999) become saturated in TIME_WAIT, causing outgoing requests to fail with EADDRNOTAVAIL: Cannot assign requested address. The production remedy is enabling HTTP keep-alive connection pooling.

# Check current ephemeral port range in Linux
cat /proc/sys/net/ipv4/ip_local_port_range
# Typical output: 32768 60999 (28,232 available ports)

# Inspect sockets currently stuck in TIME_WAIT status
ss -tan state time-wait | wc -l

# Optimize TCP socket reuse in sysctl.conf
net.ipv4.tcp_tw_reuse = 1

To harden network infrastructure against reconnaissance and unauthorized access:

1. Bind to 127.0.0.1 vs 0.0.0.0: Internal databases (Redis, PostgreSQL) should never listen on 0.0.0.0 (all public interfaces). Bind them strictly to localhost or private VPC subnet interfaces.
2. Default-Deny Firewall Configuration: Close all unused ports using Linux ufw or AWS Security Groups, opening only 80 and 443 to the public internet.
3. Port Scanning Audit: Regularly inspect listening daemon sockets using ss -tlpn or explore well-known service assignments with the DevUtils Port Numbers directory.