本文概述了从准备测试环境到数据采集和分析的完整流程,重点介绍如何用常见命令和工具(如 ping、mtr、iperf3、traceroute 等)评估通过 cn2专线 访问韩国 时的 稳定性 与 丢包率,并给出判断阈值与定位思路,便于与运营商或对端沟通处理。
先在韩国侧准备至少一台可控服务器(例如云主机或自有服务器),确保具备 root/管理员权限用于安装测试工具和抓包;在中国侧选择多个不同城市或不同运营商的节点作为发起点,优先包含使用 cn2专线 的出口;统一时间同步(NTP),关闭不必要防火墙规则,保证测试端口开放。建议准备好能长期运行的监控主机用于后续持续观测。
常用工具包括:ping(基础丢包与延迟)、mtr(结合 traceroute 的连续丢包与每跳延迟)、traceroute/tcptraceroute(确认路由路径)、iperf3(带宽与丢包/抖动,UDP/TCP 测试)、hping3(可自定义报文)、smokeping/Smokeping 类工具或 Prometheus+Grafana 用于长期可视化。必要时用 tcpdump/wireshark 抓包做深度分析。
先做路由确认:用 traceroute/tcptraceroute 确认是否走 CN2 路径(观察中间 AS/跳数)。然后进行短期与长期测试:短期用 iperf3(TCP 与 UDP)测试瞬时带宽与丢包,持续 1–10 分钟;用 mtr/连续 ping 运行 10–30 分钟,查看逐跳丢包;长期用 smokeping 或周期性 ping(例如每 1 分钟一次)监控 24–72 小时或更长。对比不同时间段与不同发起点的结果,必要时改变包大小与并发流数以模拟真实业务。
数据应同时保存在发起端和韩国端,包含 ping/mtr/traceroute 输出、iperf3 日志和抓包文件(pcap)。所有测试节点必须使用统一的时间基准(NTP),并记录测试开始/结束时间、频段、端口、报文大小等元数据。把数据上报到集中监控(如 Prometheus + Grafana 或 ELK)方便时序对比与告警设置。
丢包与不稳定常见原因有链路拥塞、转发设备丢弃(队列溢出)、跨境出口链路质量不佳、路由抖动或策略限速、防火墙/中间设备丢包、MTU 不匹配导致分片丢失等。定位思路是:用 mtr 判断哪一跳开始出现丢包(如果是中间某跳持续丢包,说明运营商侧问题);用 iperf3 验证是否是带宽饱和导致;用 tcpdump 抓包看是否有 ICMP Destination Unreachable、TCP 重传或重复 ACK 等迹象。
评估应包含短期和长期两个维度:短期测试(10–30 分钟)可捕捉瞬时丢包与带宽问题;中期(24–72 小时)能观察日夜或高峰时段波动;长期(7–30 天)有助于评估周期性问题和路由策略影响。Ping 间隔常用 1s 或 10s,监控采样不宜过稀。判断阈值示例:丢包 <0.1% 为优秀,0.1–1% 为可接受但需关注,>1% 则应认真排查;延迟若稳定在业务预期范围内且抖动小则可接受。
分析时把延迟的 p50/p95/p99、丢包率时间序列、每跳丢包分布和带宽测试记录整理成图表,标注发生问题的时间窗口与对应路由路径。与运营商沟通时提供 mtr/traceroute 原始日志、抓包 pcap、iperf3 测试记录和发生时段,明确描述业务影响与期望。若定位到特定跳有持续丢包,要求其对该链路/设备做链路排查或调整路由策略,必要时申请切换出口或使用备份通道。