When TCP establishes a half-connection during the second handshake, a flood attack can be launched.
A large number of requests initiate TCP connections. During the second handshake, the server will put these requests in the semi-connection queue. Since these malicious attack clients will not confirm the third handshake, these semi-connections cannot be released. The server will wait until the timeout. At this time, the semi-connection queue will be full and normal request connections cannot be answered. This is the method of flood attack.
How to deal with flood attacks in general
When syncookies is enabled, during the first handshake, the server will calculate a hash value (SHA1) based on (source address, source port, destination address, destination port, etc.) and a random number, and then the generated syncookies will be returned to the client in the second handshake. When the client confirms the third handshake, it will send the syncookies to the server again. The server will verify whether the syncookie matches the previous one. If they match, a TCP connection will be established.
The advantage of this approach is that the TCP connection will not be established when the server does not receive or receives syncookies that do not match. When using syncookies, the server will not maintain a semi-connection queue, that is, there is no semi-connection state, because there is no need for semi-connection when using syncookies, so it avoids the semi-connection queue being full and unable to receive new connections.
Scenarios that syncookies cannot solve
When a large number of DDOS attacks are launched, the syncookies method will also be paralyzed. The reason for the paralysis is that the CPU has to calculate a large number of syncookies, which causes the CPU to be killed. Because the calculation of syncookies also consumes CPU performance, facing a huge amount of DDOS, the CPU cannot withstand it. At this time, the only option is to increase the bandwidth and use the hard cap configuration.
Other solutions
Increase the semi-connection queue and the full connection queue (this method is basically ineffective for massive attacks)
Reduce the number of SYN+ACK retransmissions (TCP relies on retransmissions to maintain a stable connection). That is, when a flood attack is received with a large number of SYN requests, the server will not receive a response and will keep retrying until the maximum number of times is reached. Reducing this maximum number can alleviate the problem.
How to check whether it has been attacked by flood