排位赛最后十秒，你贴着掩体摸过去，一刀切向对面残血。就在刀锋要碰到的那一帧，画面顿了一下——不是卡死，就是“咯噔”一下，像视频缓冲打了个嗝。等你反应过来，人已经站到你身后了。

你退出游戏，打开测速，45ms，绿的。

这就是云游戏最让人上火的地方：它不给你一个明确的错误码，只给你一股说不清的憋屈。你没法截图举证，只能在群里骂一句“云游戏就是不行”。

问题真不在那个45。平均延迟是“路程有多长”，而让你咯噔的那一下，是“路程忽长忽短”（抖动）和“包裹半路掉了”（丢包）。第03篇我们把延迟拆成七个分量，讲的是均值结构；这一篇讲方差结构和丢失结构。两份数据合起来，才是一份完整的网络体检报告——只看前者，你会得出“网络很好、体验很差”这种自相矛盾的结论。

说句实话，和几个做云游戏体验的朋友聊下来，大家有个共识：团队里九成的精力都花在压平均延迟上，真正劝退玩家的是每小时那几次两百毫秒的尖峰。玩家记不住P50，记得住那一次P99。

这一篇干三件事：把抖动和丢包翻译成玩家能说出口的体感；给出一张“P95抖动/丢包率—游戏品类”的量化映射表，让你拿去当验收标准；最后给一套缓冲区、FEC、重传联动的三档配置。中间会拆Stadia、Parsec、Moonlight三套真实方案，看它们各自怎么在这道坎上做取舍。

先把词翻译成人话。抖动：每一帧数据从服务器发出到你收到，耗时本该稳定，比如一直38ms；但网络里挤、路由跳来跳去，这一帧32ms、下一帧61ms、再下一帧29ms，这个忽快忽慢的幅度就是抖动。丢包：某一帧的数据整个没到，或者到得不完整。

关键在于，玩家不会说“我抖动P95有点高”，他只会说三种话，对应三条完全不同的技术路径。

第一种，追帧感。画面先卡住半拍，然后突然快进一下追上来。这是抖动缓冲被瞬间撑大、再排空造成的。它的阴险之处在于：卡的那半拍里，你的输入还在往服务器送，但画面没跟上，手和眼短暂分家。动作游戏、格斗游戏玩家会立刻怀疑“我明明按了”。

第二种，瞬移感。这多半是丢包。某一帧没到，播放端只能拿上一帧顶着（叫帧保持，或者冻结），等下一帧到了，里面的角色已经移动了一大段。你眼看着对手的模型平滑了一秒，然后“啪”地跳到新位置，像被谁拽了一下。

第三种，糊块感。很多人忽略这个——丢包不总是直接冻画面。视频压缩靠前后帧互相参考，丢一个包，解码器可能让整片区域糊成马赛克、绿块，持续半秒到两秒，直到下一个关键帧（I帧）到来才恢复。RPG、策略游戏还能忍，竞速游戏里你正过弯，画面糊一块，直接上墙。所以I帧间隔（GOP长度）不只是编码参数，它直接决定了你从糊块里爬出来的时间——这是第02篇编码话题在体验侧的直接投影。

把这三件事摆在一起看，你会发现它们的技术诱因、时间尺度、最敏感的品类都不一样：

所以拿一个“丢包率小于1%”去验收云游戏，等于用体温计量血压——指标本身没错，量错了对象。

再讲个真实场景。Moonlight加Sunshine这套自托管方案，社区里有个长盛不衰的帖子：“我家里千兆宽带、延迟8ms，为什么还是偶尔卡？”底下老玩家一句话点破：你Wi-Fi是2.4G还是5G？路由器摆在哪？微波炉一开、隔壁邻居刷视频，抖动直接起飞。带宽是你买套餐时的数字，抖动是你家墙和邻居决定的。云游戏体验抖动，大头在最后一公里，不在玩家引以为傲的带宽。

这一层先记住一句话：三种体感，三种修法。用修丢包的办法去修抖动，或者反过来，都是白花钱。

抖动缓冲区的原理一句话能说完：既然帧到达时间忽快忽慢，那我先攒一小把，等齐了，再按稳定节奏匀速吐出去。播放端就顺了。

但这里有个绕不开的反向关系：攒得越多，抹平抖动的手艺越好，端到端延迟也越大。缓冲区里压着5帧，就是5帧的延迟实打实送给玩家。工程上有个粗略的近似：缓冲深度大致要覆盖你想吸收的抖动幅度，1比1的量级——要吸收30ms的抖动，就得准备30ms左右的缓冲。这不是精确公式，但足够你做第一轮估算。

所以抖动缓冲区本质是一笔延迟税：你交多少税，换多少平滑。

表里的数值是工程经验区间，适用于家庭宽带、5GHz Wi-Fi这类常见接入，不是行业标准，你按自己用户的网络分布再收窄。

现代方案基本都走自适应，但“自适应”三个字是个坑。你写个抖动估计器，按最近几百毫秒的抖动幅度调深度，听着优雅。问题是抖动常常是阵发性的：你估计器反应太快，邻居家开个下载，缓冲猛地撑到80ms，网络稳了它还没缩回来，玩家手感“木”一阵；反应太慢，真正的尖峰来了没接住，画面照样糊。

行业的常见做法是六个字：扩得快，缩得慢。看到前面堵，提前减速；路况好了，别立刻猛踩油门，因为随时会再堵。给玩家的体验应该是“有点黏，但永远不卡”，而不是“大部分时候很爽，偶尔脸滚键盘”。具体到参数：扩容通常希望在100ms内到位，收缩用2到5秒的时间常数慢慢往回蹭——这两个数是经验值，你得按自己用户的网络分布再调。

还有个容易被忽略的联动：抖动缓冲和码率自适应抢的是同一份延迟预算。第06篇讲过，自适应码率降码率要时间，缓冲区扩深度也要时间，两个同时动作，延迟会叠着涨。做云游戏别把它们当两个独立模块调，得放在一张预算表里算。你有多少延迟预算，先分给谁，再分给谁，这个顺序比单个参数调得多精细更重要。

真实方案怎么选？Stadia偏保守，Parsec偏激进，Moonlight把旋钮交给用户——这三家的完整拆解放在后面案例段，这里先记结论：缓冲深度没有“正确值”，只有“对这个品类、这群用户、这张网的正确值”。

抖动缓冲是在“时间”上做文章，丢包恢复是在“信息”上做文章。玩家丢了一帧怎么办？行业里两个基本流派，性格相反。

ARQ，自动重传请求，理解成“丢了再要”。你发现第37帧没到，通过反向通道告诉服务器“再来一遍37帧”，服务器补发，你收到接着播。逻辑简单，带宽省——只有真丢了才重发。代价是至少多花一个网络往返时间。局域网20ms，无感；跨省公网60ms，等你补到37帧，42帧都快到了，画面上你已经撞墙了。所以ARQ不是不能用在云游戏，是它有个硬条件：剩余缓冲时间得大于一个往返加处理时间，否则救了也白救。

FEC，前向纠错，理解成“多带备份”。服务器不傻等你要，主动多发冗余。比如每10帧额外带1到2帧的纠错信息，丢了1帧，接收端自己算出来，不用回话。杀手锏是不依赖往返、没有额外延迟，本地秒级救回。代价是多占带宽：1%丢包的网络，为了保险可能要准备5%到10%的冗余，移动网络上行吃紧时这笔钱不小。

这俩的关系，打个比方：ARQ像门卫发现快递少了一件，打电话让快递员再送一趟；FEC像你出门顺手多带一把伞，突然下雨也不用回家拿。前者省事但要等，后者要背但不耽误。

云游戏怎么选？答案是别选，轮班。落地大概这么几条：

按帧的重要性分级。I帧和关键参考帧丢了，后面一串都废，值得用FEC加ARQ双保险；普通P帧丢一帧，靠FEC或帧保持顶过去就行，别为它等一个往返。第02篇讲过参考帧结构，这里就是它在传输层的用法。

冗余率动态化。用一个滑动窗口估计当前丢包率，乘个系数（经验上1.5到2倍）算出冗余率，再设上下限，比如最低3%、最高30%。丢包突然涨，冗余跟着涨；网络干净了慢慢退回去，别一直背着30%的带宽走路。

重传请求延迟发。收到丢包信号别立刻喊重传，等半个到一个往返，给FEC一个自己恢复的机会。很多时候FEC已经算回来了，你这一喊反而重复请求。这个技巧在WebRTC系里很常见（第11篇聊过它的重传机制），云游戏把它拿来用没毛病。

重传要去重、要合并。同一个包被多个解码单元依赖，别发多次请求；服务器侧对重传请求做合并，避免一次丢包引发请求风暴。

该放弃就放弃。上面那个硬条件再强调一遍：剩余缓冲时间不够一个往返，ARQ直接关掉，省下带宽给FEC。判断逻辑用自然语言说就是：这帧还能等多久，够不够一来一回，不够就别等。

私有协议在这块的自由度更大，第14篇拆过Parsec、Moonlight这些方案在确认、重传、加密位置上的不同选择——同样一套FEC加ARQ，放在协议栈的哪一层，效果差很多。

前面三层都在讲机制，这一层干一件策划最该干的事：把定性变成可验收的数字。

先说清楚这些数字怎么来的，免得你拿去当圣经。三个来源：一是第03篇梳理过的品类端到端延迟容忍区间（FPS大约50到70ms、格斗更严、竞速80到100ms、RPG和策略宽松得多），抖动和丢包本质上是在吃这份延迟预算；二是公开评测和平台官方网络建议里的经验值，各家云游戏对带宽、丢包、抖动都有推荐门槛；三是第29篇会讲的视听同步研究——大脑对音画不同步的融合窗口大概在正负30ms量级，超过就开始“感觉怪”。下面这些区间是综合这三者给的经验带，用于产品验收和调参起点，不是学术定论。测试方法放在表后面。

两个表要合起来看，因为抖动和丢包是相乘的，不是相加的。抖动大的时候，你的缓冲已经被撑满，留给重传的时间更少；同样1%的丢包，在P95抖动20ms的网络里可能只是偶发糊块，在P95抖动60ms的网络里就是连续瞬移。这也是为什么很多团队单独看每个指标都“达标”，合起来体验却一塌糊涂。

再说测量。抖动别用平均往返时间，要采帧到达间隔或往返时间序列，取P95和P99，窗口给30秒到1分钟，太短会被一次波动带偏。丢包要分两层看：网络层丢包（抓包能看到）和应用层丢帧（解码器发现参考帧缺失），后者才是玩家真正感知到的。测试注入可以用网络损伤工具模拟固定抖动、随机丢包和突发丢包三种模式，别只测随机丢包——真实世界里的丢包经常是成串来的。

主观侧的验证，建议配第10篇那套方法做配对比较：同一段录像，一组加20ms抖动，一组加50ms，让玩家盲选哪个“更能接受”。你会发现玩家的主观阈值往往比你想的更严，尤其是格斗和音游玩家。

这张表的正确用法不是贴墙上，是写进验收清单：新版本上线前，跑一遍弱网矩阵，看目标品类的格子有没有变红。红了就别发，或者先降级。

Stadia：稳定优先，把税交在前面。Stadia当年有两个设计很典型：手柄直接连Wi-Fi、绕过本地设备，目的是砍掉输入段的一截延迟；视频侧则偏保守，连接时做带宽和延迟探测，动态设码率和缓冲深度，弱网下优先保画面不崩。据当年Digital Foundry等公开评测，良好网络下端到端大致在100到150ms量级（不同游戏差别不小），画面稳定性口碑不错，但输入手感被硬核玩家反复吐槽“看着很干净，打起来飘”。设计意图很清楚：客厅大屏、手柄休闲玩家、降低售后麻烦。收益是首次体验一致、弱网不崩；代价是把延迟税交在了手感上。社区里那句“Stadia画面最好，但打FPS不对劲”，基本就是这笔账的注脚。它最后关闭的原因很多（第01篇拆过），但“稳定压过手感”这个取舍，值得每个做云游戏的人重新算一遍。

Parsec：手感优先，缓冲压到薄。Parsec走的是另一头：自研UDP传输、低延迟编码配置、薄抖动缓冲，网络自适应很激进，目标就是把输入回声压到最低。它起家于远程桌面，游戏是顺带做的，所以对“操作跟手”这件事有执念。好网络下它的口碑是“最快”，局域网里几乎接近本地；代价是对烂网络非常不客气，Wi-Fi一抖、丢包一涨，画面花屏和卡顿来得比谁都直接。Reddit上常见的评价是“Parsec快是快，Wi-Fi下容易炸”，这句话很准确——它不是不会处理弱网，是主动选择不为一小部分弱网用户牺牲大多数好网络用户的手感。做产品时这个取舍很值得学：你得知道自己在为谁优化，以及愿意放弃谁。

Moonlight加Sunshine：把旋钮交给用户。这套开源方案逆向自NVIDIA的GameStream协议，跑在局域网为主，编码用硬件编码器，协议里给了FEC百分比、码率、帧节奏这些可调项，让用户自己按网络调。它的收益很实在：局域网里延迟能做到很低，画质码率自己定，HDR、AV1这些新特性社区往往比商业平台先上（第27篇专门聊这个生态）。代价也明显：公网访问要端口转发、打洞或者VPN，安全自己负责；对家庭网络质量极度敏感。社区里“千兆还卡”的帖子，答案十有八九是Wi-Fi信道、路由器性能或者后台下载，而不是带宽不够。Moonlight的意义不在于它比商业平台强，而在于它把“抖动和丢包到底怎么影响体验”这件事，赤裸裸地摆在了用户面前——参数调错一次，你就全懂了。

下面这张表是给工程和策划一起看的。三档覆盖常见网络形态，每档给一组联动参数：缓冲门限、FEC冗余率、重传策略。再次强调，数值是工程经验区间，不是标准答案，适用网络写在第二列，你按自己用户的分布调。

怎么用：先给用户分档（可以首次连接探测自动分，也可以让用户手动选“流畅优先/画质优先”），按档位设初始值，运行中根据实测抖动和丢包在档位内微调。FPS和格斗游戏默认往A靠，RPG和策略可以往C靠——同样是云游戏，品类不同，容忍度差一个档。

验收指标别只看平均延迟，建议盯三个：卡顿事件率（每分钟超过200ms的卡顿次数）、输入回声P95、糊块持续时长。这三个数比一个漂亮的平均延迟更能预测留存。

最后提醒一句：这张表是起点，不是终点。真上线以后，拿真实用户的网络分布回填门限，你会发现A档和B档的边界经常要挪，因为你的用户不是按运营商套餐分布的，是按“家里路由器摆在哪”分布的。

初级用户速览。如果你不是网络工程师，只想知道结论，记住五句话。一，平均延迟是广告，P95抖动和丢包才是体验。二，先修最后一公里——有线换Wi-Fi、2.4G换5G、路由器别塞柜子里，比任何协议优化都立竿见影。三，抖动缓冲是一笔延迟税，开得越大越稳也越黏，别默认拉满。四，FEC保随机小丢包，ARQ救关键帧，指望一个包打天下行不通。五，拿上面的映射表当验收标准，别拍脑袋说“能玩”。

进阶深入。如果你要动手调，顺序建议这样：先测网络分布（用户都用什么网、抖动和丢包的P95是多少），再定档，再调缓冲，再配FEC，最后接ARQ和码率自适应。指标定义要统一：帧间隔P95和P99、丢包突发长度、卡顿事件率、输入回声，四个都得有，缺一个你都会在复盘时吵架。

和本系列其他篇目的配套关系也理一下：第03篇测的是延迟均值与七个分量，这一篇测的是方差和丢失，两套数据合起来才是完整体检；第06篇的码率自适应会和缓冲抢延迟预算，要一起调；第10篇的主观评估用来验证你调出来的参数玩家买不买账；第11篇和第14篇讲传输协议，FEC和ARQ具体放在哪一层，那两篇是参考答案。

A/B测试别只切一个参数，缓冲、FEC、码率是一组，一起切，看留存、退出率、主观评分三个指标。单独切缓冲，你很难分清效果是缓冲带来的还是那几天网络波动带来的——这种误判我在项目里见过不止一次。

还有个真争议：FEC该不该默认开？一派主张默认小冗余（比如5%），用一点带宽换稳定，用户感知不到；另一派主张按需开，网络好的用户不该为别人买单，而且冗余会影响码率自适应的判断。我的看法偏前者，但有个前提——冗余率要能动态退回去，别一直背着。这事没有标准答案，取决于你的用户网络分布和商业模式（按流量计费还是包月）。

抖动缓冲区到底开多大？看两个东西：你的P95抖动，和你的品类。经验上缓冲深度覆盖P95抖动再留一点余量，FPS和格斗往20到35ms压，RPG和策略可以放到60到120ms。别死记数字，先测再定，而且一定要做成可动态调的。

家里千兆宽带还是卡，怎么排查？先换有线对比，如果有线好了，问题在Wi-Fi：信道拥挤、2.4G干扰、路由器性能、摆放位置。再看后台有没有下载占满上行（云游戏对上行也敏感）。还卡就抓包看抖动和丢包，而不是看带宽。千兆是车道宽度，抖动是路上有多少车在别你。

为什么平均延迟很低，玩起来还是顿？因为平均值骗人。顿的那几下来自尾部：P95和P99抖动、突发丢包、帧保持、编码队列堆积，甚至垂直同步。把测量窗口拉长，看卡顿事件率和P99，你大概率能找到那几下。

用5G玩云游戏，丢包怎么办？5G的麻烦是抖动和切换，不是带宽。尽量在信号好的地方玩，别移动中玩；开FEC、降码率、锁帧率；如果平台支持，选离你近的节点。别指望5G能给你和有线一样的稳定性，那是两回事。

FEC和ARQ能都开吗？会不会打架？能，而且应该都开，但要分级和去重：关键帧双保险，普通帧只靠FEC；重传请求延迟发，给FEC留恢复时间；剩余缓冲不够一个往返时，直接关ARQ。打架往往不是因为都开，是因为没分级、没预算。

有个反直觉的观察：网络越好，抖动缓冲越该小；但产品越成熟，越该给用户一个“稳定性优先”的开关。因为你不是在优化一张网，你是在优化一群人的预期——硬核玩家宁愿偶尔卡一下也要跟手，休闲玩家宁愿黏一点也不要看到花屏。同一套参数服务不了两种人。

留个问题给你：如果有一天P95抖动真能做到10ms以内，抖动缓冲还需要吗？还是说，那时新的瓶颈会变成编码队列、渲染帧时间，或者别的什么我们现在还没认真看的东西？

抖动和丢包讲完了，下一篇聊画质——糊到什么程度算不能忍，那是另一套量化方法，也是另一群玩家的底线。