How Many TCP Connections Can a Server Actually Handle? Limits, Tuning, and Real‑World Calculations

Maximum Open Files on Linux

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

fs.file-max – system‑wide maximum number of file descriptors. Root can bypass this limit.

soft nofile – per‑process soft limit; can be increased but must not exceed the hard limit.

fs.nr_open – per‑process hard limit; must be larger than hard nofile and can be set per user.

These parameters are inter‑dependent: raising soft nofile requires raising hard nofile; raising hard nofile requires raising fs.nr_open. Modifying fs.nr_open with echo is not persistent across reboots and is discouraged.

Adjusting Server File Limits (Example)

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

vim /etc/sysctl.conf</code>
<code>fs.file-max=1100000   # system‑wide limit</code>
<code>fs.nr_open=1100000    # must be > hard nofile

Apply the changes: sysctl -p Then set per‑user limits:

vim /etc/security/limits.conf</code>
<code># user‑level limits</code>
<code>soft nofile 1000000</code>
<code>hard nofile 1000000

Maximum TCP Connections on a Server

A TCP connection is represented by a pair of socket kernel objects (the four‑tuple: source IP, source port, destination IP, destination port). The theoretical maximum is 2³² × 2¹⁶ ≈ 2 × 10¹⁴ connections, but practical limits are imposed by CPU and memory.

For ESTABLISHED idle connections, memory consumption is the dominant factor. Each idle connection uses roughly 3.3 KB of RAM. On a 4 GB server, this yields about 1 million concurrent idle connections, assuming no additional workload.

In real workloads with data transfer and processing, the achievable number drops dramatically; even 1 000 concurrent connections can be challenging.

Maximum Connections from a Client Machine

Each outbound TCP connection consumes a local port (0‑65535). The maximum number of connections depends on IP and port combinations:

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

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

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

Port range can be expanded by adjusting net.ipv4.ip_local_port_range. Clients can also obtain multiple IP addresses to increase the limit.

Other Related Issues

The backlog queue length is controlled by net.core.somaxconn (default 128). Increasing it reduces connection‑establishment latency under high concurrency.

After terminating a process, the port may remain in TIME_WAIT; waiting a short period resolves the “port already in use” error.

Binding a client socket to a specific port is discouraged because it overrides the kernel’s port‑selection strategy.

Linux manages sockets via hash tables for fast lookup by the TCP four‑tuple, and epoll uses a red‑black tree to manage monitored sockets efficiently.

Practical Example: Supporting 100 Million Long‑Lived Connections

Assuming a push‑notification service similar to Umeng UPush, where connections are mostly idle and the server pushes data only a few times per day, the CPU overhead is negligible.

With a 128 GB server, each idle connection consumes ~3 KB, allowing roughly 5 million concurrent connections per machine (≈ 15 GB memory). To support 100 million users, about 20 such servers are sufficient.

Example Java client code (for illustration only):

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