ACK FLOOD對比主機以及防火牆在接收到ACK報文和SYN報文時所做動作的複雜程度，顯然ACK報文帶來的負載要小得多。所以在實際環境中，只有當攻擊程式每秒鐘傳送ACK報文的速率達到一定的程度，才能使主機和防火牆的負載有大的變化。當發包速率很大的時候，主機作業系統將耗費大量的精力接收報文、判斷狀態，同時要主動回應RST報文，正常的數據包就可能無法得到及時的處理。這時候客戶端（以IE為例）的表現就是訪問頁面反應很慢，丟包率較高。但是狀態檢測的防火牆通過判斷ACK報文的狀態是否合法，藉助其強大的硬體能力可以較為有效的過濾攻擊報文。當然如果攻擊流量非常大（特別是千兆線路上，我們曾經觀察到200~300Mbps左右的ACKFlood），由於需要維護很大的連線狀態表同時要檢查數量巨大的ACK報文的狀態，防火牆也會不堪重負導致全網癱瘓。
目前ACKFlood並沒有成為攻擊的主流，而通常是與其他攻擊方式組合在一起使用。回顧前面描述的SYNCookie算法，其核心思想是主動回應SYN/ACK包，然後校驗第3次握手的ACK報文是否合法，目前大多數實現中校驗ACK報文的合法性都涉及到較為複雜的算法。當Synflood與ACKFlood一起發生的時候，主機和防火牆將耗費大量的精力來計算ACK報文是否合法以致不堪重負。
從以上的描述可以看到ACKFlood具有"單包攻擊"的特點。但我們仍然可以從TCP/IP協定的特性以及數據傳輸特性中得到一定的統計規律。在現實世界中，正常數據傳輸的兩個方向（客戶端à伺服器，伺服器à客戶端）上的報文數量基本上是均衡的，同時數據報文的內容是較為隨機的。因此，當數據傳輸兩個方向上的報文數量發生傾斜的時候，基本上可以判定發生了攻擊。並且在大多數情況下，由於為了追求發包的速率，攻擊報文的內容是較為固定的。因此，防護設備可以通過學習攻擊報文的特徵，當某個特徵在一段時間的採樣內大量重複出現，那么基本上可以判定符合此特徵的數據報文為攻擊報文。當然，統計的方法不可避免會帶來誤判，因此將統計方法與連線狀態檢測結合起來是比較合理的做法。
