1. 概述与测试目标

目标：量化香港CN2链路在高峰/低峰/夜间等不同时间段的抖动（jitter）、丢包与恢复时间，给出可复现的操作步骤与判定标准。
适用对象：拥有CN2线路的IDC/主机用户、网络工程师与运维。

2. 准备工作与工具清单

1) 获取测试目标：向服务商索要“香港CN2节点的IP或域名”，若无则选取你到香港目的地的公网IP并在逻辑上确认走CN2（可通过traceroute辨别运营商标识）。
2) 工具：Linux或WSL优先；推荐安装 mtr、iperf3、tcpdump、fping、speedtest-cli、jq。命令示例（Ubuntu/Debian）：
sudo apt update && sudo apt install mtr iperf3 fping tcpdump -y
3) 权限与网络：需有能运行持续测试的机器、稳定电源与时间同步（ntp）。

3. 时间段与测试矩阵设计

1) 时间段：建议至少覆盖：工作日高峰（09:00-12:00, 14:00-18:00）、夜间（00:00-04:00）、周末。
2) 频率：短时采样（每分钟一次ping/mtr）与长时采样（每5分钟一次带宽/iperf测量）。
3) 持续时长：每个时间段至少持续2小时，连续三天以排除偶发性波动。

4. 基础连通性与延迟测试步骤（Ping / Traceroute / MTR）

步骤：
1) 连通性：ping -c 100 -i 0.2 <目标IP>（Linux，100包，间隔0.2s），Windows用ping -n 100 -w 200。记录平均/最小/最大/丢包率。
2) 路径：mtr -r -c 100 <目标IP>，输出包含各跃点丢包与延迟分布，保存为文本（重定向）。
3) 计划：每隔1分钟调用一次mtr并保存JSON或文本，便于后续分析。

5. 抖动与丢包的精确测量方法

1) 抖动定义：常用基于RTT差分的抖动（如RFC 3550的算法）或直接用RTT的标准差/均方差。
2) 使用工具：iperf3的UDP模式可以直接测量jitter：iperf3 -c <目标IP> -u -b 50M -t 60，iperf输出会包含jitter与丢包。
3) 自测方法：使用ping连续采样并计算相邻包RTT差的均值：例如把ping输出导出为CSV，再用Python或Excel计算abs(rtt[i]-rtt[i-1])的平均值作为抖动。

6. 带宽与吞吐、并发对抖动的影响测试

1) iperf3 TCP测吞吐：iperf3 -c <目标IP> -t 60 -P 4（4并发流），观察吞吐波动是否伴随抖动上升。
2) 多流压力测试：在本地发起多个iperf并发连接，记录同时的RTT/丢包/抖动，比较在空闲与满载时的差异。
3) Speedtest：使用speedtest-cli --json定期采集测得带宽与延迟，结合mtr结果判断是否为链路本身问题。

7. 恢复能力测试（如何安全、合法地测量恢复时间）

注意：不要制造对公网的非法攻击或影响他人业务。推荐两种安全方法：
方法A（受控仿真，本地）：在测试端用Linux tc netem模拟链路故障与抖动：
sudo tc qdisc add dev eth0 root netem loss 20% delay 200ms
然后记录故障发生到指标恢复的时间；恢复命令：sudo tc qdisc del dev eth0 root。
方法B（真实故障观测）：与服务商沟通，安排短暂维护窗口或观察真实故障发生时的BGP/路由切换与恢复时间，利用连续的mtr/iperf数据定位RTO。

8. 自动化采集脚本与日志保存（示例策略）

1) Shell周期任务：写脚本每分钟执行一次ping与mtr，输出CSV行，示例字段：timestamp,target,rtt_min,rtt_avg,rtt_max,packet_loss,jitter_est。
2) Cron示例：* * * * * /usr/local/bin/cn2_check.sh >> /var/log/cn2_check.csv。
3) 集中存储：建议将CSV定期上传到ELK/InfluxDB或直接用Python脚本生成日/小时级汇总图表。

9. 数据分析方法与判定标准

1) 抖动计算：用相邻包RTT差的平均ABS或RTT标准差；若使用iperf3 UDP，直接采用其报告的jitter(ms)。
2) 判定阈值（参考）：抖动 < 10ms 良好；10–30ms 可接受；>30ms 需排查。丢包 >1% 建议报警。恢复时间：若链路在60s内恢复视为快速；超过5分钟则需重大关注。
3) 可视化：绘制时间序列（RTT、丢包率、jitter），配合时间段标注（业务高峰）来定位规律性波动。

10. 常见原因与逐步定位建议

排查顺序建议：
1) 本地：检查网络接口、MTU（避免分片）、本机带宽占用与并发任务。
2) 运营商路径：用mtr查看在哪一跃点开始出现丢包/延迟异常，确认是否是上游或回程问题。
3) BGP/路由：若有权查看路由表，观察是否有频繁路径切换；必要时联系运营商提供更详细路由日志与净化方案。
优化可能包含：调整MSS/MTU、启用TCP拥塞算法（BBR）、请求运营商调整BGP策略或更换优先出口。

11. 问答一：如何判定抖动是否来自CN2而非本地网络？

问：如何确认抖动源头在CN2链路而不是本地机房或用户侧？

答：首先在测试端排除本地因素（停用并发任务、检查MTU、在本地LAN内部做基线测试）。然后使用mtr分跃比对：若丢包/延迟从特定跃点（通常是运营商网关）开始出现并在后续跃点持续，且在不同测试设备/不同出口重复出现，则问题很可能位于运营商（如CN2）或其上游。可将测试从不同AS/不同节点并行发起，交叉验证。

12. 问答二：如何在不影响生产的前提下做恢复能力测试？

问：我担心测试会影响业务，如何安全实施恢复能力测试？

答：优先采用受控仿真（本地tc netem）在非生产接口上模拟抖动与丢包，或在低峰时段并在运维窗口内与服务商协作做短时维护测试。避免直接在生产链路上断流或制造高丢包；任何真实线路变更务必提前通知影响面的所有干系人并记录回退方案。

13. 问答三：长期观测策略与报警设置应如何配置？

问：对于CN2链路应如何做长期观测与告警阈值设置？

答：长期观测：至少保留7天的分钟级原始数据和90天的小时级汇总。关键指标：平均RTT、RTT标准差（抖动）、丢包率、iperf吞吐。告警阈值示例：丢包率>1%（持续5分钟）或抖动均值>30ms（持续10分钟）或单点RTT突增>200ms。告警策略应支持分级，并触发自动抓包和mtr以便快速定位。

来源：实战测评香港cn2在不同时间段的网络抖动与恢复能力