判断基本连通性首先从简单工具开始:使用 ping 测试 ICMP 报文是否通达,命令示例:ping -c 5 8.8.8.8 或 ping 目标域名。若 ICMP 被屏蔽,可用 tcping(或用 curl 发起 HTTP 请求)测试特定端口,示例:tcping example.com 80 或 curl -I http://example.com。
若 ping 超时但 TCP 可达,说明可能存在 ICMP 限制但业务端口正常。若都不可达,继续使用 traceroute 或 mtr 确认网络中断在哪一跳,命令示例:traceroute -n 8.8.8.8 或 mtr -rw 8.8.8.8。
部分云厂商或防火墙会限制 ICMP,应综合多工具判断,不要仅凭 ping 结论。
常用工具包括 traceroute、mtr(结合 ping 与 traceroute 功能)以及 tcptraceroute。mtr 实时显示每跳的延迟与丢包率,适合持续观察;traceroute 适合单次获取跳数与每跳延迟。
mtr -rw 目标IP 会给出每跳的丢包与平均延迟。若某一跳丢包高但后续稳定,可能是该路由器对 ICMP 响应做限速;若丢包在后续跳仍高,说明真正的链路质量问题。
遇到跨境访问问题时,结合 whois 或路由查询工具确定 ASN,判断是否存在上游转发问题或政策性限制。
推荐使用 iperf3 进行点对点吞吐量测试,能测 TCP/UDP 带宽并支持双向测试。命令示例:服务端 iperf3 -s,客户端 iperf3 -c server_ip -P 4 -t 30(-P 并发流数,-t 测试时长)。
若需要与互联网测速,使用 speedtest-cli 或基于 Web 的 Speedtest 可测到接入到最近测试节点的上/下行速率;但这些测试受测试节点位置与网络拥塞影响较大。
多次测试、不同时间段与不同并发流数下取平均,注意排除虚拟机本身 CPU 限制、网络队列与内核参数影响(如 window size)。
若测出的带宽远低于承诺值,应排查虚拟机规格与宿主机限速(比如 vNIC 限速、SR-IOV/virtio 性能差异)。可通过在不同 VM、不同实例规格或直连物理机上重复 iperf3 测试来对比。
CPU 占用高会影响 iperf3 的性能,检查 top 或 htop;vNIC 驱动与内核参数(如 TCP buffer)也会影响吞吐。若用 NAT 模式,NAT 转发性能可能成为瓶颈,建议测试时使用公网直通或桥接模式。
通过调整并发流数、开启/关闭 TLS、切换协议(TCP/UDP)来判断瓶颈所在,必要时联系云服务商确认宿主机网络策略。
可使用脚本(Bash / Python)定时调用 ping、mtr、iperf3 与 speedtest-cli,把结果写入 CSV 或推送到监控系统(如 Prometheus + Grafana)。示例流程:调度器 -> 执行脚本 -> 保存日志 -> 分析并绘图。
脚本中记录测试时间、目标 IP、延迟中位数/均值、丢包率与带宽峰值;设置告警阈值(如丢包>5% 或上行/下行低于阈值)并通过邮件/Webhook 报警。
长期保存数据可以发现时段性拥塞或运营商路由变动带来的性能差异,有助于优化部署或调度流量。