业务抖动、丢包或延迟高,客户先骂我们;运维要能在最短时间指出是“链路”还是“机子”。
本文直接给出可执行的定位流程、必跑命令与判定阈值,适用于香港地区通过中间ISP或CDN转发的大带宽VPS场景。
用三步快速判定:1) 本地到VPS延迟/丢包基线;2) VPS到外部目标的双向测试;3) 查看CPU/网卡饱和,这三步能在三分钟内将疑点缩小一半。
第一步用ping与mtr测延迟与丢包,第二步在VPS上跑iperf做带宽确认,第三步看top/iostat/netstat判断主机资源是否被耗尽。经验结论:先把时间花在测量上,而不是盲改配置。 下一步,我们讲如何用mtr和iperf把问题点钉死。
直接运行mtr -rwz —记录丢包/延迟分布,定位哪一跳出现稳定丢包或延迟突增,这是最直观的链路断点指示器(需要连续运行1分钟以上)。
在实际项目落地中,我们常在第3-5跳看到丢包,这通常指向上游ISP的交换或链路问题。行业共识:连续的丢包>2%且伴随延迟跳变,基本可以判定为链路异常。 下一步用iperf验证带宽能力。
在VPS与对端(或测试机)做双向iperf3测试,分别用TCP与UDP模组测峰值和丢包,观察吞吐和重传率,能区分是拥塞还是限速。
我们常见的模式:TCP吞吐低但延迟正常,通常是TCP窗口或队列问题;UDP丢包高则是链路拥塞。经验结论:带宽测试要做双向,单向测试容易遗漏对端限速。 然后需要抓包看TCP细节。
抓包不是复杂操作:只抓问题时间窗口和关键五元组,然后定位SYN/ACK、重传和窗口缩减就能看到根因,抓包要有目标并且时间短而准。
用tcpdump -w抓取端口、IP、VLAN(若有),在本地通过Wireshark看TCP重传、Dup ACK、Zero Window等信号。创新结论:重传多但链路利用率低,多半是链路丢包或中间策略丢包。 下一段看如何结合路由信息判断更深层次的问题。
示例:tcpdump -i eth0 host A.B.C.D and port 443 -w /tmp/capture.pcap,抓握包时同时记录时间戳和队列长度指标,便于回放定位。
在不少同行反馈中,抓包后发现是对端做了薄流量策略或中间网络NAT导致MTU不一致。操作建议:先抓小流量样本再扩大范围。 接下来要看路由与BGP面板。
看SYN延迟、SYN-ACK超时、重复ACK和RST分布:三次握手异常多为中间丢包;重传伴随Dup ACK通常是链路丢包;RST多提示上游策略或黑洞。
一句话解释:重传是链路在尖峰期“吐词”——你需要找出哪个节点开始“打瞌睡”。行业共识:连续的SYN丢失比单包丢失更能代表路径性故障。 下面转到路由诊断。
检查AS路径、社区标记、下一跳是否变动以及是否存在不合理的AS回环;这些信息能告诉你问题是出在本地互联点、上游ISP还是海外出口。
在香港场景,往往因为IDC到本地交换中心的互联或IX策略不稳,导致间歇性丢包或流量绕行。经验结论:AS路径频繁变化是恶劣网络体验的重要信号。 接着说明如何查具体AS与路由策略。
用traceroute查看下一跳是否在同一ASN,结合BGP路由查看是否有community被打上黑洞或限流标签,必要时联系上游运营商核实。
我们通常会把问题截图发给ISP NOC,附上mtr/pcap/BGP路径,能显著缩短响应时间。实践结论:有证据的沟通比无端猜测更快。 下一小节谈监控与量化。
把延迟、丢包、抖动、带宽利用率与TCP重传率做成板块化仪表盘,阈值告警与自动抓包配合,能把“偶发性”转成可复现的事件。
常用指标:1分钟丢包、95/99延迟、TCP重传率、接口错误包。最佳实践:所有告警都应触发自动抓包与事件记录。 最后给出可落地的运维清单和下一步行动。
下一步行动:把上述工具脚本化,形成事故播放单;并将常见故障模式写入运维知识库,便于团队复用。