流量基线的本质不是“抓一个平均值”，而是建立一套能够区分“正常波动”和“攻击异常”的动态判定体系。很多防护失效的案例，问题都出在基线构建阶段：要么阈值定得太死，正常业务高峰被误杀；要么定得太松，攻击流量混在正常流量里被放行。构建DDoS防护业务流量基线，核心要解决三个问题：采集哪些数据、如何计算正常区间、如何让基线随业务变化自动修正。
先确定基线的数据维度，而不是急着算数
有效的流量基线不能只看“每秒多少请求”或“每秒多少兆带宽”这种单一指标。至少需要从四个维度同时建模：网络层流量特征、传输层连接特征、应用层请求特征、业务行为特征。网络层关注入向带宽、包速率、协议分布（TCP/UDP/ICMP/其他）、分片比例、源IP熵值。传输层关注新建连接速率、并发连接数、SYN包与ACK包比例、RST包比例、连接平均持续时间。应用层关注HTTP/HTTPS请求速率、请求方法分布、URL路径分布、响应码分布、平均响应时长。业务行为特征则要结合具体业务，比如登录接口的请求频率、验证码触发率、API调用序列的时序关系、单个用户会话内的操作间隔。
只监控带宽和包速率，遇到CC攻击或慢速连接耗尽型攻击时基本无效。攻击者完全可以用很小的带宽、很低的包速率，通过大量慢速连接或精准打击重接口把服务器拖垮。反过来，某些大流量UDP反射攻击虽然带宽巨大，但如果业务根本不开放对应UDP端口，边界设备直接丢弃即可，实际威胁并没有带宽数字看起来那么严重。所以基线的维度必须和业务暴露面、协议栈、应用逻辑对应起来。
采集方式和数据源要能支撑多维计算
数据采集建议分三层进行。第一层在网络边界设备上做，通过NetFlow、sFlow、IPFIX或者镜像流量分析，拿到网络层和传输层的聚合统计。第二层在负载均衡或反向代理层做，从访问日志和连接表中提取应用层请求特征。第三层在应用服务内部做，通过埋点或中间件统计业务逻辑层面的调用频率和响应时间。三层数据的时间戳必须对齐，否则无法做关联分析。
采样周期不能一刀切。网络层数据建议用10秒到30秒的粒度做短期统计，同时保留1分钟、5分钟、15分钟的滚动聚合。应用层数据用1分钟粒度做基础统计即可，但针对关键接口需要保留秒级原始计数。存储方面，原始明细数据保留7到14天，聚合统计数据保留至少3个月。这样既能支撑实时检测，也能在事后做攻击复盘和基线回溯。
基线计算方法：分位数比平均值更可靠
直接用平均值加固定倍数做阈值，是很多团队犯的第一个错误。流量数据从来不是正态分布，白天和晚上差异大，工作日和周末差异大，促销活动期间更是完全偏离日常。平均值会被极端值拉偏，导致阈值要么过于宽松要么过于敏感。
更可靠的做法是按时段分桶，对每个时段的历史数据计算分位数。比如把一天按小时分成24个桶，每个桶内收集过去30天同一时段的数据，计算P50、P75、P90、P99分位数。正常流量区间可以定义为P1到P99之间的范围，超过P99.9才触发告警。对于波动特别大的指标，比如突发性很强的下单接口，可以用P99.5作为告警阈值，同时结合环比增长率和同比增长率做二次确认。
具体计算时需要注意，历史数据本身可能已经被攻击污染。如果某天某个时段发生过DDoS攻击，而这段数据没有被剔除，算出来的分位数就会偏高，导致基线被抬高。所以需要先做一次粗筛，把明显异常的时段标记出来，从训练数据集中排除。粗筛可以用简单的3-sigma规则或者孤立森林算法，不需要太精确，目的是去掉明显的离群点。
动态基线需要引入时间序列模型
固定分桶的静态基线有一个明显缺陷：业务是增长的，流量趋势是变化的。如果基线三个月不更新，阈值就会逐渐偏离实际。但更新太频繁也不行，攻击期间更新的基线会把攻击流量学进去。折中方案是采用滑动窗口加指数加权，让基线自动适应缓慢的业务增长，同时对突发的攻击流量保持迟钝。
一个实用的方法是使用Holt-Winters三次指数平滑模型，对每个核心指标分别建模。该模型能同时捕捉趋势和季节性，适合流量数据这种有明显周期规律的时间序列。模型参数中，alpha控制水平平滑，beta控制趋势平滑，gamma控制季节平滑，三个参数取值在0到1之间。对于大多数业务，alpha取0.2到0.4，beta取0.05到0.1，gamma取0.1到0.3比较合适。模型每5分钟更新一次，用预测值与实际值比较，残差超过预测区间则判定为异常。
如果团队没有能力维护时间序列模型，可以用更简单的百分位滑动窗口：取过去7天同一时刻前后各30分钟的数据作为一个窗口，计算窗口内的P99作为动态阈值。这个方法计算量小，容易实现，对周期性明显的业务效果不错。缺点是节假日或业务变更时误报率会上升，需要人工介入调整。
多指标联合判定，避免单点误报
单个指标超过阈值就触发告警，误报率通常很高。比如入向带宽突然升高，可能是因为某个大文件被大量下载，而不是攻击。所以基线的使用必须配合多指标联合判定。一个实用的规则是：网络层异常需要至少两个独立指标同时越界才触发告警，比如带宽和包速率同时超过P99，或者包速率和源IP熵值同时异常。应用层异常则需要请求速率和响应码分布或响应时长同时恶化。
源IP熵值是一个容易被忽视但非常有效的指标。正常业务流量中，源IP分布相对分散，熵值较高且稳定。DDoS攻击尤其是僵尸网络攻击，源IP分布往往呈现集中或伪随机特征，熵值会明显下降或异常波动。计算源IP熵值时，按每分钟统计一次，公式为H = -Σ(p_i * log2(p_i))，其中p_i是每个源IP的出现频率。正常业务的熵值通常在6到9之间，攻击时可能降到3以下或出现剧烈跳变。这个指标对检测伪造源IP的流量泛洪特别有效。
业务流量基线的分层阈值设计
不同业务接口的流量特征差异巨大，不能用一个全局阈值覆盖所有接口。需要按业务模块或URL路径分组，分别建立基线。比如搜索接口的QPS可能很高但响应快，下单接口QPS低但响应慢，登录接口QPS中等但失败率敏感。对每个分组分别计算请求速率、平均响应时长、错误率的分位数阈值。
分层阈值设计还有一个好处：当攻击只针对某个接口时，全局指标可能没有明显变化，但该接口的分组指标会立刻越界。比如攻击者对一个需要查询数据库的搜索接口发起CC攻击，全局QPS可能只上升了20%，但该接口的QPS可能上升了300%，同时响应时长从50毫秒飙升到2秒。如果只看全局，攻击会被漏掉；看分组指标，就能精准定位。
基线构建后的验证和持续调优
基线建好后不能直接上线，需要做至少两周的影子运行。影子运行期间，基线只记录不阻断，观察误报率和漏报率。误报率控制在1%以下比较理想，漏报率则需要通过模拟攻击来验证。可以定期在测试环境或低峰时段发起小规模的模拟攻击，比如用hping3发SYN Flood，用ab或wrk发HTTP请求洪泛，看基线能否在30秒内触发告警。
持续调优方面，每月至少要重新评估一次基线参数。重点看三个指标：告警准确率、告警平均响应时间、误报导致的业务影响。如果某个接口的业务逻辑发生了变化，比如新增了缓存层导致响应时长大幅下降，对应的基线必须重新训练。业务大版本上线前，也要提前调整基线，避免新功能上线被误判为攻击。
另外需要建立基线版本管理机制。每次调整基线参数，记录调整原因、调整内容、生效时间。当发生攻击漏报或误报时，可以回溯到具体版本，分析是基线本身的问题还是执行环节的问题。版本管理不需要复杂系统，用Git管理配置文件加上变更日志即可。
一个可落地的基线构建流程总结
第一步，梳理业务拓扑和流量路径，明确数据采集点。第二步，确定核心指标清单，网络层、传输层、应用层、业务层各选3到5个关键指标。第三步，部署采集工具，确保三层数据时间对齐。第四步，用至少30天的历史数据训练初始基线，剔除已知攻击时段。第五步，选择分位数或时间序列模型计算动态阈值。第六步，配置多指标联合判定规则和分层阈值。第七步，影子运行两周，统计误报漏报。第八步，正式启用并建立月度调优和版本管理机制。整个流程走下来，团队对自身业务流量特征的理解会深入很多，后续无论是扩容规划还是应急响应，都有了量化依据。
