慢速攻击如何把连接保持时间拉长到极限？，慢速攻击连接保持时间极限手法

慢速攻击延长连接的核心逻辑，是把TCP层和应用层的超时阈值全部利用到极限，在Linux默认配置下，单条连接通过合理控制发包节奏可以存活接近7200秒（2小时），而实际攻击中真正卡住服务器的并不是连接本身，而是服务器为这条连接分配的资源一直没有被释放。

慢速攻击不是洪水猛兽式的暴力碾压,它的特点是慢，是拖着服务器不让它下班，这类攻击之所以让很多站长头疼，核心原因在于服务器默认把连接的生命周期设计得足够宽容，攻击者只是把这个宽容用到了极限。

服务器慢速攻击保持连接时间太长怎么办：先认清超时机制的三层博弈

要理解连接时间为什么能被拉长到极限,就要分开看三套时钟，第一套是系统内核的TCP栈超时，第二套是Web服务器的应用层超时，第三套是攻击者的发包节奏，三者的时间阈值互相独立，实际连接寿命取决于哪套时钟率先触发。

在绝大多数Linux服务器上,TCP层的keepalive探测包默认需要等待7200秒即2小时才启动第一次探测，也就是说，只要连接双方不发RST、不主动FIN，内核层面不会去打扰这条连接，这一步就给慢速攻击打开了大半扇门。

应用层方面,Apache和Nginx的默认超时通常是60秒左右，攻击者要做的，就是在60秒的窗口内不断“喂”一点数据给服务器，让应用层认为连接还在活跃使用，这里的关键是喂的分量要小，节奏要稳，每隔50秒发送1个字节的HTTP头字段，服务器就会重置超时计时器。

行业共识认为,完整的慢速攻击生命周期包含三个阶段：建立连接、半开状态维持、资源消耗爬坡，这三个阶段里，连接时间拉长主要发生在第二阶段。

慢速攻击如何防御：把攻击者的计时器拆解到参数级别

防御慢速攻击的前提是知道攻击者到底在用什么手法拖长时间,以下从三种主流变体逐一拆解。

慢速请求头攻击：伪装的“未完待续”

攻击者建立TCP连接后,正常发送HTTP请求行，然后就开始逐字或逐行发送请求头字段，每条头字段间隔几十秒，频率极低，流量极小，服务器端看到的只是“请求尚未完成”，只能耐心等待。

Apache的Timeout指令默认控制接收请求头和响应体的总时间，如果服务器设置了过大的超时值，比如120秒或300秒，攻击者可以把每段头字段的间隔设在略小于这个值的水平，持续数小时不断开连接。

Nginx的情况类似,client_header_timeout决定读取请求头超时，默认60秒，但很多运维为了提高大文件上传稳定性，会把client_body_timeout调大到300秒甚至更长，这就给慢速请求体攻击留下了可乘之机。

慢速请求体攻击：上传速度的演技派

攻击者发送一个带Content-Length的POST请求，声明要上传一个庞大的请求体，然后以极慢的速度发送body部分，服务器需要接收完整的请求体才能继续处理，于是资源被长时间占用。

这里有一个容易忽视的细节。Content-Length声明得越大，服务器预期等待的时间就越长，攻击者通常会声明一个几GB到几十GB的请求体，而实际发送速率控制在每秒几十字节，按照这个速率，这个请求永远也发不完。

慢速读取攻击：响应发不出去的困局

攻击者建立连接、提出正常请求、也有完整的HTTP头，但TCP接收窗口被设置为极小值，比如1字节，服务器尝试把响应数据推送出去，却发现客户端“吞不下”数据，响应卡在发送队列里，占用着worker内存和连接槽位。

服务器慢速攻击防护配置的难点就在这里,三种变体都能把单条连接的时间维度拉满，但表现出来的特征完全不同，有的卡在请求阶段，有的卡在响应阶段。

拉长时间极限的三种典型手法与参数对照

以下表格汇总了不同Web服务器在处理慢速攻击时涉及的临界参数和默认值,这是做防护时的参数调整基础：

这张表揭示了一个容易被忽略的事实,许多运维人员以为调大超时参数是自己服务器的自由配置，但在攻击场景下，这些调大的数值全部变成攻击者手中的筹码。

把时间压回去：连接超时参数与内核层面的调整实操

慢速攻击的核心是时间对抗,防御策略相应地聚焦在压缩时间和限制并发连接数上。

第一步：压缩应用层超时窗口

Nginx中,建议将超时时间设定为HTTP协议允许的最小安全值：

http {
    client_header_timeout 10s;
    client_body_timeout 10s;
    send_timeout 10s;
    keepalive_timeout 10s;
}

上述配置意味着,无论请求头、请求体还是响应发送，一旦在10秒内没有数据传输，连接就会被断开，这比默认60秒缩小了6倍，但同时需要留意，超时设置需要匹配正常用户的网络环境。

第二步：限制单IP并发连接数

单纯压缩时间还不够,超时时间被压缩后，攻击者会加大并发连接数来弥补单连接的吞吐损失，因此需要限制单IP并发连接。

使用Nginx的limit_conn模块：

http {
    limit_conn_zone $binary_remote_addr zone=perip:10m;
    server {
        limit_conn perip 20;
    }
}

使用iptables做更底层的连接数限制：

iptables -I INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 50 -j REJECT --reject-with tcp-reset

第三步：修改内核TCP参数

对于慢速读取攻击的极小窗口问题,通过重新设置TCP栈参数来改善：

sysctl -w net.ipv4.tcp_keepalive_time=600
sysctl -w net.ipv4.tcp_fin_timeout=5
sysctl -w net.core.rmem_max=8388608
sysctl -w net.core.wmem_max=8388608

其中tcp_keepalive_time从7200秒降到600秒，让内核主动探测僵死连接。tcp_fin_timeout缩短了TIME_WAIT状态的时间，加快连接回收。

第四步：等保合规场景下的额外加固

在等保三级合规要求下,系统通常需要部署入侵检测设备，这类设备可以做到行为分析，识别出“单IP周期性发包且包间隔稳定在几十秒”的模式，直接与超时缩短策略联动防御。

考虑到安全设备的费用不低,相比高防IP动辄数千元的月费，调整服务器自身的超时参数和连接数限制，是预算有限的中小站点最优先考虑的方案。

慢速攻击怎么处理：真实场景下的连接状态观察与判断

在一台实际被攻击的服务器上,通过ss -ant命令看到的典型异常状态是大量ESTABLISHED连接长时间一动不动：

ss -ant | grep :80 | awk '{print $1}' | sort | uniq -c | sort -nr

正常情况下,ESTABLISHED连接数量平稳，且来源IP分布分散，慢速攻击下，会出现大量来自同一IP段或同一IP的连接，连接建立时间超过数分钟却没有完成HTTP交互，用ss -ant -o还能看到这些连接的计时器：

ss -ant -o state established '( sport = :80 )'

输出中的timer:(keepalive,2.5s)或timer:(on,5s)表示该连接的活跃计时器状态，攻击者的连接会持续刷新计时器，但永远不进入数据传输完成阶段。

结合Web服务器日志可以进一步确认,慢速攻击的连接在Nginx日志中通常表现为request_time极长的条目，或者压根没有对应的access log条目因为请求头还没有完整到达。

常见问题排查与结论

慢速攻击会把连接保持时间拉长到多长？

理论上,如果服务器所有超时参数未做限制，配合TCP内核默认值，单条连接可存活接近7200秒，实际攻击中，攻击者并不追求单条连接无限存活，而是追求足够多的连接同时存活，以占满服务器的最大并发限制。

连接超时调短会不会误伤正常用户？

会带来一定影响,正常用户在弱网环境下载大文件时，如果send_timeout设置过于激进，会出现下载中断，建议采用分级策略：对静态资源请求使用较短超时，对上传和下载接口保留相对宽松的超时，同时通过CDN前置转发过滤异常连接。

慢速攻击防护配置需要同时调整哪些层次？

系统层、应用层、网络层三处联动，系统层调小tcp_keepalive_time和应用层超时时间，网络层限制单IP连接数，应用层调小请求头和请求体超时，这三处配置缺一不可，单靠缩短某一层的超时时间，攻击者会迅速转移到其他层的宽松窗口。

慢速攻击的本质是利用服务器对连接的宽容来消耗资源,防御的核心逻辑，是把这份宽容压缩到不影响正常用户的最小范围，并配合同步的连接数限制兜底，把这个时间账算清楚，慢速攻击的威胁就能下降到可管理的水平。