本篇文章在于浅尝辄止的分析TCP的SYNCookie机制.
一个连接的建立需要进行TCP三次握手，如下图所示
简单来说，服务端收到客户端的SYN包之后，将连接放到半连接队列中，当服务端再次收到客户端的ACK包之后，会将连接从半连接队列移到全连接队列中，这样服务端的程序调用accept()方法的时候，就可以从全连接队列中获取到连接了.
这里要提到SYN Flood，如果一个客户端在短时间内发送大量的SYN包给服务端，而且不发送ACK包给服务端，这样会导致服务端的半连接队列很快就被填满了，间接导致其他客户端无法与服务端完成三次握手.
接下来，通过实验模拟这样的场景，以及如何解决它.
【实验】
一台ubuntu-20.04机器作为服务端(IP=192.168.0.103)
一台Kali机器作为客户端(IP=192.168.0.102)
首先，需要修改服务端的一个配置文件(/etc/sysctl.conf)，修改的文件内容如下
说明：如果sysctl.conf文件中没有对应的属性值则需要手动添加
属性值的含义如下 net.ipv4.tcp_syncookies = 0 表示不开启SYNCookie机制 net.ipv4.tcp_max_syn_backlog = 5 设置半连接队列大小 net.core.somaxconn = 5 设置全连接队列大小
说明：这里只是将半连接队列和全连接队列设置的小了一些, 除此之外没有其他特殊原因
接下来，在服务端，使用Python语言搭建一个简单的Server程序，代码如下
代码语言：javascript复制import socket
server=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
server.bind(('192.168.0.103',8082))
server.listen(5)
程序监听在8082端口
然后在客户端机器上，通过netwox命令，向服务端持续发送SYN包，模拟SYN Flood
说明：通过 apt install netwox 安装netwox命令
以上命令会向192.168.0.103机器的8082端口持续发送SYN包
接下来， 我们看一下服务端的一些现象
在服务端执行 netstat -s | grep LISTEN 命令，可以查看半连接队列的情况
可以发现，被丢弃的SYN包的数量一直在增长. 因为客户端一直在向服务端发送SYN包，当半连接队列满了之后，后面的SYN包只能被丢弃.
在服务端执行 sudo tcpdump -nn -i enp0s8 port 8082 命令，如下图
说明：192.168.0.103属于enp0s8网卡
可以发现， 客户端一直发送SYN包给服务端
而且通过查看系统日志，比如使用 dmesg 命令或者查看 /var/log/kern.log 文件，能够发现如下一行信息
TCP: request_sock_TCP: Possible SYN flooding on port 8082. Dropping request. 大概意思是，在8082端口可能发生了SYN Flood攻击，请求被丢弃了.
假如我们有另外一个客户端，向服务端正常的发送三次握手. 比如执行 telnet 192.168.0.103 8082 命令
它会一直处于连接中，直到超时失败.
【总结】 由于半连接队列满了，导致客户端无法与服务端建立连接
针对上面的情况，TCP给出了一个解决思路. 修改服务端的配置文件(/etc/sysctl.conf)，将 net.ipv4.tcp_syncookies = 1 ，表示开启SYNCookie机制， 其他的无需修改， 继续上面的实验.
通过 netstat -s | grep LISTEN 命令，可以发现SYN包没有再被丢弃 (被丢弃的数量没有发生变化)
再次通过dmesg命令查看系统日志，发现如下一行信息
TCP: request_sock_TCP: Possible SYN flooding on port 8082. Sending cookies.大概意思是，在8082端口可能发生了SYN Flood攻击，发送了cookies.
是因为在服务端开启了SYNCookie机制，即便半连接队列满了，通过Cookie机制，依然可以保证让客户端连接到服务端.
这个时候通过另外一个客户端执行 telnet 192.168.0.103 8082 命令，是可以正常连接到服务端的，如下图
【总结】开启TCP的SYN Cookie机制，即便半连接队列满了，客户端也可以成功与服务端建立连接
