先讲一个所有指标都解释不了的卡顿
有用户来问过一个问题：他把 QuickQ 的节点列表翻了一遍，挑了一个延迟 38ms、负载 24% 的节点，数字都比自动推荐的那个更漂亮。结果用了半天，反而觉得比自动推荐还卡。看剧的时候画面一顿一顿，开语音的时候对方说"你声音有点断续"。
他以为是节点的问题，换了一个；新节点数字同样漂亮，症状依旧。最后切回自动选路，反而一切正常。
这个现象用"延迟"和"负载"都解释不了——他的数字确实很好。真正的原因，藏在他没看的那两个指标里：抖动和丢包。
延迟、抖动、丢包，这三个词经常被混在一起说，但它们描述的是三件完全不同的事。要理解它们的区别，可以借一个生活里的场景：把网络传输想象成快递配送。
三个指标，三种性格
先用一句话把三个指标各自描述什么讲清楚，后面每一节再展开。看完这三句话，你对它们的区别就有一个大致轮廓了。
这三个数字各自独立，而且经常"背道而驰"。一个延迟很低但抖动很大的连接，用起来会比一个延迟中等但非常稳定的连接更难受。这就解释了开头那个用户的情况——他看到的是"平均配送时间"，但没看到"配送时间忽长忽短"这个更关键的问题。
延迟：它是平均值，而平均值会骗人
延迟是最常被关注的指标，因为它最直观——"从发出去到回来，用了多少毫秒"。数字越小越好，这个理解没错，但有个前提容易被忽略：延迟是一个平均概念。
延迟描述的是"整体速度水平"
它告诉你一条路平均要花多久，但不告诉你这条路稳不稳回到快递的比喻。假设你收到了 10 个包裹，配送时间分别是：46、45、47、44、46、45、46、45、47、44 毫秒。平均下来是 45.5ms。这个连接非常稳定，你的体验会是"顺滑"。
换一个场景。同样 10 个包裹，配送时间是：20、80、25、90、18、85、22、88、30、80 毫秒。平均下来也是 52ms 左右，看起来数字也还行。但用起来是什么感觉？快的时候飞快，慢的时候特别慢。看视频会一顿一顿，开会时声音会时断时续。
这两种连接，平均延迟接近，但体验天差地别。区别就在于"稳定性"，也就是抖动。
什么时候延迟最重要
延迟对"每一步都要等回应"的场景影响最大。比如网页点击、搜索、翻页——这些操作是"一步接一步"的，每步都要等结果。延迟高，每一步都会慢一点，累积下来就很明显。
实时对战游戏也很在意延迟，但它的机制有点特别：游戏会在你操作之前就预测你下一步要做什么，用"预测"来弥补延迟。所以延迟稍高一点，游戏依然可以玩得下去。真正会让游戏变得不可忍受的，往往不是延迟本身，而是抖动。
抖动：最被低估，也最影响"流畅感"
抖动衡量的是"延迟的波动幅度"。延迟稳定在 45ms，抖动接近 0；延迟在 20 到 90 之间反复横跳，抖动就很大。这个指标在很多客户端里不直接显示，但它对体验的影响，可能比延迟本身还大。
抖动描述的是"节奏的稳定性"
它决定了音视频这种连续性内容能不能"顺下去"想象你正在听一场音乐会。如果乐队的节奏一直很稳，只是整体慢了一点点，你不会觉得难听。但如果节奏忽快忽慢，就算平均速度刚好，音乐也会听起来一团糟。抖动就是那个"节奏"。
为什么抖动对音视频是致命的
视频和音频是一串有严格顺序的数据包，播放器必须按顺序、按节奏把它们播出来。为了应对网络波动，播放器会设置一个"缓冲区"，先把收到的数据存一会儿再播放。这样即使某个包晚到了一点，也能从容地播出来。
但如果抖动太大，超过缓冲区的容量，播放器就撑不住了——要么暂停等数据（视频转圈），要么丢掉来不及播的帧（画面卡一下）。这就是为什么看剧时"画面一顿一顿"，根源往往不是延迟高，而是抖动大。
抖动也影响游戏手感
游戏里，你每一次操作都需要立即发送到服务器，服务器再返回结果。如果抖动大，会出现"有时候响应特别快、有时候特别慢"的情况。手感上就是"操作忽灵忽不灵"，比稳定的高延迟更让人抓狂。
有些射击游戏里，玩家会形容这种手感为"黏键"——不是按下去没反应，而是反应忽快忽慢，完全没法形成肌肉记忆。
特别提醒：如果客户端显示的延迟只有 45ms，但你用起来明显觉得"顿"，那大概率是抖动在作怪。这时候换一个延迟稍高（比如 55ms）但更稳定的节点，体验往往反而更好。
丢包：最直接，也最容易被误解
丢包是三个指标里最"狠"的一个。它指的是数据包在传输途中丢失，没有到达目的地。延迟高是"慢"，抖动大是"不稳"，而丢包是"东西没了"——性质完全不同。
丢包描述的是"完整性"
丢一点点可以补救，丢多了就彻底崩继续用快递比喻。假如你买的是一本书，物流分成了 5 个包裹寄出。如果丢了 1 个，书就不完整了，你得联系卖家补发。如果 5 个全到了但次序乱了，你拼一下也能读。
网络里的情况类似。传输协议会对丢包做"重传"——发现某个包没到，就再发一次。1% 以内的丢包，经过重传基本感受不到。但一旦丢包率超过 3%～5%，重传本身的负担就开始累积，速度明显下降。
丢包对不同场景的影响完全不同
大文件下载对丢包比较宽容——重传一次，慢一点，但不会断。丢包率 2% 的情况下，下载速度会掉一点，但文件最终会完整下完。
视频播放对丢包比较敏感。丢一个关键帧，画面可能就花一下；丢几个连续包，就会出现明显的马赛克或卡顿。
语音和视频通话对丢包最敏感。音频包里几毫秒的内容丢了，重传来不及，就只能"填充"——听感上就是声音突然断了一下，或者变成了机械音。
实时对战游戏则介于两者之间。玩家操作的数据包如果丢了，重传是有意义的（虽然慢了一点，但操作生效了）；但如果丢的包太多，重传都来不及，就会出现"按了没反应"或者"角色瞬移"的情况。
一个小知识：QuickQ 的传输层做了丢包补偿机制。对于实时性强的流量（比如语音、游戏），它会优先用前向纠错的方式"猜"出丢失的内容，而不是等重传；对于可容忍延迟的流量（比如下载），则走重传路线。这就是为什么同一网络状况下，不同场景的体验差异会很大。
谁最致命？看场景，不看数字
三个指标没有"谁永远比谁更重要"的说法，关键看你正在做什么。下面这张表按常见使用场景列出优先级，可以对照着看。
| 使用场景 | 最怕 | 次怕 | 原因 |
|---|---|---|---|
| 视频会议 | 抖动 | 丢包 | 声音不能忽快忽慢，画面不能出现马赛克，稳定性压倒一切 |
| 实时语音 | 抖动 | 丢包 | 人对声音节奏变化极其敏感，抖动直接毁掉通话质量 |
| 实时对战 | 抖动 + 丢包 | 延迟 | 延迟可以被预测机制补偿，但抖动和丢包会带来"不可预测" |
| 4K 流媒体 | 丢包 | 抖动 | 丢包导致画面马赛克，抖动则影响缓冲能否稳定填充 |
| 大文件下载 | 丢包 | — | 延迟高低无所谓，丢包太多会让重传拖垮速度 |
| 网页浏览 | 延迟 | 抖动 | 每一步都要等回应，延迟累积效应明显 |
| 学术检索 | 丢包 | 延迟 | 大量并发请求，丢包重传的代价会被放大 |
如果你只想记一句话：连续性的场景（视频、语音、会议）最怕抖动；突发性的场景（点开、下载、检索）最怕丢包；交互性的场景（浏览、点按）最怕延迟。
从症状反推：你遇到的到底是哪一种卡
如果不确定自己遇到的是哪个问题，可以从"感受到的症状"出发，往下找对应的原因。这是最实用的诊断方法——你不需要看数字，只需要观察自己的使用体验。
典型症状是"能看，但不够顺"。延迟数字可能看起来正常，但连续画面偶尔会卡一下再继续。
大概率是抖动语音的连续性最强，对抖动最敏感。丢包也会造成类似症状，但丢包通常是"突然消失半句话"，而抖动是"持续性的不流畅"。
抖动或丢包这是丢包的典型表现。画面上的马赛克就是"某帧数据没收到，播放器用猜测的内容顶了一下"。恢复得越快，说明重传越及时。
丢包游戏对抖动和丢包都非常敏感。如果延迟数字正常但手感不对，先怀疑抖动；如果偶尔出现"按了没反应"，那可能是丢包。
抖动 + 丢包这是延迟的典型表现。网页浏览是"每一步都等"的模式，延迟高会明显被感知到，抖动和丢包的影响相对较小。
延迟偏高可能是丢包重传导致的效率下降。下载对延迟不敏感，但对丢包极其敏感——每丢一个包就要重传一次，速度自然上不去。
丢包综合性的"变钝"，通常是多个指标同时有一点恶化。优先考虑换一个更空闲的节点，或者让它跑一会儿自动选路重新评估。
综合，建议自动选路把症状和原因对上，你就能大致判断该往哪个方向调。比如怀疑抖动，可以换一个延迟略高但更稳定的节点；怀疑丢包，可以换一个出口质量更好的节点；怀疑延迟，可以换一个离你更近的节点。
关于这三个指标，几个常见误区
除了"混为一谈"这个根本问题，还有几个细节容易被误解。
小结：从"看数字"到"看体感"
回到标题里的那个问题——"三个指标哪个最影响体验？"答案是：取决于你在做什么。但有一个更重要的认知升级：从"只看延迟"变成"结合场景看三个指标"，你的判断力会直接上一个台阶。
可以带走的四句话
- 延迟是平均值，抖动是稳定性，丢包是完整性。三者描述三件不同的事。
- 连续性的场景最怕抖动，突发性的场景最怕丢包，交互性的场景最怕延迟。
- 延迟稍高但更稳定的节点，往往比延迟低但抖动的节点体验更好。别被数字迷惑。
- 不确定问题在哪，就从症状反推。画面马赛克是丢包，声音断续是抖动，点一下慢半拍是延迟。
如果看完这篇，你对"为什么明明延迟不高但还是卡"这件事有了新的理解，那么回到 节点选择 那篇，你可能会发现很多新的角度——那篇讲的是"选哪个节点"，这篇讲的是"为什么这个节点用起来是这个感觉"。两篇配合看，你对自己网络的状况，会有一套完整的判断方法。
如果遇到具体的连接问题不知道怎么办，可以看 连接排查 那篇，里面有一套按顺序自查的流程。
