端系统对ACK flood报文的处理
端系统在收到一个ACK报文时，如果目的端口未开放，那么端系统会直接向源IP发送RST报文，其交互过程大致如下图所示：
如果端系统的相关端口是对外开放的，那么其在收到ACK报文时，首先会检查这个ACK报文是否属于TCP连接表中的一个已有连接（这个过程会对端系统主机CPU资源造成一定的消耗），如果是的话，则正常处理，如果不属于任何一个已有连接，那么端系统会向源IP发送RST报文，交互过程如下图所示：
根据上面两个过程的分析，我们可推论ACK flood攻击对端系统性能的影响并不会非常大，至少跟SYN flood（端系统需要给每个SYN报文分配相应连接表空间，会消耗端系统内存资源）攻击相比，其攻击效果似乎难上台面。
中间系统对ACK flood报文的处理
路由器和防火墙的工作机制决定了路由器和防火墙在处理ACK报文的时候是完全不同的，我们分别将路由器与防火墙对ACK flood攻击的处理过程做简单描述。
路由器是网络层的设备，其主要功能是选路和转发，其选路的依据大部分都是基于网络层信息（目的IP、源IP等），因此路由器在处理ACK报文的时候，其并不关心它是不是ACK报文，它主要关心其目的地址，需要根据其目的地址来进行选路，如果ACK flood攻击的目的主机都是固定的，那么路由器其实只需要在收到第一个ACK flood攻击报文时，调用CPU资源实现选路和转发，后续的ACK flood攻击报文由于目的主机是固定的，其甚至不需要调用CPU资源，直接使用快速转发表即可实现对ACK flood报文的转发，路由器对ACK报文的处理过程大致如下：
防火墙对ACK报文的处理主要跟连接状态表有关，防火墙在收到ACK报文时，首先检查该ACK报文是否属于连接状态表中的已有连接，如果是，防火墙转发该ACK报文，如果未命中任何一个已有连接，防火墙会将该ACK报文丢弃，如下图所示：
ACK Flood攻击对系统的影响
由此来看，ACK flood攻击对端系统与中间系统的影响相对于其他攻击来说都不是非常明显，至于网上有相关资料讲其需要配合SYN flood攻击产生较好的攻击效果，原因为针对防护SYN flood攻击的一种技术 ——SYN cookie技术。
当某些启用SYN cookie技术进行SYN flood攻击防护的中间设备（专业抗DOS设备、防火墙、IPS、负载均衡、路由器等），在收到ACK报文时，需要计算cookie值，这个过程会消耗一部分中间设备的CPU资源，如果大量的ACK报文过来的话，很可能很快就会导致设备资源耗尽，达到拒绝服务的效果。
关于SYN cookie的工作机制，我在互联网上找到一篇文章，文章链接为：
http://blog.csdn.net/force_eagle/article/details/5348946，作者：droplet，现全文引用至此：
“
Cookie如何计算？
cookie = MD5(srcip,dstip,sport,dport)
端口是否需要考虑哪？没有端口的话，可以少一点计算。
Syn-cookie是无状态的，在Gateway上，不会保存任何与connection相关的东西，所以不会占用gateway的资源，缺点就是需要计算cookie，CPU占用会高一点。
如果不考虑端口的话，cookie是不是可以cache哪，如果cache了，就有查找的开销，并不一定比MD5的hash快多少。
在Syn-cookie之前，先要检查一下srcip是不是spoofing的，这里需要做一个反向的路由查找，看看是不是从错误的接口进来的，也可以确认一下源地址是否可达。
是不是也应该做一个源端口的检查哪？如果是0~1024的端口，就默认是非法的，因为这些端口在操作系统里面，一般是保留的，不会分配给应用程序。
Syn attack是否有signatue? 不同的syn flood工具，生成的工具包，应该有一定的模式，如果能够找到这个signature，就可以通过signature来直接drop这个syn，不用再做syn-cookie的检查了。
Syn-cookie会strip掉client和server的tcp option，对client，可疑在cookie里面带上tcp option，但是对server来说，就比较难办一点。strip掉tcp option，对connection的性能有影响。
对syn-flood的防范，目前还是threshold based，因为不能区分正常包和攻击包，但是如果能够定义攻击的signature，就可以做signature based的防范，这样可以更有效一点。”
在这里有个疑问，启用SYN cookie技术的中间设备在收到SYN报文的时候会建立cookie序列，在收到ACK报文的时候会计算cookie是否合法，那么是不是任何一个ACK报文都计算cookie值呢？从全文的描述来看，应该是在收到三次握手的最后一个ACK报文时才进行计算。
如果是对所有ACK报文都进行cookie值计算，这个中间设备对SYN cookie技术的实现是不是非常不科学呢？如果仅针对三次握手时的第三个ACK报文进行cookie值计算，那么中间设备应该直接丢弃随机伪造的ACK flood攻击报文。如果是丢弃随机伪造的ACK flood报文，那么对中间设备资源的消耗也是有限的。