适用场景

「网络慢」是最含糊的故障描述。正确做法是把路径切成四段：客户端到网关、网关到服务端、服务端内部、反向回包，然后逐段量化。没有分段就没法定责，也没法验证优化效果。

配置步骤（四段打点实操）

# 1) 路径与跳数
traceroute -T -p 443 app.example.com
mtr -rwzc 100 app.example.com

# 2) 客户端侧：请求耗时分段（curl 自带）
curl -o /dev/null -s -w 'dns=%{time_namelookup} conn=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://app.example.com/health

# 3) 服务端侧抓包：看请求到达与响应离开
tcpdump -i eth0 -nn -s0 -w /tmp/srv.pcap 'tcp port 443 and host 172.16.1.20'
tshark -r /tmp/srv.pcap -q -z io,stat,0.1

# 4) 重传与乱序统计
tshark -r /tmp/srv.pcap -Y 'tcp.analysis.retransmission' | wc -l
tshark -r /tmp/srv.pcap -Y 'tcp.analysis.ack_rtt' -T fields -e tcp.analysis.ack_rtt | sort -n | tail -5

关键参数与建议

  • 先量化再动手：记录 P50/P95/P99 与抖动，不看平均值掩盖问题
  • 分段打点：客户端、网关、服务端各打一次时间戳，求差得出每段耗时
  • 抓包位置：靠近客户端与靠近服务端各抓一份，比对同一请求的到达与离开时间
  • 干扰排除：同链路跑大流量测试会污染样本，排障时先控制变量
  • 无线与广域网优先怀疑：丢包、重传、漫游、运营商绕路
  • 时间同步：抓包多机分析前先确保时间源一致，偏差会让结论完全相反
  • 结论落文档：每次排障输出分段数据，形成基线库

容易踩的坑

  • 只在服务端抓包，看不到客户端到网关这一段的问题
  • 用平均值汇报，掩盖了 P99 的严重抖动
  • 多机抓包时间没同步，比对结论完全错误
  • 抓包没限长度，磁盘被写满
  • 排障期间同时跑备份，样本被污染
  • 没记录基线，改完无法证明变快了

验证与巡检

# 丢包与重传
tshark -r /tmp/srv.pcap -z io,stat,1,'COUNT(tcp.analysis.retransmission) tcp.analysis.retransmission'

# TCP 窗口与零窗口
ss -tin state established '( dport = :443 or sport = :443 )' | grep -E 'rtt|retrans|cwnd|rwnd' | head -20

# 链路质量
ping -c 100 -i 0.2 app.example.com | tail -3
  • 巡检：P95 基线、重传率 < 0.5%、无零窗口、每季度复核链路质量

小结

延迟排障的交付物是一张分段耗时表，不是「好像是网络问题」。谁的耗时高就查谁，改完用同一方法复测。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。