How Many TCP Connections Can a Linux Server Actually Handle?

Background

A common interview question asks how many TCP connections a single server can support. The answer depends on Linux file descriptor limits, memory size, and kernel parameters.

Linux File Descriptor Limits

Linux treats everything as a file, so the maximum number of open files (including sockets) is governed by three parameters:

fs.file-max – system‑wide maximum number of file descriptors. Root is not limited by this value.

soft nofile – per‑process soft limit for open files.

fs.nr_open – per‑process hard limit; can be set per user.

These parameters are coupled:

Increasing soft nofile requires raising the hard nofile limit as well.

If hard nofile is raised, fs.nr_open must be larger than the new hard limit.

Modifying fs.nr_open with echo "value" > /proc/sys/fs/nr_open is not persistent; it will revert after a reboot.

Example: Raising the Open‑File Limit

To allow a process to open one million file descriptors, edit the following files:

vim /etc/sysctl.conf

fs.file-max=1100000   # system‑wide buffer

fs.nr_open=1100000   # must exceed hard nofile

Apply the changes:

sysctl -p

vim /etc/security/limits.conf

# user‑level limits

soft nofile 1000000

hard nofile 1000000

Maximum Server Connections

In theory, a TCP connection is identified by a 4‑tuple (source IP, source port, destination IP, destination port), giving a theoretical maximum of 2^32 * 2^16 ≈ 2×10^14 connections. In practice, CPU and memory are the real constraints.

Each ESTABLISHED connection consumes roughly 3.3 KB of memory. On a 4 GB server, the memory alone limits the number of idle connections to about one million: 4 GB / 3.3 KB ≈ 1 000 000 connections When connections carry traffic and require processing, the achievable number drops dramatically.

Maximum Client Connections

A client consumes one local port per connection. The usable port range is roughly 0–65535 (about 64 000 after excluding reserved ports). Different scenarios affect the total:

Case 1: Single client IP, single server IP, single server port → up to ~65 000 connections.

Case 2: Client has n IP addresses → up to n × 65 000 connections.

Case 3: Server listens on m ports → up to 65 000 × m connections.

The kernel parameter net.ipv4.ip_local_port_range can be adjusted to enlarge the client port range if needed.

Additional Tuning and Considerations

The listen backlog length is controlled by net.core.somaxconn (default 128).

After a process is killed, its ports may remain in TIME_WAIT; waiting a short period usually resolves the issue.

Clients should avoid calling bind() with a fixed port unless necessary, as it overrides the kernel’s port‑selection strategy.

Linux manages sockets via hash tables; epoll uses a red‑black tree for efficient add/remove operations.

Practical Problems

The “too many open files” error occurs when a process exceeds its file‑descriptor limit. Fix it by increasing fs.file-max, soft nofile, and fs.nr_open while respecting their coupling.

For large‑scale push services (e.g., 100 million long‑living connections), memory is the dominant factor. Assuming 128 GB RAM per server and ~3 KB per connection, a single server can handle roughly 5 million idle connections, so about 20 servers would suffice for 100 million users.

Code Example

public static void main(String[] args) throws IOException {
    SocketChannel sc = SocketChannel.open();
    // Optional bind (not recommended for normal clients)
    sc.bind(new InetSocketAddress("localhost", 9999));
    sc.connect(new InetSocketAddress("localhost", 8080));
    System.out.println("waiting..........");
}