常规洪水攻击的原理
- 在TCP第二次握手建立半连接时，此时就可以发动洪水攻击
- 就是大量的请求发起TCP连接，当第二次握手时，服务器会把这些请求放到半连接队列中，由于这些恶意攻击的客户端不会再确认第三次握手，就导致这些半连接无法被释放，服务器会一直等直到超时，此时半连接队列会被塞满，正常请求连接就无法被应答，这就是洪水攻击的方式
常规如何解决洪水攻击
- 开启syncookies方式，第一次握手时，服务器会根据(源地址，源端口，目的地址，目的端口等) 和一个随机数，计算出来一个哈希值(SHA1), 然后第二次握手会把这个生成的syncookies一并返回给客户端，客户端确认第三次握手时，会把这个syncookies再发送给服务端，服务端会校验该syncookie是否和之前的匹配， 如果匹配则建立TCP连接。
- 这种做法好处：当服务端没有收到 或 收到的syncookies不匹配时是不会建立TCP连接的。并且使用syncookies时，服务端不会去维护半连接队列，也就是不存在半连接状态，因为使用syncookies对比就无需半连接了，所以就避免了半连接队列被打满导致无法接收新的连接。
syncookies无法解决的场景
- 当发动大量DDOS攻击时，syncookies这种方式也会瘫痪，瘫痪原因是因为CPU要计算大量的syncookies，导致CPU被打死了。因为在计算syncookies时也是消耗CPU性能的，面临巨量的DDOS，CPU是扛不住的，此时只能增大带宽，用配置硬顶。
其他解决方案
- 增大半连接队列和全连接队列(海量攻击该方法基本无效)
- 减少SYN+ACK的重传次数(TCP是靠重传维持稳定连接的)，即收到大量syn请求的洪水攻击时，服务端接收不到回应会不断重试，直到最大次数，降低这个最大次数就能缓解一下
如何查询判断是否被洪水攻击了
1. 先进行流量查看:
sar -n DEV 1 -h然后只看eth0即可-->用rxkb/s 和 rxpck/s 这两列相除-->如果得出的包就50-60几字节，
那就说明是小包搞鬼，有可能遭受洪水攻击了，一般来说最大MTU = 14602. 如果发现是小包搞鬼，那就再进行网络抓包, 输入如下命令
tcpdump -i eth0 -n tcp port 803. 看有多少个[S], 这个表示发起TCP请求阶段，如果[S]过多，那就说明是洪水攻击，这是洪水攻击的特征4. 进一步确认是洪水攻击，查询半连接的池子大小，以及当前半连接数量
半连接总大小: cat /proc/sys/net/ipv4/tcp_max_syn_backlog
当前半连接数: ss -s 或 netstat -n -p | grep SYN_RECV | wc -1[S]: SYN，开始连接
[P]: PSH， 推送数据
[F]: FIN， 结束连接
[R]: RST, 重置连接
[.]: 没有Flag，可能是ACK 也可能是URG
