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