2. 网络延迟与抖动：延迟的定义、RTT与Ping、抖动对带宽的影响

聊带宽测试，很多人第一反应就是「测速」。但说实话，光看带宽数字，就像只看车速不看路况——你跑得再快，遇到红灯和坑洼照样得停下来。今天我们就来聊聊网络里那两个最容易被忽视、却又最要命的指标：延迟和抖动。

2.1 延迟到底是什么？

延迟，说白了就是数据包从A点跑到B点所花的时间。单位是毫秒（ms）。你想想看，你点一下网页，数据包要从你的电脑跑到服务器，再跑回来，这一来一回的时间就是延迟。

我个人习惯把延迟拆成三部分：

  • 传播延迟：光在光纤里跑的时间。这个物理定律决定，谁也改不了。北京到上海的光纤，光速跑一趟大概5ms，但实际因为折射率，大概要8-10ms。
  • 处理延迟：路由器、交换机处理数据包的时间。这个跟设备性能有关。
  • 排队延迟：数据包在设备缓冲区里排队等待的时间。这个最坑，流量一拥塞，排队时间能暴涨几十倍。

核心观点：延迟不是单一值，它是多个环节的累加。你测到的延迟，往往是这三部分的总和。

2.2 RTT 与 Ping：最常用的测量手段

RTT（Round-Trip Time），往返时间。就是数据包从你这里出发，到达目标，再返回你这里，总共花的时间。注意，是往返，不是单程。

Ping 工具就是基于 RTT 原理工作的。它发送一个 ICMP 回显请求包，目标收到后回复一个回显应答包。Ping 会告诉你每次的 RTT 值，以及丢包率。

我在项目中遇到过一件事：有一次客户说网络慢，我上去一测带宽，100M跑满了，没问题啊。但 Ping 了一下网关，延迟居然有 200ms。再 Ping 外网，直接 500ms+。后来发现是内网有台设备在疯狂发包，把交换机的缓冲区塞爆了。这就是典型的排队延迟导致的假性带宽不足。

# 基本 Ping 测试
ping -c 10 8.8.8.8

# 输出示例
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=11.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=13.1 ms
...
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss
rtt min/avg/max/mdev = 11.5/12.4/14.2/0.8 ms

这里有个细节：mdev 就是平均偏差，它其实就是抖动的雏形。0.8ms 的抖动算正常，但如果 mdev 超过 5ms，你就要警惕了。

我的建议：别只看 Ping 的平均值。重点关注最大值和 mdev。如果最大值是平均值的 3 倍以上，说明网络存在间歇性拥塞。

2.3 抖动：延迟的「忽高忽低」

抖动（Jitter），就是延迟的变化量。你连续 Ping 10 次，每次的延迟都不一样。这些延迟之间的差异，就是抖动。

为什么会这样？因为网络不是一条专用的管道。数据包在路上会遇到各种情况：有的包排队短，有的包排队久；有的包走了不同的路由路径。这些都会导致延迟不一致。

嗯，这里要注意：抖动对实时应用的影响，有时候比延迟本身还大。

应用类型 可接受延迟 可接受抖动 抖动超标的后果
网页浏览 < 200ms < 50ms 页面加载忽快忽慢
视频会议 < 150ms < 30ms 画面卡顿、音画不同步
在线游戏 < 50ms < 10ms 角色瞬移、操作延迟
VoIP 语音 < 100ms < 20ms 声音断断续续、回声

我曾经帮一个游戏公司排查问题。他们的玩家反馈说「角色会突然瞬移」，但带宽测试显示完全够用。我抓包一看，延迟平均值只有 30ms，但抖动高达 40ms。也就是说，有的包 10ms 到，有的包 50ms 到。游戏引擎按照固定间隔渲染，结果就是角色位置来回跳。后来我们给服务器加了 QoS 策略，把游戏流量优先级调高，抖动降到了 5ms 以内，问题解决。

2.4 抖动对带宽的「隐形消耗」

很多人以为抖动只影响体验，不影响带宽。其实不然。抖动会触发 TCP 的拥塞控制机制，间接吃掉你的有效带宽。

TCP 协议有个特点：它通过 RTT 来估算网络状况。如果抖动很大，TCP 会误判为网络拥塞，然后主动降低发送窗口。你想想看，本来能跑 100M 的链路，因为抖动导致 TCP 窗口频繁收缩，实际吞吐量可能只剩 60M。

避坑指南：我曾经在一条卫星链路上做带宽测试，测出来只有标称带宽的 40%。一开始以为是设备问题，查了半天才发现是卫星链路的抖动太大（200ms+），导致 TCP 窗口始终打不开。后来改用 UDP 测试，带宽就正常了。所以，测带宽时一定要同时看抖动，否则你测到的可能只是「TCP 眼中的带宽」。

这里我画了一张图，帮你理清延迟、抖动和带宽之间的关系：

延迟、抖动与带宽的关系 延迟 (Latency) 数据包往返时间 抖动 (Jitter) 延迟的变化量 有效带宽 实际可用吞吐量 不稳定路径 TCP窗口收缩 物理因素 • 光纤距离 • 路由跳数 • 设备处理能力 动态因素 • 队列拥塞 • 流量突发 • 路由变化 影响结果 • 吞吐量下降 • 重传增加 • 应用体验差 高抖动 → TCP 误判拥塞 → 有效带宽降低

2.5 实战中怎么测抖动？

光说理论不行，我给你几个实战命令：

# 1. 连续 Ping 并计算抖动
ping -c 100 8.8.8.8 | grep 'time=' | awk -F'time=' '{print $2}' | awk '{print $1}' | awk '{if(NR>1) print $1-prev; prev=$1}' | awk '{sum+=$1; sumsq+=$1*$1} END {print "抖动(标准差): " sqrt(sumsq/NR - (sum/NR)^2) " ms"}'

# 2. 使用 iperf3 测试 UDP 抖动
iperf3 -c 10.0.0.1 -u -b 10M -t 30

# 输出中会包含 jitter 字段
# [ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
# [  3]  0.00-30.00  sec  35.6 MBytes  9.95 Mbits/sec  2.345 ms  0/25500 (0%)

我的习惯：测抖动时，我会同时跑 TCP 和 UDP 两种测试。TCP 测的是「应用层感受到的抖动」，UDP 测的是「网络层真实的抖动」。两者差距越大，说明 TCP 的拥塞控制越激进。

最后说一句：延迟和抖动，就像网络的「血压」和「心率」。血压高不行，心率不齐更危险。下次做带宽测试时，别忘了带上 Ping 和 iperf 的抖动参数。你会发现，很多「带宽不够」的问题，其实是「抖动太大」在作祟。

想要更多资料，联系可可

← 上一章 📖 返回目录 下一章 →