监控图上平均延迟一直稳定在 160ms，可用户却在投诉"时快时慢"；SSH 敲命令偶尔要等半秒才回显；视频会议每隔几分钟卡一下。这类现象的元凶通常不是"延迟高"，而是抖动（Jitter）——延迟的稳定性差。抖动对交互式业务和实时业务的杀伤力，往往远大于单纯的延迟绝对值。但它也是最容易被忽略的指标：大部分监控只画平均值，把波动给平滑掉了。本文讲清楚抖动的成因、如何量化它、如何定位到具体网段，以及不同成因对应的处置手段。
一、什么是抖动，为什么它比平均延迟更致命
1.1 定义
抖动指延迟的变化程度，通常用延迟样本的标准差（ping 输出里的 mdev）或相邻包延迟差的平均值来衡量。举例：一组样本的延迟依次是 155、158、160、157、330、156 ms，平均值会被那个 330 拉高一些，但真正的问题是那个突发的 330——它代表某次排队或重传。
1.2 不同业务对抖动的敏感度
| 业务类型 | 主要敏感指标 | 抖动的典型影响 |
|---|---|---|
| 网页浏览、文件下载 | 吞吐、丢包 | 影响较小，TCP 可重传补偿 |
| SSH / 远程桌面 | 延迟、抖动 | 输入回显一顿一顿，操作手感差 |
| API 调用、微服务 | 尾延迟（P99） | 单次慢请求拖慢整体链路 |
| 语音 / 视频会议 | 抖动、丢包 | 卡顿、断续、音画不同步 |
| 实时游戏 | 抖动、丢包 | 瞬移、操作延迟不可预测 |
| 数据库同步 / 分布式一致性 | 延迟、丢包 | 超时重试、主从延迟增大 |
关键结论：凡是"一次请求要等结果"的交互式场景，抖动都会被直接感知；凡是"大块数据慢慢传"的场景，抖动影响相对可控。所以排查抖动前，先确认投诉来自哪类业务，这决定了处置的优先级。
二、抖动的四类常见成因
2.1 链路拥塞（最常见）
当某段链路的流量超过其容量时，数据包在路由器队列中排队等待，队列越长延迟越高，而队列长度随流量波动，就产生了抖动。拥塞有几种典型形态：
- 国际出口拥塞：跨境流量在晚间高峰（国内时间约 20:00-23:00）集中，出口队列排满，延迟与抖动同步上升
- 跨网互联点拥塞：用户是移动/联通、机房主接电信时，数据要经过运营商互联点，该点容量不足就会拥塞
- 机房上行打满：机房出口带宽跑满，所有流量一起排队
- 本地宽带上行打满：用户侧有上传、云盘同步、视频会议占用上行，ACK 回不去导致延迟飙升
2.2 丢包与重传
丢包本身会造成延迟突刺：TCP 检测到丢包后要等待重传超时（RTO）或快速重传，这段时间可能是正常 RTT 的数倍。丢包原因包括：
- 拥塞导致的队列尾丢（tail drop）
- 链路质量问题（光衰、误码、接触不良）
- 设备性能不足（CPU 高导致转发丢包）
- 安全策略或限速（ICMP 限速、连接数限制）
- MTU 不匹配导致分片丢弃
2.3 路由不稳定
- 路由震荡：BGP 会话不稳定、链路频繁切换，导致路径反复变化，延迟随路径切换而跳变
- 负载分担：等价多路径（ECMP）下不同包走不同路径，若各路径延迟差异大，就会产生抖动
- 绕路：本可直达却绕道，延迟基数被抬高
2.4 服务器自身
- CPU 满载或软中断集中在单核，导致包处理不及时
- 网卡协商异常（速率/双工不匹配）产生错包
- 连接队列、accept 队列满
- 内核缓冲区或拥塞控制参数配置不当
- 虚拟化环境的 CPU 抢占（steal time）
三、量化抖动：先把现象测准
3.1 用 ping 测抖动基线
# 100 个包、间隔 0.2 秒，约 20 秒完成 ping -c 100 -i 0.2 203.0.113.10 # 关注最后一行 # rtt min/avg/max/mdev = 152.301/168.772/341.220/38.455 ms
判断参考（经验值，需结合业务容忍度）：
mdev低于avg的 10%：链路稳定mdev在avg的 10%-25%：存在可感知波动，需要关注mdev超过avg的 25%：明显抖动，交互式业务会受影响max超过avg的 2 倍以上：存在突发性排队或重传
3.2 更精细：用 ping 的时间戳看逐包变化
# 开启时间戳，观察每个包的延迟变化规律
ping -D -c 100 -i 0.2 203.0.113.10
# 只打印往返时间，便于后续统计
ping -c 200 -i 0.1 203.0.113.10 | awk -F'time=' '/time=/{print $2}'
把逐包延迟导出后，可以观察抖动是随机分布（拥塞）还是周期性（定时任务、备份流量、流量整形）。周期性抖动往往指向内部流量调度或限速策略。
3.3 用 MTR 看抖动的分布位置
# TCP 模式，100 个周期，报告模式 mtr -T -P 80 --report --report-cycles 100 203.0.113.10 # 关注 StDev 列，找到标准差从哪一跳开始变大 mtr -T -P 443 --report --report-cycles 200 203.0.113.10
MTR 输出中 StDev 列就是该跳的抖动。定位规则：找到 StDev 首次明显增大的那一跳，问题就出在它之后的那段链路上。如果从第一跳就大，问题在本地；如果只有最后一跳大，问题在服务器；如果中间某跳之后整体抬升，问题在运营商链路。
3.4 用 ss 看真实连接的 RTT 与重传
# 显示每条连接的 RTT、重传数、拥塞窗口、发送/接收队列
ss -i
# 只看已建立连接并统计状态分布
ss -ant | awk 'NR>1{print $1}' | sort | uniq -c
# 查看 TCP 全局统计中的重传相关计数
cat /proc/net/snmp | grep -i Tcp
ss -i 输出中的 rtt（如 rtt:168.5/22.3，分别是平滑 RTT 与其偏差）和 retrans（重传数）是关键指标。若 rtt 的偏差值大且 retrans 持续增长，说明链路上存在真实丢包导致的抖动；若 rtt 正常但 retrans 高，可能是乱序或缓冲区问题。
四、定位方法：五个对比维度
抖动排查的核心方法是做对比，通过控制变量缩小范围。
4.1 逐跳对比：定位到具体网段
如上所述，用 mtr -T -P 80 --report --report-cycles 100 找到 StDev 开始变大的跳。把该跳 IP 的归属查清楚：
# 查询 IP 归属的 AS 与网段信息 whois 203.0.113.1 | grep -i -E 'origin|netname|descr|country'
这样能确认问题发生在"本地接入网""用户运营商骨干""国际出口""机房上游"还是"机房内部"，便于后续找正确的责任方。
4.2 跨网段对比：确认是否普遍现象
换三个不同网络环境测同一目标：办公网（企业专线）、家庭宽带、手机流量。同时换运营商环境（电信/联通/移动）。
- 只有某个网络抖：问题在该网络或其到机房的路径上
- 所有网络都抖：问题在机房侧或公共链路上
- 只有某个运营商抖：典型的跨网互联或该运营商方向接入质量问题
4.3 晚高峰对比：确认是否拥塞
在三个时段用完全相同的命令测：上午 10 点、晚上 21 点、凌晨 2 点。把 avg、mdev、丢包率列表对比。
| 时段对比结果 | 可能成因 | 处置方向 |
|---|---|---|
| 仅晚高峰劣化，凌晨恢复 | 国际出口或互联点拥塞 | 更换优化线路、错峰、CDN 分流 |
| 全天都抖，无时段规律 | 链路质量、设备问题、路由震荡 | 提交工单排查链路、检查网卡 |
| 特定时间周期性出现 | 内部备份/同步任务、流量整形 | 调整任务时间、做 QoS |
| 仅业务高峰时抖 | 带宽打满 | 扩容带宽或限速 |
| 全天稳定，偶发突刺 | 瞬时拥塞或路径切换 | 观察频率，一般不紧急 |
4.4 双向对比：去程与回程
抖动常常只出现在一个方向。从本地测去程，登录服务器测回程：
# 在服务器上反向测到国内目标 mtr -n --report --report-cycles 100 1.2.4.8 ping -c 100 -i 0.2 1.2.4.8
若回程抖动大而去程正常，说明响应数据在返回途中排队——这在跨境链路中非常常见，也是很多"去程很快却依然卡顿"的原因。
4.5 同机房对比：排除个案
找同机房的另一台机器（或让服务商提供测试 IP）做同样的测试。若同机房其他机器正常，问题在你的服务器；若都抖，是机房或上游链路的问题。
五、服务器自身排查与优化
5.1 网卡与链路层
# 查看网卡速率、双工、协商状态 ethtool eth0 # 查看网卡错包、丢帧、溢出统计 cat /proc/net/dev # 查看更详细的网卡统计（部分网卡支持） ethtool -S eth0 | grep -i -E 'err|drop|discard|over'
若 ethtool 显示速率未协商到预期（如千兆口协商成 100Mb）或 Duplex 为 Half，或 cat /proc/net/dev 中 errs/drop 持续增长，先解决链路层问题再谈优化。
5.2 软中断与 CPU
# 查看软中断分布，判断网络包处理是否集中在单核 cat /proc/softirqs | grep -i NET # 实时监控 CPU 与中断 top -1 # 虚拟化环境查看 CPU 抢占 vmstat 1
若 NET_RX 软中断几乎全集中在某一个 CPU 且该 CPU 使用率高，可开启多队列（RSS）或 RPS/RFS 把负载分散到多核。
5.3 是否带宽打满
# 按网卡实时查看流量 sar -n DEV 1 # 按进程查看流量（需安装 nethogs） nethogs eth0
带宽打满时的抖动特征是：抖动曲线与流量曲线高度吻合，高峰期抖、低谷期稳。处置方式是扩容或做流量限速与优先级调度。
5.4 协议栈与拥塞控制
# 查看当前拥塞控制算法 sysctl net.ipv4.tcp_congestion_control # 查看可用算法 sysctl net.ipv4.tcp_available_congestion_control # 查看 TCP 缓冲区设置 sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem
对跨洋高延迟链路，BBR 通常在吞吐表现上优于默认的 CUBIC，尤其在存在轻微丢包时。但要注意：BBR 改善的是吞吐，不会降低延迟和抖动，不要指望它解决实时业务的卡顿。
六、抖动排查步骤清单
- 确认现象：明确是持续抖动、周期性抖动还是偶发突刺，记录发生时段与投诉业务类型
- 量化基线：
ping -c 100 -i 0.2，记录 avg、mdev、max、丢包率 - 逐跳定位：
mtr -T -P 80 --report --report-cycles 100，找 StDev 开始变大的跳，用 whois 确认归属 - 排除服务器：
ethtool查协商、cat /proc/net/dev查错包、ss -i查重传、sar -n DEV 1查是否跑满、cat /proc/softirqs查软中断集中 - 跨网段对比：换办公网/家庭网/手机流量、换运营商各测一次
- 晚高峰对比：10 点、21 点、凌晨 2 点三次采样，制表对比
- 双向对比：登录服务器反向
mtr，确认去程回程是否都存在抖动 - 同机房对比：找同机房其他机器或服务商测试 IP 对照
- 路径检查：
traceroute -n -T -p 80看是否绕路 - 归类处置：本地问题联系宽带商；机房内部问题自行处理或报修；上游链路问题提交工单并附 MTR 证据
- 验证闭环：处理后在同一时段同一网络重测，对比 mdev 与丢包率是否改善
- 建立基线：把每日固定时段数据存档，形成可对比的时间序列
七、不同成因的处置对照
| 成因 | 可观测特征 | 处置手段 |
|---|---|---|
| 国际出口拥塞 | 仅晚高峰劣化，去程或回程单向明显 | 换优化回国线路、CDN 分流、错峰传输 |
| 跨网互联瓶颈 | 仅特定运营商用户受影响 | 选择 BGP 多线机房、接入覆盖该运营商的线路 |
| 机房上行打满 | 抖动与流量曲线吻合 | 扩容带宽、限速、流量分级 |
| 网卡/链路层故障 | errs/drop 持续增长，协商异常 | 更换网线光模块、检查交换机端口、联系机房 |
| CPU 或软中断瓶颈 | 单核软中断集中，负载高时抖 | 开启 RSS/RPS、优化中断亲和、扩容 CPU |
| 路由震荡 | 路径在多次测试中不一致 | 提交工单，要求上游排查 BGP 稳定性 |
| 内部任务抢占 | 周期性出现，与备份/同步时间吻合 | 调整任务时间、限速、错峰 |
| 虚拟化 CPU 抢占 | vmstat 中 st 值偏高 | 更换宿主机、选择独享型实例 |
小结
网络抖动的本质是延迟的不稳定，对交互式与实时业务的伤害远大于平均延迟偏高。排查的关键是量化与对比：ping -c 100 -i 0.2 提供 mdev 与丢包基线，mtr --report --report-cycles 100 用 StDev 列定位抖动起始跳，ss -i 从真实连接角度看 RTT 偏差与重传，ethtool 与 cat /proc/net/dev 排除网卡与链路层问题。五个对比维度——逐跳对比、跨网段对比、晚高峰对比、双向对比、同机房对比——能覆盖绝大多数场景，把问题从"网络慢"精确到"某一段链路在某个时段的某个方向"。避坑要点：不要只看平均延迟，很多监控图把抖动平滑掉了；不要把中间跳的 ICMP 限速当成故障，看后续跳是否同样丢包；不要在白天测一次就下结论，晚高峰才是真实水平；不要指望 BBR 或任何拥塞控制算法降低抖动，它们优化的是吞吐；不要忽略回程方向，跨境链路中回程拥塞极为常见。最后，把测试数据按固定条件长期留存，当抖动再次出现时，历史基线会让你在几分钟内判断出"这是新故障还是老毛病"。
本文所述判断阈值为运维经验参考，不同业务对抖动的容忍度差异很大，请结合自身业务设定告警阈值。
企业QQ咨询
