要确认流量是否走 cn2,可以通过多种方法交叉验证:首先使用 traceroute(或 Windows 的 tracert、Linux/Unix 的 mtr)查看中间跳点的主机名,通常带有包含“cn2”、“ct”或“telecom”相关的标识;其次查询 IP 的 BGP/WHOIS 信息(例如 bgp.he.net、whois、ipinfo.io)确认该 IP 的 AS 与运营商是否为中国电信或阿里云的出口;第三可以向阿里云控制台或运营商确认实例的弹性公网 IP 分配和出口策略,或直接在阿里云控制面板查看网络类型。注意仅凭单次 traceroute 不能绝对断定,建议在不同时间窗口重复检测并结合 BGP 信息作判断。
常用命令示例:
Linux: mtr -r -c 100 目标IP,traceroute -T -p 80 目标IP;WHOIS/BGP: 访问 bgp.he.net 或 whois 目标IP。观察跳点主机名中是否包含 cn2 字样及 AS 路径是否属于中国电信相关 AS。
稳定性评估以长期与分散时间点的数据为准。主要指标为丢包率、往返延时(RTT)和抖动(jitter)。推荐步骤:使用 ping 做长时间采样(如 ping -c 1000 -i 0.2 目标IP),并记录丢包和 RTT 分布;使用 mtr -r -c 1000 分析每跳丢包,定位是本地、出口还是中间链路问题;如果需要精确的一端到另一端单向延迟,需在两端做时钟同步(NTP/chrony)后采样并计算单向延时。
通常 RTT 低且稳定、丢包 < 0.1%、抖动 < 10ms 可认为较好;若丢包 > 1% 或抖动频繁峰值超过几十毫秒,则需要进一步排查链路或上下行拥塞。用 mtr 可看到是某一跳开始出现丢包(多为中间链路问题),还是最终目的地丢包(可能为主机或防火墙问题)。
测带宽上限以 iperf3 为主。搭建测试时需要一个可靠的服务端(建议部署在新加坡或靠近目标的公网节点),客户端从另一端发起测试。推荐方法:先测试单流 TCP:iperf3 -c server -t 60;再用并发流测试以充分利用 TCP 并行性:iperf3 -c server -P 8 -t 60(-P 表示并发流数)。对 UDP 带宽和丢包也可使用 iperf3 -u -b 0 或指定带宽来检测丢包率和抖动。
带宽测试结果受多方面限制:实例规格与云网卡上限、宿主机的虚拟化带宽限速、本地网络(客户端机器网卡/带宽)、中间网络策略(ISP 限速或流控)、TCP 窗口与协议栈调优等。为了得到准确“链路”上限,需确保两端实例规格和本地网卡都足够高,并多次测试与不同时间段比对。
常用参数组合:iperf3 -c server -P 8 -t 60 --logfile result.txt(并发 8 流测试 60 秒),UDP 丢包测试:iperf3 -c server -u -b 0 -t 30(-b 0 表示尽可能追满链路,注意服务器与网络是否允许如此高流量)。
排除干扰要从端到端逐步验证:确认两端 CPU/内存未达瓶颈,禁止或停止系统级别的备份/更新任务;确认实例的网络类型和弹性网卡不受云产品策略限速;本地测试机器不要受 Wi‑Fi、VPN 或本地 NAT 的影响,优先使用有线直连千兆网卡;在云端,检查安全组与防火墙是否对测试端口限速或丢包;用不同端口(80/443/5201 等)和协议(TCP/UDP)复测,以识别是否存在端口/协议相关的限速或策略。
建议按顺序排查:本地网卡/线路 → 客户端配置(窗口/MTU)→ 云实例规格/ENI → 中间链路(mtr/traceroute)→ ISP 或云运营商策略。对 MTU 问题可用 ping -M do -s size 测试分片与 MSS,避免因分片导致性能下降。
长期监控建议结合采样与告警:使用 Prometheus + node_exporter/blackbox_exporter 收集 ping、http、iperf3 导出器的数据,并用 Grafana 可视化 RTT、丢包、吞吐与抖动趋势;或部署专门的网络监控工具如 Smokeping、Zabbix、LibreNMS。自动化测试可用脚本周期性运行 iperf3/mtr/ping,将结果上报到时序数据库(InfluxDB/Prometheus),并在异常(丢包超阈、带宽骤降、延迟突增)时触发告警(邮件/钉钉/短信)。
示例 cron 任务:每 15 分钟运行一次短 iperf3(或更长的夜间深度测试),并每日汇总带宽峰值与丢包率;保存原始日志以便出现问题时回溯分析。对于关键业务,可在多可用区或多线路上并行监控,建立对比基线来区分全网性问题与单一路径异常。