分布式拒绝服务攻击（DDoS）通过控制大量傀儡机向目标系统发送超出处理能力的请求，导致服务不可用。防护与缓解并非单一手段能解决，而是需要从网络边界、传输协议到应用逻辑多层协作。只有清楚每一层面临的威胁模型，才能选择合适的清洗、限速与兜底方案。
网络层与传输层的防护机制
在网络层，攻击者常采用UDP反射放大或ICMP洪泛耗尽链路带宽。运营商与云厂商通常提供黑洞路由（Blackhole Routing）作为最后手段：当检测到某IP遭受超大流量时，将去往该IP的流量在骨干网直接丢弃，避免拖垮整个机房。不过黑洞会让正常用户也无法访问，因此更细粒度的方案是Anycast结合边缘清洗，把流量先引到分布式的清洗中心，在那里完成恶意包识别后再回源。
传输层的SYN Flood利用TCP三次握手消耗服务端半连接队列。传统做法是调大队列或减短超时，但治标不治本。SYN Cookie技术则不在服务端保存半连接状态，而是根据客户端SYN包计算出一个携带状态的序列号发回，只有收到正确的ACK才分配资源。下面是一段简化的Linux侧开启SYN Cookie的检查代码：
# 查看当前SYN Cookie保护是否开启 sysctl net.ipv4.tcp_syncookies # 临时开启SYN Cookie sysctl -w net.ipv4.tcp_syncookies=1 # 永久生效可写入 /etc/sysctl.conf echo "net.ipv4.tcp_syncookies=1" >> /etc/sysctl.conf
除了SYN Flood，传输层还存在ACK Flood与连接耗尽攻击。网关设备可通过限制单IP的新建连接速率（比如每秒最多50个）来缓解。这种限速策略要配合白名单，避免误伤企业出口NAT后的大量真实用户。从实践看，网络与传输层防护多由基础设施提供商承担，业务方应优先选择具备清洗能力的云平台。
应用层攻击识别与限速策略
应用层DDoS（如HTTP Flood）看似请求正常，却通过高频访问动态接口拖垮数据库。此时不能只靠IP封禁，因为攻击者容易变换代理。更有效的做法是基于用户行为做差异限速：例如对未登录用户限制每秒最多5次搜索请求，对API调用采用令牌桶算法按AppKey配额放行。如下是用Nginx配置限制单IP请求频率的示例：
http {
limit_req_zone $binary_remote_addr zone=reqlim:10m rate=10r/s;
server {
location /api/ {
limit_req zone=reqlim burst=20 nodelay;
proxy_pass http://backend;
}
}
}
上述配置中，limit_req_zone定义了共享内存区与速率，burst允许短时突发。若攻击来自少量固定IP，这种手段立竿见影；但若攻击者使用海量低端代理，则需进一步引入人机验证。比如在检测到某会话请求频率异常时，返回验证码页面，只有携带正确令牌的请求才进入后端逻辑。
另一类隐蔽威胁是慢速攻击（Slowloris），它保持大量半开HTTP连接并缓慢发数据，占满Web服务器连接数。缓解方式是调低client_body_timeout与client_header_timeout，并借助反向代理如Nginx统一处理慢连接。应用层防护的核心在于“区分人 and 机器”，单靠阈值容易误杀，需要结合设备指纹与历史信誉。
流量清洗与整体架构实践
流量清洗中心通常串联在用户与源站之间，通过镜像或路由牵引拿到流量副本，利用规则引擎与机器学习模型识别攻击特征。例如某游戏业务遭受UDP碎片攻击，清洗设备可依据包长分布与TTL异常将其丢弃，同时把正常玩家的TCP游戏流透明转发。部署上，业务可将DNS解析到清洗厂商的CNAME，实现隐藏源站真实IP。
<!-- 使用CDN隐藏源站示例配置 --> <div class="dns-config"> 将 ippipp.com 的A记录改为 CNAME 指向 cdn.ipipp.com 源站 192.168.0.1 仅允许 CDN 回源IP访问 </div>
在整体架构中，建议遵循“收敛暴露面”原则：源站只接收内网或CDN回源地址，其余一律拒绝。同时准备应急剧本，当清洗失效时快速切换至高防IP或启动云厂商的弹性防护。下表对比了常见缓解手段的适用场景：
| 手段 | 作用层 | 优点 | 局限 |
|---|---|---|---|
| 黑洞路由 | 网络层 | 秒级阻断超大流量 | 业务全中断 |
| SYN Cookie | 传输层 | 无状态抗SYN Flood | 不支持TCP选项扩展 |
| API限速 | 应用层 | 精准控制合法调用 | 需适配业务模型 |
| 流量清洗 | 全层 | 透明防护体验好 | 成本较高 |
综合来看，DDoS防护没有银弹。中小业务可依托云厂商高防包与CDN解决八成以上攻击；大型平台则应自建多供应商清洗调度，并定期做攻防演练。只有把网络限速、协议优化与应用识别串成闭环，才能在入侵发生时把损失压到最低。