- TCP Maximum number of connections
in the TCP Application, Server listen in advance on a fixed port, Client initiate the connection and build after the three-way handshake TCP connection. So what is the maximum number of concurrent TCP connections for a single machine?
- Theoretical maximum Value
before determining the maximum number of connections, let's look at how the system identifies a TCP connection. The system uniquely identifies a TCP connection with a 4 four -tuple: {Local IP, local port,remote ip,remote port} . ServerMaximumTCPNumber of connectionsServerusually fixed on a local port for listening, waiting forClientconnection request. Address reuse is not considered (Unixof theso_reuseaddroption), even if theServerEnd has multipleIP, the local listening port is also exclusive, soServerEndTCPConnection4only in tuplesRemote IP(i.e.Client IP) andRemote Port(ClientPort) is variable, so the maximumTCPConnect as ClientIPnumberxClientPortnumber, yesIPV4, without regardIPaddress classification and other factors, the largestTCPthe number of connections is approximately2of the +Sub-party (IPnumber)X2of the -Sub-party (Portnumber), i.e.Serversingle-side maximumTCPthe number of connections is approximately2of the -The second party.
- the actual TCP Number of connections
The above given is the theoretical maximum number of single-machine connections, in the actual environment, by the machinery resources, operating systems, etc., especially sever The maximum number of concurrent TCP connections is far from being limited to a theoretical limit. The main factors that limit the number of connections under Unix/linux are memory and the number of file descriptors allowed (each TCP connection consumes a certain amount of memory, each socket is a file descriptor), and the following ports are usually reserved ports. under the default 2.6 kernel configuration, it is tested that each socket occupies within 15~20k between. This means that the number of TCP connections is related to memory and the maximum number of descriptors allowed. On the server side, the maximum number of concurrent TCP connections over 100,000 is no problem by increasing the memory and modifying the number of maximum file descriptors (FD). So the question is, how is the DDoS attack going?
- Number of TCP semi-connections for DDoS attacks
In a DDoS attack, if the server allows a large number of TCP connections, server memory is very large, then the attacker is often to send a large number of TCP semi-connection requests, so that the number of connections exceeds the maximum value of FD or FD does not exceed the maximum value, but the amount of memory to maintain FD exceeds the server memory, Because the number of FD corresponds to the number of connections, and a large number of semi-connections need to maintain a lot of memory, so that the server can not process. Also, if the server uses Select/poll mode for multiplexing, the CPU resources consumed are equally scary. So for a DDoS attack, all we have to do is limit the number of semi-connections so that it doesn't affect normal requests, and I/O multiplexing using the Epoll mode. Here's a brief introduction to Epoll and Select/poll:
Epoll is an enhanced version of the multiplexed IO interface select/poll for Linux, which significantly increases the system CPU utilization in cases where there is only a small amount of activity in a large number of concurrent connections, because it will reuse the file descriptor set To pass the result without forcing the developer to prepare the set of file descriptors to be listened to before each wait for the event, the other is that it does not have to traverse the entire set of descriptors that is being listened to, as long as it iterates through the set of descriptors that are joined to the ready queue by an asynchronous wake-up of the kernel IO event. Epoll provides edge triggering (edge triggered) in addition to the level triggered of Select/poll IO events, which makes it possible for user space programs to cache IO status and reduce epoll_wait/ Epoll_pwait calls to improve application efficiency. Et only reads the data once (even if it is not finished and is not notified until the state changes), and LT will be notified until the data has been read.
On the relationship between TCP semi-connection number and FD in DDoS attack