Web 安全之延迟攻击（Delay Attack）详解
你有没有遇到过这种情况？
一个网站，流量不大、CPU不爆、带宽没满，可就是打不开。
刷新一次，卡10秒；再刷一次，还是卡。
你查监控，一切正常；你问运维，查不出问题。
最后只能重启服务，暂时恢复——但没过两天，又瘫了。
这不是玄学，也不是硬件老化。
这很可能是一场精心策划的**“延迟攻击”（Delay Attack）**——一种不靠“洪流”，而靠“慢性中毒”来摧毁系统的高级网络攻击。
延迟攻不像传统DDoS那样声势浩大，而是像慢性病一样，悄无声息地耗尽你的资源，让你的系统“活不下去”。
“慢”才是最可怕的攻击
我们通常以为，网络攻击就是“快”：
- 流量越大越好，
- 速度越猛越强，
- 一秒打爆才算赢。
但真正的高手，往往反其道而行之——他们用“慢”来攻击。
这类攻击统称为 延迟攻击（Delay Attack） 或 低速率攻击（Low-rate Attack），核心思路是：
不追求瞬间爆发，而是通过长时间、低强度的“合法行为”，一点点蚕食系统资源，最终让服务彻底瘫痪。
它不靠“砸门”，而是“赖着不走”。
它不伪造数据，而是“装作很忙”。
它不触发警报，因为一切看起来都“很正常”。
正因如此，这种攻击极难被发现，也极难防御。
最经典的“慢速攻击”：Slowloris 和 R.U.D.Y.
这类攻击的目标很明确：Web服务器的应用层连接池。
我们先来理解一个关键机制：
Web服务器（如 Apache、Nginx）为了同时处理多个用户请求，会为每个连接分配一个“线程”或“工作进程”。这个数量是有限的，一旦所有线程都被占用，新的用户就无法连接。
攻击者的策略就是：让每一个连接都“半死不活”，长期霸占一个线程。
1. Slowloris：假装“网速很差”的请求者
想象你去餐厅点餐，服务员过来问你要吃什么。
你说：“我要点……”，然后停住。
服务员等你继续说，但你每隔30秒才说一个字：“……红……烧……肉……”
服务员不能走，因为他以为你还在思考。
结果你一个人占着他，其他客人进不来。
这就是 Slowloris 攻击。
- 攻击者与服务器建立 HTTP 连接；
- 开始发送请求头（如
User-Agent、Accept），但只发一部分； - 每隔几十秒才发几个字节，永远不发完；
- 服务器认为“客户端网络差”，于是保持连接等待；
- 成百上千个这样的“慢吞吞”连接，就把所有线程占满了。
特点：
- 流量极小，可能只有几百B/s；
- 请求完全合法，防火墙看不出异常；
- 一次攻击，几十台机器就能打瘫一个中型网站。
2. R.U.D.Y.：我“要发大文件”，但“一个字一个字发”
R.U.D.Y.（R-U-Dead-Yet?）更阴险，专挑需要提交数据的页面下手，比如登录、搜索、上传等。
攻击流程如下：
- 攻击者发送一个 POST 请求，声明：“我要发5MB数据”（
Content-Length: 5000000）； - 服务器信以为真，分配缓冲区，准备接收；
- 但攻击者每次只发一个字节，间隔几分钟；
- 服务器只能干等，连接一直不释放。
这就像你去快递站寄包裹，说有100斤东西要发，结果你每次只拿一粒纽扣出来……
工作人员只能等着，其他客户全被堵在外面。
3. 慢速读取攻击：我“收到了”，但“我慢慢看”
还有一种反向操作：慢速读取（Slow Reading）。
攻击者发一个正常请求，比如“下载一个10MB的日志文件”。
服务器处理完，开始发送数据。
但攻击者故意“读得很慢”——通过TCP协议的“接收窗口”机制，告诉服务器：“我的缓冲区满了，别发了”。
服务器只好暂停发送，但连接不能断，数据还得留在内存里。
如果攻击者发起成千上万个这样的连接，服务器的内存和连接资源就会被慢慢耗尽。
连密码都能被“时间”破解？时序攻击揭秘
你可能更没想到：连加密系统，也可能被“时间”攻破。
这就是密码学中的时序攻击（Timing Attack）——一种典型的“侧信道攻击”。
它是怎么做到的？
假设一个系统用密钥验证你的登录。
代码逻辑可能是：
if user_key == secret_key:allow_access()
但计算机执行这个比较时，是从左到右逐位比对的。
如果第一位就错了，很快返回；
如果前9位都对，只错最后一位，就要比对很久。
攻击者通过精确测量响应时间，就能猜出：
- 哪些密钥位“更接近正确”；
- 然后不断调整输入，逐步逼近真实密钥。
这就像开保险箱：
你听“咔哒”声的长短，就能判断哪些数字“转得更深”。
虽然每次差异只有微秒级，但通过大量统计分析，攻击者真的能还原出密钥。
防御之道：恒定时间算法
解决方案是：让所有输入的执行时间都一样。
无论密钥对错，都走完所有计算步骤，不提前退出。
这叫“恒定时间编程”（Constant-time Programming），是现代密码库（如 Libsodium）的基本要求。
如何防御这些“慢动作”攻击？
传统防火墙和DDoS设备，靠“流量阈值”报警。
但慢速攻击的流量可能比正常用户还小，根本触发不了警报。
所以，防御必须更精细、更智能。
1. 调整服务器配置：别让连接“赖太久”
-
设置连接超时：
Apache 的RequestReadTimeout，Nginx 的client_header_timeout，超过时间就断开。 -
限制单IP连接数：
防止一个IP开几千个慢连接。 -
设置最小传输速率：
要求客户端每秒至少收/发一定数据，否则视为异常。
2. 用反向代理做“缓冲层”
把 Nginx 或 CDN 放在前面，作为“第一道防线”。
它先完整接收客户端请求，确认没问题后，再以“高速、短连接”的方式转发给后端服务器。
这样，后端永远只处理“完整请求”，不受慢速连接影响。
3. 部署WAF（Web应用防火墙）
现代WAF不仅能防SQL注入，还能做行为分析：
- 监控连接的数据传输速率；
- 识别“长时间低速发送”的异常模式；
- 自动封禁可疑 IP。
为什么这类攻击越来越重要？
因为：
- 传统 DDoS 越来越容易被识别和清洗；
- CDN 和云防护让“流量压制”成本极高；
- 攻击者开始转向“ smarter, not harder” 的策略。
慢速攻击正是这种“以巧破力”的典型代表。
不需要海量僵尸网络，
不需要TB级带宽，
甚至不需要高超的漏洞利用技术。
只需要：理解系统逻辑，然后“装傻”。
安全，是一场与“异常行为”的博弈
延迟攻击告诉我们：
最大的威胁，往往不是“异常的流量”，而是“正常的异常行为”。
一个请求，语法正确、路径合法、参数合规，
但它就是“太慢了”。
在网络安全的世界里，“慢”不该被忽视。
它可能是攻击的伪装，也可能是系统崩溃的前兆。
作为开发者、运维、安全人员，我们不仅要关注“发生了什么”，更要关注“它是怎么发生的”——
时间、节奏、行为模式，这些细节，才是未来防御的关键。
毕竟，真正的攻击，从来不会按常理出牌。
作者注：本文基于实际攻防案例与安全研究整理。技术在变，攻击在进化，防御也必须与时俱进。保持警惕，始于对“异常”的敏感。