丢包与抖动对视频、语音、游戏分别有什么影响

先给结论：同样的丢包和抖动，在不同应用里是不同的病

丢包和抖动对体验的影响，取决于应用怎样处理“迟到”和“没到”的数据。视频点播有几十秒的缓冲，能吸收大部分波动，最先表现为清晰度下降；语音通话缓冲很短，表现为断续和失真；联机游戏几乎没有缓冲，表现为瞬移、回弹和操作延后；网页与下载使用 TCP，表现为加载停顿和速度锯齿。晚高峰时两者往往同时上升，但你感受到哪一种，取决于当时在用什么。

本文只讲影响，不讲指标定义和计算方法。抖动的算法见 抖动是什么：为什么平均延迟不高也会卡顿，丢包率的测量见 丢包率怎么看，测速指标的总览在 测速指标：延迟、吞吐、丢包与 UDP NAT。本文属于 晚高峰与网络质量影响因素二级专题。

应用怎样应对丢包和抖动

不同应用有各自的“自救手段”，这决定了它们的症状：

表里的“多为”是常见情况，具体应用的实现各不相同。

视频：缓冲越大，越怕持续不足而不怕短暂波动

视频点播会预先下载一段内容。只要平均吞吐高于当前清晰度所需的码率，短时间的丢包和抖动都被缓冲掩盖。晚高峰真正让视频卡的，是吞吐持续不足：播放器测到下载变慢，先降低清晰度，降到最低仍不够时才停下来转圈。所以“晚上画质自动变糊”通常是吞吐问题，而不是抖动问题。

直播不同。为了让观众看到的画面接近实时，直播缓冲很小，抖动会让延迟逐步累积，播放器到一定程度会跳过一段内容追上进度，表现为画面突然跳动。

语音：零星丢包能补，成串丢包补不了

语音把声音切成很短的小包，接收端用抖动缓冲区把它们排好再播放。零星丢掉一两个包，补偿算法可以用前后的声音推测填补，听起来只是轻微失真；连续丢掉一串，就会出现明显的断字。抖动大时，缓冲区要设得更长，对话的整体延迟随之增加，双方容易抢话；超过缓冲容忍度的迟到包会被直接丢弃，效果等同于丢包。

游戏：每个包都要“准时”

联机游戏客户端会根据收到的状态预测其他玩家的位置。包迟到时，预测与实际不符，画面会把角色拉回正确位置，即“回弹”；包丢失时，某次操作可能没有被服务器收到。游戏通常发包频繁、单个包很小，所以它对带宽几乎没有要求，却对抖动和丢包非常敏感。游戏场景还涉及 UDP 与 NAT 等条件，见 联机游戏与语音用机场要看什么。

网页与下载：丢包变成速度锯齿

网页和下载使用 TCP。TCP 会重传丢失的数据，所以内容不会缺，但它把丢包当作拥堵信号，会主动减速再逐步恢复。丢包反复发生时，下载速度呈锯齿状起伏，网页则表现为加载到一半停住、过一会儿又继续。抖动对这类应用的影响相对较小。

代理隧道会改变症状的形态

通过代理时还多了一层变化。若节点用基于 TCP 的方式承载 UDP 数据，隧道内的一次丢包会触发重传，后面所有数据都要等这个包补齐才能交给应用。结果是，原本应该被游戏或语音直接丢弃、自行补偿的包，变成了一段集中的等待：零星的断续变成了周期性的顿挫，丢包被“翻译”成了抖动。

这意味着，同样的链路质量，用不同协议或不同的 UDP 承载方式，实时应用的体验可能不同。协议层面怎样承载 UDP，见 机场节点支持 UDP 吗：协议、服务器与客户端三方条件。

为什么晚高峰时两者往往一起上升

晚间链路某一段开始排队时，最先变化的是延迟的波动，也就是抖动；排队继续加剧、缓冲装满后，才开始出现丢包。所以在同一个晚上，你往往先注意到游戏和语音变差，过一阵才发现下载和视频也受影响。反过来，抖动大而丢包几乎没有，说明拥堵还停留在排队阶段；丢包频繁出现，说明已经有设备在丢弃数据。

用症状反推方向

• 只有视频画质下降、下载慢：先看持续吞吐。
• 语音断续、游戏瞬移，但下载正常：先看抖动和丢包，以及 UDP 是否被正确承载。
• 网页时快时慢、下载速度锯齿：先看丢包。
• 所有应用一起变差且集中在晚间：按 五段链路 的顺序定位拥堵位置。

本文不对任何品牌的丢包或抖动表现做判断。本站各品牌页的测速截图是单次快照，样本量不足以评估抖动和丢包。使用相关服务时请遵守所在地法律法规与平台服务条款。