Featured image of post Debunking the Misconception: Maximum Number of TCP Connections on a Server

Debunking the Misconception: Maximum Number of TCP Connections on a Server

 

Introduction

There’s a widespread misconception:

Since TCP port numbers are 16-bit unsigned integers with a maximum value of 65535, a single server can support at most 65536 TCP socket connections.

Even experienced network programmers may believe this conclusion to be proper. Let’s debunk this myth using both theoretical and practical perspectives.

Theoretical Analysis

In *nix systems, each TCP connection is uniquely identified by a 4-tuple structure: {local_ip, local_port, remote_ip, remote_port}.

For IPv4, the system can theoretically manage up to 2^(32 + 16 + 32 + 16) connections—equivalent to 2^96.

IPv4 can be viewed as a 32-bit unsigned number.

Breaking Down the 4-Tuple Limits

  1. A single server typically uses only one local_ip, meaning the server could theoretically manage 2^(16 + 32 + 16) connections.
  2. A single service (e.g., an Nginx process) usually listens on one local_port, which reduces the capacity further to 2^(32 + 16).
  3. If one remote machine (client) connects to a server, fixing local_ip, local_port, and remote_ip leaves only the remote_port variable. Since the remote_port range is 16-bit, there are only 2^16 = 65536 possible connections from a single client to a specific server endpoint.

This limitation is the root of the classic misunderstanding.

For protocols beyond TCP (like UDP), the tuple expands to include the protocol type, making it a 5-tuple, adding even more possibilities.

The actual limits for a server depend on factors beyond the tuple structure.


Practical Limitations

File Descriptors

In Linux, everything is treated as a file, and sockets are no exception. The number of file descriptors determines the maximum number of simultaneous TCP connections.

  1. Maximum file descriptors supported by the system:

    1
    2
    
    [root@test1 ~]# cat /proc/sys/fs/file-max
    1616352
    
  2. Maximum file descriptors per process:

    1
    2
    
    [root@test1 ~]# ulimit -n
    1024
    

Both values can be modified. For instance, during stress testing, these limits are often increased manually.

ip_local_port_range

When a client connects to the same TCP endpoint (ip:port), each connection requires a unique local TCP endpoint. For clients with a single IP, the available local ports determine the connection limit.

On *nix systems, the default local port range is typically from 32768 to 61000. Check this range using:

1
2
[root@test1 ~]# cat /proc/sys/net/ipv4/ip_local_port_range
32768    60999

This means a single client can establish around 30,000 connections to the same server endpoint during stress tests.

Operating systems automatically reuse local ports if multiple distinct remote endpoints (ip:port) are involved.

Memory & CPU

Each TCP socket in the ESTABLISHED state consumes approximately 3.3 KB of memory. While CPU usage for idle connections is minimal, the server’s memory capacity significantly impacts the total number of connections.

In practice, hardware resources like memory and CPU limit the maximum number of TCP connections a server can handle, long before reaching the theoretical 4-tuple limit.
2^96 is too bigger


Summary

The maximum number of TCP connections a server can support is an astronomical 2^96. However, practical constraints like memory, CPU, file descriptors, and port availability impose far lower limits.

There’s no universal number; the limit depends on hardware, configuration, and workload.


Licensed under CC BY-NC-SA 4.0
Last updated on Dec 02, 2024 15:44 CST
Built with Hugo
Theme Stack designed by Jimmy