凌晨三点，常用处置某电商平台的攻击网关告警狂响。流量曲线像被掰断的流量温度计，瞬间从每秒2Gbps飙到87Gbps。常用处置运维老张盯着屏幕骂了句脏话，攻击然后打开路由器抓包——源IP全是流量伪造的，SYN包占九成。常用处置这就是攻击最典型的SYN Flood，攻击者用僵尸网络打满你的流量并发连接表，让正常用户连握手都完不成。常用处置

对付这种流量，攻击第一反应不是流量硬扛，是常用处置分流。机房上游一般都有黑洞路由，攻击运营商那边能一键把攻击流量引到null接口。流量代价是IP直接断网，但总比整个机柜瘫了强。去年有个游戏公司被打了三天，CTO舍不得封IP，结果机房整体宕机四小时，损失比封IP大十倍。记住，黑洞是保命手段，不是首选方案。

要是攻击没超过带宽上限，就用清洗设备。主流做法是部署流量牵引，把可疑流量引到专用清洗集群，用指纹识别和行为分析筛掉恶意包，再把干净流量回注到源站。这里有个坑：清洗设备本身可能成为瓶颈。我见过某云厂商的清洗节点被打到CPU满载，结果正常请求也跟着超时。所以清洗策略得分层——先粗粒度过滤（比如丢弃异常TCP标志位组合），再细粒度验证（比如挑战应答），别一上来就深度包检测。

应用层CC攻击更阴险。它不占满带宽，就是模拟真实用户疯狂请求某个接口。比如抢票软件被刷，每秒几万次查询打到数据库，CPU直接飙红。这时候防火墙的静态规则没用，得靠动态限频。Nginx里用limit_req_zone按IP限速，但攻击者会换IP。更有效的是按会话特征限——比如统计每个UA（User-Agent）的请求频率，或者检查Cookie是否在短时间内重复出现。有个电商平台遇到过用随机UA的CC攻击，最后靠分析请求间隔的熵值才拦住——正常用户访问有随机性，攻击流量的间隔规律得像节拍器。

抓包分析是基本功。用tcpdump抓10秒样本，看流量构成。如果是UDP Flood，直接丢UDP包（除非业务必须用UDP）。如果是DNS Query Flood，就限源IP的QPS（每秒查询数）。但别只盯着攻击特征，得留个心眼——有些攻击会伪装成正常业务。比如HTTP Flood里混着大量合法的GET /search，你误杀的话，误伤率能到40%。这时候就得靠业务逻辑判断，比如检查请求是否带登录态，或者是否在短时间内请求了超过20个不同的搜索词。

长期防御得靠架构调整。把静态资源扔CDN，源站只暴露API接口，再加一层WAF（Web应用防火墙）。但WAF不是万能的，它自己也可能被绕过。更实在的做法是弹性扩容——攻击来了就临时加服务器扛着，等流量过去再缩容。云上这么做成本不算高，但得提前写好自动化脚本。我认识一个运维，他写了个脚本，检测到流量超过阈值就自动调用云API开20台临时实例，把流量分散掉，攻击结束后自动释放。这套东西在双十一大促时也派上了用场，算是歪打正着。

最后说个反直觉的案例。有个小网站被打了，攻击流量只有200Mbps，但网站就是打不开。排查发现是源站服务器的连接数被占满，而攻击包本身很小，清洗设备把流量过滤后，回注的干净流量还是把服务器连接池挤爆了。后来加了层Redis缓存，把数据库查询压力扛住，问题才解决。所以，处理DDOS不能只盯着流量大小，得看攻击对系统哪个环节造成了压力——有时候瓶颈在CPU，有时候在数据库连接，有时候在日志写入磁盘的I/O。

处置完别急着收工。保存攻击样本，分析攻击源端口和协议特征，更新防火墙规则。把这次的流量特征写进IDS（入侵检测系统）规则库，下次遇到类似的能自动拦截。别忘了写复盘报告，但别写那种“我们加强了监控、优化了流程”的空话，要写具体数据：攻击峰值多少，清洗掉了百分之几，误伤了多少正常请求，业务恢复用了多长时间。这些数字，下次再被攻击时就是你的底牌。