业务是否受影响取决于应用延迟敏感度和重试机制；http API通常容忍100ms内抖动，而实时音视频、高频交易或redis主从同步在10ms抖动下就可能超时。
网络抖动到底多大才算影响业务
业务是否受影响，不取决于抖动绝对值，而取决于应用对延迟敏感度和重试机制。HTTP API 通常容忍 100ms 内抖动，而实时音视频、高频交易或 Redis 主从同步可能在 10ms 抖动下就出现超时或连接重置。
关键判断依据是：你的服务是否设置了 connect_timeout、read_timeout，以及下游依赖（如数据库、缓存）的超时阈值。例如，若用 curl 调用一个设了 --max-time 2 的接口，而网络抖动导致某次 RTT 突增至 2100ms，就会直接失败。
怎么用 ping 和 mtr 快速定位抖动来源
ping 只能看端到端，但抖动可能发生在中间某跳；mtr 是更有效的诊断工具，它结合了 traceroute 和持续 ping 的能力。
- 运行
mtr -r -c 100 -i 0.2 example.com（100 次探测，间隔 200ms），重点关注「Loss%」和「Avg」列突变的跳数 - 如果第 5 跳开始延迟骤增且方差大（
Jitter列明显高于前后跳），大概率是该节点出口拥塞或 QoS 限速 - 注意对比
mtr --tcp -P 6379 redis-host和普通 ICMP 结果——有些防火墙会优先丢弃 ICMP，而放行 TCP，此时必须用 TCP 模式测真实业务路径
业务日志里怎么识别抖动引发的异常
抖动本身不会直接报错，但会放大下游不稳定。常见线索包括：
-
Connection reset by peer或Broken pipe：TCP 连接被对方异常关闭，常因握手或 ACK 延迟超时触发 - java 应用中大量
java.net.SocketTimeoutException: Read timed out，且时间点与ping抖动峰值吻合 - nginx access log 中
$request_time正常但$upstream_response_time波动剧烈，说明问题在 upstream 网络而非本机处理 - Redis 客户端日志出现
io.netty.channel.ConnectTimeoutException，尤其在使用lettuce且未调大timeout时
别只盯着平均延迟，要盯 P95/P99 和标准差
平均延迟掩盖抖动本质。比如两组数据：[10,10,10,10,100] 和 [20,20,20,20,20]，平均都是 28ms，但前者 P95 是 100ms，后者是 20ms。
建议用 tcpreplay 回放真实流量 + tc 模拟抖动做压测，或在业务埋点中记录每次 rpc 的 rtt_ms，再用 prometheus + histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[1h])) by (le)) 观察长尾。
真正危险的是抖动不可预测性：连续三次 ping 结果为 5ms/80ms/12ms，比稳定 40ms 更容易触发熔断或误判节点下线。