Maximum TCP Connections per Server Process and per Server

During a Tencent interview, candidates were asked two questions: the maximum number of TCP connections a single server‑side process can handle, and the maximum a whole server can support.

A TCP connection is represented in the kernel by a struct socket (which contains a struct sock) and an struct inet_sock that stores the IPv4 four‑tuple (source IP, source port, destination IP, destination port). The server process typically listens on one port (e.g., 443) bound to 0.0.0.0, meaning the IP address is fixed while the client side varies.

The theoretical upper bound for a single process is the number of possible client IPs (2 32 ) multiplied by the number of client ports (2 16 ), i.e., 2 48 ≈ 2.8×10 14 connections. In practice this is limited by file‑descriptor and memory resources.

Linux imposes three levels of file‑descriptor limits:

System‑wide limit: cat /proc/sys/fs/file-max User‑level limit: cat /etc/security/limits.conf Process‑level limit: cat /proc/sys/fs/nr_open Each TCP connection also consumes memory; an established connection occupies about 3.44 KB (≈0.81 KB + 2.19 KB + 0.19 KB + 0.25 KB). Therefore, an 8 GB server can hold roughly 8 GB / 3.44 KB ≈ 2.4 million concurrent connections.

When considering the whole server, multiple processes can listen on different ports (up to 65 535). The theoretical count becomes 2 32 × 2 16 × 2 16 , effectively unbounded, but real limits are still governed by file descriptors and memory.

In summary, the ideal maximum per process is 2 48 connections, but practical limits are in the millions, dictated by OS resources.