How Many Socket Connections Possible

Maximum number of Socket (for HTTP traffic) connections possible for a single machine

The connection is identified by Source address, Destination Address, Source port, Destination port. So if you fix the destination port to 80 (HTTP), the destination address to your server IP and the source address to your client IP, then, yes the number of contemporaneous connections cannot exceed the number of port range.

Theoretically your server can have more connections than the port range if it talks with multiple clients.

What is the theoretical maximum number of open TCP connections that a modern Linux box can have

A single listening port can accept more than one connection simultaneously.

There is a '64K' limit that is often cited, but that is per client per server port, and needs clarifying.

Each TCP/IP packet has basically four fields for addressing. These are:

source_ip source_port destination_ip destination_port
<----- client ------> <--------- server ------------>

Inside the TCP stack, these four fields are used as a compound key to match up packets to connections (e.g. file descriptors).

If a client has many connections to the same port on the same destination, then three of those fields will be the same - only source_port varies to differentiate the different connections. Ports are 16-bit numbers, therefore the maximum number of connections any given client can have to any given host port is 64K.

However, multiple clients can each have up to 64K connections to some server's port, and if the server has multiple ports or either is multi-homed then you can multiply that further.

So the real limit is file descriptors. Each individual socket connection is given a file descriptor, so the limit is really the number of file descriptors that the system has been configured to allow and resources to handle. The maximum limit is typically up over 300K, but is configurable e.g. with sysctl.

The realistic limits being boasted about for normal boxes are around 80K for example single threaded Jabber messaging servers.

How many system resources will be held for keeping 1,000,000 websocket open?

Updated Answer

Short answer: yes, but it's expensive.

Long answer:

This question is not unique to WebSockets since WebSockets are fundamentally long-lived TCP sockets with a HTTP-like handshake and minimal framing for messages.

The real question is: could a single server handle 1,000,000 simultaneous socket connections and what server resources would this consume? The answer is complicated by several factors, but 1,000,000 simultaneous active socket connections is possible for a properly sized system (lots of CPU, RAM and fast networking) and with a tuned server system and optimized server software.

The number of connections is not the primary problem (that's mostly just a question of kernel tuning and enough memory), it is the processing and sending/receiving data to/from each of those connections. If the incoming connections are spread out over a long period, and they are mostly idle or infrequently sending small chunks of static data then you could probably get much higher than even 1,000,000 simultaneous connections. However, even under those conditions (slow connections that are mostly idle) you will still run into problems with networks, server systems and server libraries that aren't configured and designed to handle large numbers of connections.

See Alessandro Alinone's answer about approximate resource usage for 500,000 connections.

Here are some older but still applicable resources to read on how you would configure your server and write your server software to support large numbers of connections:

What is the theoretical maximum number of open TCP connections that a modern Linux box can have
http://www.kegel.com/c10k.html

What is the practical / hard limit on socket connections per server

Assuming you select a sensible architecture for your server then the limit will be memory and cpu related. IMHO you'll never reach the hard limit that Martin mentions :)

So, rather than worrying about a theoretical limit that you'll never hit you should, IMHO, be thinking about how you will design your application and how you will test it to determine the current maximum number of client connections that you can maintain for your application on given hardware. The important thing for me is to run your perf tests from Day 0 (see here for a blog posting where I explain this). Modern operating systems and hardware allow you to build very scalable systems but simple day to day coding and design mistakes can easily squander that scalability and so you simply MUST run perf tests all the time so that you know when you are building in road blocks to your performance. You simply cannot go back and fix these kind of mistakes at the end of the project.

As an aside, I ran some tests on Windows 2003 Server with a low spec VM and easily achieved more than 70,000 concurrent and active connections with a simple server based on an overlapped I/O (I/O completion port) based design. See this answer for more details.

My personal approach would be to get a shell of a server put together quickly using whatever technology you decide on (I favour unmanaged C++ using I/O Completion Ports and minimal threads), see this blog posting for more details. Then build a client or series of clients that can stress test the application and keep updating and running the test clients as you implement your server logic. You would expect to see a gradually declining curve of maximum concurrent clients as you add more complexity to your server; large drops in scalability should cause you to examine the latest check ins to look for unfortunate design decisions.

Number of network connections possible

There's many different pieces in play. Since a connection is defined by (Src IP, Src Port, Dest IP, Dest Port) tuples, you're allowed 65536 ^ 2 connections between two given peers at any given time: from 1 to 1, from 1 to 2, .. from 1 to 65535, etc. And that's just between two peers -- you can of course have many connections open to many peers simultaneously.

BUT, most operating systems limit the number of open filedescriptors / handles per process. This limit was historically low (20), but is now often higher (1024 on my system, ulimit -a will show per-process limits in bash(1)).

In addition to the setrlimit(3) limits on Unix systems, there are also system-wide limits; /proc/sys/fs/file-max on a Linux system will report the maximum number of open files allowed on the entire system. (This is 596118 on my system.) Other systems will have different limits.

And, there may be a limit to the number of open connections enforced by a stateful firewall in the middle. Since each state requires memory in the firewall tables, any will probably enforce some arbitrary limit to avoid running short on memory.

In a tcp connection, how possibly can a server handle more than 65535 client at an instant?

A unique TCP connection is defined by a unique combination of client IP, client port, server IP and server port. For a specific service server IP and port are constant (i.e. port 80 for HTTP), but client IP and port can vary. Since the port range is only 1..65535 this means that the server can only handle at most 65535 different connections from the same client IP address at the same time, because these are all possible unique combinations of the connection tuple when only the port can be changed. But, if there are multiple clients with different IP addresses this limitations applies to each of these clients separately. If you then look at the amount of different possible IP addresses (IPv4 and IPv6) you'll see that there is essentially no real limit of how much connections the server could handle in theory.

In practice each of these TCP connections takes memory at the server since the current state has to be kept. Additional memory is needed in kernel and application for file descriptor and application protocol state etc. This means that there is a practical limit based on the resources of the machine which might be less then 64k but also way more, depending on the system and its configuration.