继续上回：我们已经确认了全连接队列的长度计算，接下来继续寻找半连接队列长度。
试着慢慢减小tcp_max_syn_backlog的值，但还是看不到半连接状态数量的变化。
实在没什么思路，只能Google之，搜出来的基本都是关于SYN Flood的文章，难道没同学关注过半连接队列的长度吗？ read more »
最近在学习TCP方面的基础知识，对于古老的SYN Flood也有了更多认识。SYN Flood利用的是TCP协议缺陷，发送大量伪造的TCP连接请求，从而使得被攻击方资源耗尽（CPU满负荷或内存不足）的攻击方式。
SYN Flood的原理简单，实现也不复杂，而且网上有许多现成的程序。
我在两台虚拟机上(虚拟机C攻击虚拟机S)做测试，S上跑了apache监听80端口，用C对S的80端口发送SYN Flood，在无任何防护的情况下攻击效果显著。用netstat可以看见80端口存在大量的半连接状态(SYN_RECV)，用tcpdump抓包可以看见大量伪造IP发来的SYN连接，S也不断回复SYN+ACK给对方，可惜对方并不存在(如果存在则S会收到RST这样就失去效果了)，所以会超时重传。
这个时候如果有正常客户A请求S的80端口，它的SYN包就被S丢弃了，因为半连接队列已经满了，达到攻击目的。 read more »
