第2章延迟与抖动

延迟与抖动：网络质量的“体温”与“心率”

做网络运维这些年，我越来越觉得，延迟和抖动就像是网络的“体温”和“心率”。体温高了，系统发烧；心率不齐，业务就抽搐。很多刚入行的朋友，总把这两个概念混为一谈，其实它们完全是两码事。

今天，我们就来把这层窗户纸捅破。我会结合我踩过的坑，把延迟的组成、抖动的计算，以及它们到底怎么影响业务，掰开了揉碎了讲清楚。

延迟，说白了就是一个数据包从A点跑到B点，总共花了多少时间。单位通常是毫秒（ms）。你想想看，从北京发一个包到上海，如果花了30ms，那这30ms到底花在哪了？

我个人习惯把延迟拆成四个部分，这样排障时思路特别清晰：

核心公式：

端到端延迟 = 传播延迟 + 处理延迟 + 排队延迟 + 序列化延迟

我在项目中遇到过好几次，业务方投诉说“网络卡”，我一查延迟才20ms，根本不高。后来才发现，是排队延迟在作祟——瞬间流量一拥而上，队列瞬间堆满，延迟直接飙到200ms。所以，光看平均延迟是远远不够的。

这个最简单。光在真空中的速度是3×10⁸ m/s，在光纤里大约是2×10⁸ m/s。北京到上海直线距离约1000公里，算下来传播延迟就是5ms左右。这个你改变不了，除非你把服务器搬到用户隔壁。

设备查路由表、做ACL匹配，都需要时间。我见过一些老旧设备，处理延迟能到几毫秒，而新一代的芯片，这个数字可以降到微秒级。嗯，这里要注意，如果处理延迟突然变大，大概率是设备CPU爆了。

这是最“调皮”的一个。网络不拥塞时，它几乎为0；一旦拥塞，它就像滚雪球一样越滚越大。我曾经排过一个故障，专线延迟每10秒就跳变一次，最后发现是出口带宽被一个P2P下载占满了，队列深度直接拉满。

这个有个计算公式：序列化延迟 = 包大小（bit） / 链路带宽（bps）。举个例子，一个1500字节的包，在1Gbps链路上，序列化延迟只有0.012ms；但在64Kbps的专线上，这个数字就变成了187.5ms。所以，带宽越小，序列化延迟越明显。

抖动，就是延迟的变化量。说白了，就是延迟的“忽高忽低”。

为什么业务怕抖动？因为很多应用对延迟的绝对值并不敏感，但对延迟的稳定性要求极高。比如VoIP语音，延迟200ms还能忍，但如果延迟在100ms到300ms之间来回跳，那声音就断断续续，根本没法听。

抖动的计算方式，业内常用的是 Jitter = |D(i) - D(i-1)|，也就是相邻两个数据包的延迟差值的绝对值。

我的排障小技巧：

我一般会连续抓1000个ICMP包，然后计算它们的延迟标准差。如果标准差超过平均延迟的20%，基本可以判定抖动异常。这个阈值是我自己总结的，你可以参考。

举个例子：

那么，包2的抖动是2ms，包3的抖动是38ms，包4的抖动是35ms。你看，包3的抖动直接飙到38ms，这就是问题所在。

避坑指南：

我曾经犯过一个错误，只看了平均抖动，觉得才5ms，没问题。结果业务方投诉说视频会议卡顿。后来一查，平均抖动虽然低，但每30秒会有一个瞬间抖动高达100ms。这种“间歇性抽风”最坑人，一定要看抖动的峰值和分布，不能只看平均值。

不同的业务，对延迟和抖动的容忍度天差地别。我整理了一个表格，方便你快速对照：

业务类型	延迟敏感度	抖动敏感度	典型影响
VoIP语音	中（<150ms可接受）	高（<30ms）	声音断续、回声、掉线
视频会议	高（<100ms）	极高（<20ms）	画面卡顿、音画不同步
在线游戏	极高（<50ms）	高（<10ms）	操作延迟、瞬移、掉线
文件传输	低（秒级可接受）	低	传输速度慢，但不会中断
数据库同步	高（<10ms）	中	事务超时、主从延迟
Web浏览	中（<200ms）	低	页面加载慢，但不会报错

你看，VoIP和视频会议对抖动最敏感。我记得有一次帮一家金融客户排障，他们的交易系统延迟一直稳定在2ms，但突然有一天，交易员反映“下单按钮点下去没反应”。我一查，延迟还是2ms，但抖动从0.5ms飙到了15ms。最后发现是核心交换机的一个端口协商成了半双工，导致大量冲突和重传，抖动瞬间爆炸。

所以，我的经验是：延迟决定业务能不能用，抖动决定业务好不好用。 很多运维只看延迟，忽略了抖动，结果业务体验一塌糊涂。

为了让你更直观地理解，我画了一张图，把延迟和抖动的核心逻辑串起来：

这张图把延迟的四个组成部分、抖动的计算方式，以及它们对业务的影响，都串在了一起。你排障的时候，可以对照这张图，一步步定位问题到底出在哪个环节。

好了，关于延迟和抖动的核心概念，我们就聊到这。记住，下次遇到网络卡顿，别光盯着延迟看，多看看抖动，往往能发现意想不到的线索。