会话表为什么是关键资源
防火墙要为每条经过的连接维护会话表项，容量由型号规格决定且是有限的。会话表被打满时的表现不是「缓慢变差」而是「新建连接直接失败」：已有连接可能还在跑，新用户却连不上。因此会话容量需要持续观察趋势，在接近瓶颈之前用老化优化或扩容来处理，而不是等告警上门。
基本信息
| 监控指标 | 会话总数、使用率、每秒新建速率、老化数量 |
|---|---|
| 瓶颈表现 | 新建连接变慢或失败，日志出现资源类告警 |
| 常见成因 | 扫描攻击、应用异常重试、长连接堆积 |
| 优化手段 | 调整老化时间、清理异常占用、限制异常来源 |
| 扩容方式 | 提升规格或增加设备分担，按变更流程执行 |
| 排查配合 | 容量异常时同步查看威胁日志与连接统计 |
典型使用场景
- 上线后确认会话容量规格是否满足业务规模
- 异常时段排查新建连接失败的原因
- 业务增长后评估是否需要扩容
- 攻击期间观察会话占用并限制异常来源
- 新增业务或大促前的容量评估
排查步骤
排查步骤
1. 查看会话使用率与近期趋势 # 现状
2. 按源地址、目的与应用统计占用来源 # 定位占比
3. 分析长连接与异常会话的占比 # 判断性质
4. 调整老化参数或清理异常占用 # 缓解
5. 容量仍不足时按变更流程评估扩容 # 根治容量问题的两类成因与处置
| 成因 | 特征 | 处置方式 |
|---|---|---|
| 异常流量导致 | 会话数短时间内骤增 | 限速封禁来源并排查攻击 |
| 业务增长导致 | 使用率随规模稳定上升 | 优化老化参数或扩容 |
| 长连接堆积 | 单条会话存活时间很长 | 评估应用侧连接管理策略 |
攻击与异常扫描同样会推高会话数：容量异常时要同步查看威胁日志，而不是只盯着应用侧。
会话打满后才发现问题的代价很高：业务直接表现为新建连接失败，恢复时间取决于处置速度。