Syn_Flood攻擊原理
攻擊者首先偽造地址對服務器發起SYN請求（我可以建立連接嗎？），服務器就會回應一個ACK+SYN（可以+請確認）。而真實的IP會認為，我沒有發送請求，不作回應。服務器沒有收到回應，會重試3-5次並且等待一個SYN Time（一般30秒-2分鍾）后，丟棄這個連接。
如果攻擊者大量發送這種偽造源地址的SYN請求，服務器端將會消耗非常多的資源來處理這種半連接，保存遍歷會消耗非常多的CPU時間和內存，何況還要不斷對這個列表中的IP進行SYN+ACK的重試。TCP是可靠協議，這時就會重傳報文，默認重試次數為5次，重試的間隔時間從1s開始每次都番倍，分別為1s + 2s + 4s + 8s +16s = 31s,第5次發出后還要等32s才知道第5次也超時了，所以一共是31 + 32 = 63s。
也就是說一共假的syn報文，會占用TCP准備隊列63s之久，而半連接隊列默認為1024，系統默認不同，可 cat /proc/sys/net/ipv4/tcp_max_syn_backlog c查看。也就是說在沒有任何防護的情況下，每秒發送200個偽造syn包，就足夠撐爆半連接隊列，從而使真正的連接無法建立，無法響應正常請求。 最后的結果是服務器無暇理睬正常的連接請求—拒絕服務。
Syn_Flood防御
防御手段：
1）可以對SYN包進行監視，如果發現某個IP發送了大量SYN即將該IP列入黑名單。
2）因為消耗服務器資源主要是因為當SYN數據報文一到達，系統立即分配TCB，從而占用了資源。而SYN Flood由於很難建立起正常連接，因此，當正常連接建立起來后再分配TCB則可以有效地減輕服務器資源的消耗。常見的方法是使用Syn Cache和Syn Cookie技術。
Syn Cache技術：
這種技術是在收到SYN數據報文時不急於去分配TCB，而是先回應一個SYN ACK報文，並在一個專用HASH表（Cache）中保存這種半開連接信息，直到收到正確的回應ACK報文再分配TCB。在FreeBSD系統中這種Cache每個半開連接只需使用160字節，遠小於TCB所需的736個字節。在發送的SYN ACK中需要使用一個己方的Sequence Number，這個數字不能被對方猜到，否則對於某些稍微智能一點的Syn Flood攻擊軟件來說，它們在發送Syn報文后會發送一個ACK報文，如果己方的Sequence Number被對方猜測到，則會被其建立起真正的連接。因此一般采用一些加密算法生成難於預測的Sequence Number。
Syn Cookie技術：
對於SYN攻擊，Syn Cache雖然不分配TCB，但是為了判斷后續對方發來的ACK報文中的Sequence Number的正確性，還是需要使用一些空間去保存己方生成的Sequence Number等信息，也造成了一些資源的浪費。
Syn Cookie技術則完全不使用任何存儲資源，這種方法比較巧妙，它使用一種特殊的算法生成Sequence Number，這種算法考慮到了對方的IP、端口、己方IP、端口的固定信息，以及對方無法知道而己方比較固定的一些信息，如MSS、時間等，在收到對方的ACK報文后，重新計算一遍，看其是否與對方回應報文中的（Sequence Number-1）相同，從而決定是否分配TCB資源。
3）防火牆，Syn Cache技術和Syn Cookie技術總的來說是一種主機保護技術，需要系統的TCP/IP協議棧的支持，而目前並非所有的操作系統支持這些技術。因此很多防火牆中都提供一種SYN代理的功能，其主要原理是對試圖穿越的SYN請求進行驗證后才放行，防火牆在確認了連接的有效性后，才向內部的服務器（Listener）發起SYN請求，所有的無效連接均無法到達內部的服務器。而防火牆采用的驗證連接有效性的方法則可以是Syn Cookie或Syn Flood等其他技術。