上个月，我们接到客户投诉，说其部署在香港机房的跨境电商独立站——平时日流量在 10 万 PV / 天 + 峰值几千并发 —— 突然出现 “访问极慢 / 经常超时 / 页面大量 503” 问题。

当时A5IDC的香港机房监控显示：“出口带宽使用率接近满载（> 95%）”、“上行／下行流量暴涨”，但奇怪的是：业务日志并未显示对应的用户访问激增 —— 正常的访问量水平。初步怀疑：可能是被 DDoS 洪水攻击 (bandwidth‑flood)；但也不排除是普通网络“回程拥堵”（backhaul congestion / ISP peering link saturate）造成。

作为负责的运维工程师，我立刻带上笔记本，登录监控系统 + 路由器统计 + 流量分析设备，开始排查。下面是我当时的方法与思考过程。

为什么要区分：洪水攻击 vs 回程拥堵

如果是洪水攻击：继续加带宽意义不大，容易浪费资源；而且可能需要启动清洗、防火墙、SYN/UDP flood 防护等措施。

如果是回程拥堵 / 普通网络拥塞：更可能是路线 / ISP 问题，重点在于与上游 / 运营商沟通、优化 AS 路由 / BGP / CN2 / 国际链路，而不是做高防清洗。

判断错误，会导致误投入高防设备 / 误报警 / 或者忽略真实运营商问题。

诊断流程与技术细节

我把诊断拆成以下几个层次：流量监控 & 模型对比 → 协议 / 报文分析 → 连接行为分析 → 回程链路 / 路由分析 → 最终判定与响应。

1. 流量监控 & 基线对比

首先，我们需要有“正常业务时段”的流量基线 (baseline) —— 包括带宽使用率、连接数、包速率 (pps)、流量变化曲线等。

（数据为我司历史监控记录示例）

当天异常时间段 (15:42–16:10)：

很明显——带宽 & pps 都急剧飙升，是正常峰值流量的 5~10 倍。这是典型“流量型攻击 / 洪水”的首要红旗。

于是我写了一个简单的 Python 脚本，用于实时与 baseline 比较：

# traffic_anomaly_detector.py
import time
import psutil  # 或者从 sflow/snmp 采集
import numpy as np

# 假设 baseline_stats 是提前统计好的历史均值和标准差
baseline = {
    'bandwidth_mbps': 150,
    'pps': 50000,
}
threshold = {
    'bandwidth_ratio': 5.0,
    'pps_ratio': 5.0,
}

def is_anomalous(current, baseline, threshold):
    return (current['bandwidth_mbps'] / baseline['bandwidth_mbps'] > threshold['bandwidth_ratio'] or
            current['pps'] / baseline['pps'] > threshold['pps_ratio'])

while True:
    current = {
        'bandwidth_mbps': get_current_bandwidth(),  # 需要结合 SNMP / sFlow / 接口统计采集工具
        'pps': get_current_pps(),
    }
    if is_anomalous(current, baseline, threshold):
        print(f"[WARNING] 异常流量 {current}")
    time.sleep(5)

类似思路也在很多 DDoS 检测机制中被使用 —— 例如学术论文中提到的“基于包数 + 熵 (entropy) 的混合检测方法”。

如果流量 / pps 突发高到基线的几倍 —— 首要考虑洪水攻击，而不是普通业务激增或网络拥塞。

2. 协议 / 报文层面分析

确认流量异常之后，接下来抓包 (pcap) 或使用 netflow / sFlow / iptables + conntrack 统计分析，观察流量协议结构是否反常。

我们重点关注：

• 是否为大量无状态 / UDP / ICMP /较小固定包 (fixed‑size packets)
• 是否大量 SYN (未完成握手) / 半开连接 (SYN flood)
• 是否来自地理 / 源 IP 集中或极度分散 / 无规律 / 无业务上下文

当天抓包的观察 (简化)：

• UDP 流量占比达到 70%，且大部分包大小固定为 512 bytes。
• SYN 包数骤增，且大量来自伪造 / 不同国籍 IP；很多 SYN 没有收到对应 ACK（半开连接堆积）。
• 基于这些特征，我判断很可能是 UDP Flood + SYN Flood 混合攻击。
• 这与 UDP Flood 攻击 / SYN Flood 攻击 的典型特征一致。
• 单纯靠增加带宽 / 优化 BGP 路由是无法缓解这种“极度短时、大量无效包”的攻击。

3. 连接行为 & 成功率分析

在抓包和 conntrack 统计基础上，我统计了 SYN → SYN‑ACK → ACK 的三次握手成功率 (connection success rate)：

成功率骤降 —— 极大比例是半开 (half‑open / incomplete) 连接。 这是典型 SYN‑Flood / 半开连接攻击的信号。

正常网络拥堵时，不太可能导致连接成功率从 90% 降到 5%。因为拥堵虽可能造成丢包 / 超时，但大部分合法 TCP 连接仍会成功完成三次握手 —— 特别是来自真实用户、带有 ACK 的连接。

因此，这一步进一步确认：问题不是普通的路由拥塞 / 链路饱和，而是恶意流量洪水 + 半开连接攻击。

4. 排除“回程 / 上游链路拥堵 / 路由问题”的可能

虽然流量异常 + 协议 / 连接行为很像洪水攻击，但作为谨慎运维，我仍检查了“回程链路 / 上游运营商 / 路由”的健康状况 —— 避免误判为攻击。

联系骨干网络提供商 (ISP / 上游) 查询：当日并无该时段其网络报告异常 / 故障 / 链路故障。

使用 BGP 路由监控系统 (我们内部有一个脚本定期抓取路由表并记录各条目 AS 路由 + next‑hop) —— 查阅当日 15:30 ~ 16:15 的 BGP 路由变化记录，无明显大范围 route flap（抖动）或 peer down。

与其他租户对比：同机房、同运营商、不同客户的网站流量 / 可访问性均正常。

综合来看，并无上游链路问题或 BGP 路由异常 —— 倾向于本服务器/本 IP 被针对。

回应与处置方案

确认是洪水攻击 (UDP + SYN flood) 后，我立即按预案执行以下处置，并最终恢复业务。

硬件 / 网络 / 防护配置

我们当时部署的是 1 Gbps 国际带宽 + CN2 + BGP 自动多路，由机柜防火墙 (iptables + conntrack) + 上游清洗能力 + 应用层 Web 服务 (Nginx + PHP-FPM + MySQL) 构成。

临时启用了防火墙规则 + 限速 (rate‑limit) + SYN‑cookies + conntrack 限制 + UDP 丢弃：

# iptables 防护示例
iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 200 -j DROP
iptables -A INPUT -p udp -m limit --limit 1000/sec -j DROP
# 启用 SYN cookies (内核)
sysctl -w net.ipv4.tcp_syncookies=1
# 限制 conntrack 总表项数
sysctl -w net.netfilter.nf_conntrack_max=200000
# 对超速 / 大量 pps 的源 IP 加黑名单

同时联系上游 ISP：请求启动流量清洗 (scrubbing)，将恶意流量清洗 (drop / null‑route) 在上游。我们有与 ISP 签署 “清洗服务 / 高防触发机制” SLA，所以他们很配合，将目标 IP 临时切换到高防线路并清洗。

业务层 (Web / API) 同时打开限流 + 缓存策略 (如 Nginx 缓存 / 403 对非正常请求) 防止应用层被压垮。

后续防护机制建设

我们总结并落地了一套 “自动检测 + 自动防护 + 报警触发” 流程：

实时流量 & pps 监控 + 异常检测脚本 (参考上文 Python)：一旦流量 / pps 超过 baseline 的 3–5 倍，就触发报警。

连接成功率监控 (SYN / ACK ratio)：每 1 分钟统计一次 SYN / SYN‑ACK / ACK，比对成功率；若低于设定阈值 (如 < 20%)，触发“疑似 SYN flood”报警。

自动防护脚本：当二级报警 (流量 + 连接成功率异常) 同时触发时，自动部署 iptables 限流 / 丢弃策略 + 联系上游清洗。

日志 & 报表：每日 / 每周生成流量 / 连接 / success‑rate 报表，用于趋势分析 & SLA 汇报。

预案演练：每季度进行一次模拟 flood 攻击 (controlled flood simulated) — 测试防护脚本、生效时间、业务恢复流程等。

我们还参考学术界对于 DDoS 检测的混合方法，将“基于流量 + 基于行为 (entropy / conn‑pattern) + 基于成功率 (SYN/ACK)”结合，以提升检测精度并减少误判 (普通流量高峰被误判)。

遇到的坑 & 现场教训

在这个过程中，我也遇到不少坑 — 经验教训很值得记录：

Baseline 建立不充分：开始监控时，只记录了带宽，没有统计 pps、conntrack 数据。结果一开始误把 pps 突增当成普通高峰 — 幸亏协议 / 连接分析补上。

防火墙 / conntrack 限制过严导致误伤：第一次启 iptables 丢弃 UDP 后，有少数合法用户 (通过某些 CDN / UDP API) 出现连接失败。后来调整策略，仅丢弃源自 “非业务端口 + 高 pps 且连续 5 秒以上 的 UDP 包”。

依赖上游清洗服务时延迟较高：因为要联系 ISP + 启动清洗，整个过程有几分钟延迟 — 在这期间服务可能仍然不稳定。后来我们加了自动化脚本 + SLA 中设置 “高峰期自动触发清洗，无需人工确认”。

日志量过大 / 存储压力大：抓包 + netflow + conntrack 日志在 flood 高峰时数据量暴涨，需要额外扩容日志存储 (Elasticsearch / 分片)；否则会导致磁盘写满。

为什么能“看出来是洪水攻击而不是回程拥堵”

综合上述几个维度 —— 流量 / pps 突发 + 包 / 协议异常 + 半开连接成功率极低 + 上游 / 路由链路正常 + 同机房其他租户正常 —— 几乎可以 排除回程拥堵 / 路由问题，而 高度确认是针对性的 flood 攻击。

回程拥堵 / 路由拥塞，一般表现为：带宽接近满载，但包结构仍然与正常业务类似 (TCP + TLS + HTTP 混合, 包大小 / 协议比例与 baseline 接近)，连接成功率不会崩到 5%。

而 flood 攻击恰恰在协议层 & 连接层表现异常。

这种判断对我们后续如何处置 (是否升级带宽 / 是否启用防护 / 是否联系上游 / 是否记录为安全事件) 有重大意义。

总结：给香港服务器 / 国际带宽运维团队的建议

• 务必建立多维度 baseline (带宽 / pps / conntrack / 成功率)，不仅仅看带宽。
• 实时检测 + 自动报警 + 自动防护脚本 — flood attack 往往来得快、停得快。
• 联合防火墙 (iptables / conntrack / SYN‑cookie) + 上游清洗服务 + 应用层限流 / 缓存 构建多层防护体系。
• 定期演练 / 模拟攻击 + 日志 / 报表 — 了解防护流程是否通畅、是否误伤业务、是否在可接受误报率范围。
• 记录教训：日志存储、误伤 (false positive)、与上游沟通延迟等都要考虑。

当我在香港机房看到监控仪表骤然跳红灯，流量 / pps 像火箭一样窜上去的时候，我知道，这 不是 回程拥堵 —— 是洪水攻击。那一刻，我像“战场上的守夜人” —— 一边紧盯流量图，一边敲命令，一边联系上游清洗。

那场混合 UDP + SYN 洪水攻击，在我们启动自动防护 + 上游清洗之后，仅 8 分钟内被基本控制，网站恢复可访问。事后回看日志、报表、连接成功率数据，我能清楚地追踪到当时发生的一切 —— 这让我坚定：高并发 / 高带宽国际链路 + 跨境业务，必须建立起类似“战备状态”的监控 + 防护体系。