要明白这种攻击的基本原理，还是要从TCP连线建立的过程开始说起：

大家都知道，TCP与UDP不同，它是基于连线的，也就是说：为了在服务端和客户端之间传送TCP数据，必须先建立一个虚拟链路，也就是TCP连线，建立TCP连线的标準过程是这样的：

首先，请求端（客户端）传送一个包含SYN标誌的TCP报文，SYN即同步（Synchronize），同步报文会指明客户端使用的连线埠以及TCP连线的初始序号；

第二步，伺服器在收到客户端的SYN报文后，将返回一个SYN+ACK的报文，表示客户端的请求被接受，同时TCP序号被加一，ACK即确认（Acknowledgment）。

第三步，客户端也返回一个确认报文ACK给伺服器端，同样TCP序列号被加一，到此一个TCP连线完成。

以上的连线过程在TCP协定中被称为三次握手（Three-way Handshake）。

问题就出在TCP连线的三次握手中，假设一个用户向伺服器传送了SYN报文后突然当机或掉线，那幺伺服器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的（第三次握手无法完成），这种情况下伺服器端一般会重试（再次传送SYN+ACK给客户端）并等待一段时间后丢弃这个未完成的连线，这段时间的长度我们称为SYN Timeout，一般来说这个时间是分钟的数量级（大约为30秒-2分钟）；一个用户出现异常导致伺服器的一个执行绪等待1分钟并不是什幺很大的问题，但如果有一个恶意的攻击者大量模拟这种情况，伺服器端将为了维护一个非常大的半连线列表而消耗非常多的资源----数以万计的半连线，即使是简单的保存并遍历也会消耗非常多的CPU时间和记忆体，何况还要不断对这个列表中的IP进行SYN+ACK的重试。实际上如果伺服器的TCP/IP栈不够强大，最后的结果往往是堆叠溢出崩溃---即使伺服器端的系统足够强大，伺服器端也将忙于处理攻击者伪造的TCP连线请求而无暇理睬客户的正常请求（毕竟客户端的正常请求比率非常之小），此时从正常客户的角度看来，伺服器失去回响，这种情况我们称作：伺服器端受到了SYN Flood攻击（SYN洪水攻击）。

从防御角度来说，有几种简单的解决方法：

第一种是缩短SYN Timeout时间，

由于SYN Flood攻击的效果取决于伺服器上保持的SYN半连线数，这个值=SYN攻击的频度 x SYN Timeout，所以通过缩短从接收到SYN报文到确定这个报文无效并丢弃该连线的时间，例如设定为20秒以下（过低的SYN Timeout设定可能会影响客户的正常访问），可以成倍的降低伺服器的负荷。

第二种方法是设定SYN Cookie，

就是给每一个请求连线的IP位址分配一个Cookie，如果短时间内连续受到某个IP的重複SYN报文，就认定是受到了攻击，以后从这个IP位址来的包会被丢弃。 可是上述的两种方法只能对付比较原始的SYN Flood攻击，缩短SYN Timeout时间仅在对方攻击频度不高的情况下生效，SYN Cookie更依赖于对方使用真实的IP位址，如果攻击者以数万/秒的速度传送SYN报文，同时利用随机改写IP报文中的源地址，以上的方法将毫无用武之地。例如SOCK_RAW返回的套接字通过适当的设定可以自己完全控制IP头的内容从而实现IP欺骗。

SYN flood可以用DCN防火墙来拦截，在DCN防火墙受到攻击的时候会提示有IP试图连线你的连线埠等报警，这是受到了SYN FLOOD攻击的徵兆，不是什幺抓肉鸡，而是被SYN攻击了，正常情况下SYNFLOOD是攻击不进去的，所以儘管放心