洪水攻击又称洪泛攻击，是DoS攻击或DDoS攻击的常用手段。 但是，对于不同阶段的洪水攻击，我们的应对方法也不同。 当然，这里只讲述防止方法，不说明具体的详细配置。
针对TCP的洪水攻击TCP3次握手规则
以下是三次握手的详细情况：
最初，主机1和主机2都处于关闭状态。 主机1主动打开连接，主机2被动打开连接。 主机2创建TCB传输控制块，用于存储与连接有关的信息，诸如TCP的连接表、指向发送/接收缓存的指针、指向重发队列的指针、发送号码和接收号码等。 TCB创建完成后，打开监听状态。 主机1创建TCB并申请连接。 向b发送请求消息：该消息头的同步位SYN=1，随机序列号seq=x。 注：在TCP中，此时的消息无法携带数据，但必须占用一个序列号。 主机1将处于SYN SENT状态。 主机2接收请求，并向主机1发送连接确认。 在此时的确认消息中，向主机1发送SYN=1、ACK=1、ack=x 1以及随机序号seq=y。 同样需要序列号，无法携带数据。 主机2进入同步恢复状态。 主机1收到确认消息后，将状态更改为ESTABLISHED，并再次向主机2发送消息。 ACK=1，seq=x 1，ack=y 1。 TCP规定，此时的消息可以携带数据，也可以不携带数据。 如果不携带数据，则不需要序列号，下次序列号保持seq=x 1，这次保持seq=x。 主机2接收连接确认，进入ESTABLISHED状态。 其中一个细节，ACK与ACK的关系：
ACK :消息被单独识别，仅在ACK=1时有效，在ACK=0时无效。 ack :确认号码是收到的seq 1，意味着我应该收到的下一条消息的号码是seq 1。 三次握手的缺陷现在，假设利用洪水攻击，攻击者必然会利用多ip地址。 这些地址可能是真实的，也可能是伪造的。 如果属实，我们很难用手段拒绝这些连接。 为什么这么说，是因为我们不能拒绝真实的ip为我们服务。 但是，如果这些ip是假的，带入TCP握手三次会发生什么呢？
假设有10000个伪造的ip地址向服务器发送了连接请求，服务器收到了。 对这些请求回复接收请求。 但是，由于这些ip地址是假的，所以找不到对应的ip地址，所以服务器的回复完全不起作用。 但是，为了保证TCP吵死了的可靠性，我们需要多次请求连接。 这样，无形中就会造成资源的浪费，达到洪水攻击。
如何对抗TCP三次握手的洪水攻击，实际上有很多防治方法。 可以从几个角度对这些手段进行分类。
建造壁垒的我们让另一台服务器处理TCP连接，只有实际握手三次的申请才会转移到实际服务的服务器上。
因为监视ip伪造不能握手3次，所以它们的连接都是半连接。 我们可以把半连接的请求放在一个队列里。 队列已满时，根据先进先出原则确定队列中的请求是否已经全部连接，如果是，则踢出队列。 如果仍然处于半连接状态，则可以将其视为恶意ip，释放这些连接并将其赶出队列。
我不知道这个方法是否可以从Java APP应用层代码实现，在查找资料时也没有说明这方面的代码，所以我暂时只知道这个方法需要从linux系统级别设置。
黑名单这个方法可能没什么效果。 因为ip是伪造的，所以屏蔽这些ip地址可能没有什么效果。 但是，也是一个解决方法。
如果超时并释放每个连接一段时间以上，无论出于什么原因，都会放弃直接连接。
设定重复响应的次数。 例如，我要保持可靠的连接，就必须继续发送确认请求的消息。 在这种情况下，可以设置重复确认的次数，超过此次数后即可断开连接。
对APP应用程序的洪水攻击这种攻击导致对APP应用程序的大量访问导致APP应用程序和服务器崩溃。 这什么也别说，只是请求无效的访问。 处理方法也比较简单：
创建队列，控制访问通信，超过的通信禁止访问。 好处是服务不会崩溃，缺点是可能阻止大量常规访问。 接口统计数据将在一定期间内多次访问视为恶意访问。 例如，如果每秒钟开始10次访问，则显然不是正常的快速出现，而是阻止ip。 防止刷3秒钟。 在3秒钟内，每个ip只能访问一次。 好处是平等对待每个ip。 缺点是，大量ip访问导致服务器无法正常运行会限制常规ip重新访问。 ——————————————————————
虽然还有其他红帆的攻击，但我并不是专业学习安全，对这些也一无所知，所以这里就不谈了。