游戏用 UDP 传输，丢包了怎么办？｜阿里巴巴测开面经解析

60 秒回答模板

游戏用 UDP 传输时，丢包不能只回答“重传”，因为游戏网络的核心矛盾是实时性和可靠性的取舍。我的思路是先给每个数据包或逻辑消息加序号、时间戳和类型标识，接收端用序号判断丢包、乱序和重复。对于高频、可覆盖的状态同步数据，比如玩家位置、朝向、速度、动画帧，丢了通常不重传，因为旧状态到了也已经过期，可以直接等待下一帧快照，通过客户端预测、服务端快照插值、平滑纠偏来掩盖抖动。对于必须到达的重要消息，比如开火指令、技能释放、伤害确认、背包变化、结算结果，则在 UDP 之上做应用层可靠机制，使用 ACK、超时重发、选择性重传、消息去重和顺序控制。对于弱网或高丢包场景，还可以发送冗余状态、关键字段重复携带，或者用 FEC 用额外校验包恢复少量丢包。最终不是让 UDP 变成 TCP，而是按消息重要性分层处理：不重要的丢弃，过期的覆盖，关键的可靠送达，并严格控制重传带来的带宽和延迟成本。

考点 先明确为什么游戏偏向 UDP

主线 丢包要按消息价值分类

易错点 只回答“丢包就重传”，没有区分实时状态和关键事件的不同…

深入解析

先明确为什么游戏偏向 UDP

游戏选择 UDP 的原因不是它更可靠，而是它没有连接维护、拥塞控制和队头阻塞这些默认行为，更适合实时交互。游戏里的大量数据是状态流，例如位置、朝向、速度、技能前摇、动画状态，这些信息价值会随时间迅速衰减。一个 200 毫秒前的位置包即使重传成功，也可能不如直接使用最新快照。因此处理丢包时首先要承认：游戏网络的目标不是所有包都到，而是让玩家看到的世界尽量及时、连续、可信。

丢包要按消息价值分类

面试中不能把所有 UDP 包都按同一种方式处理。第一类是可丢弃的高频状态，例如移动同步和朝向同步，下一次快照会覆盖旧数据，重传意义很小。第二类是可冗余的重要状态，例如血量、当前武器、技能冷却，可以在后续包里重复带上最新值。第三类是必须可靠的事件，例如购买道具、匹配成功、伤害结算、任务奖励，这类数据丢了会造成状态不一致，必须在应用层实现确认、重传、去重和必要的顺序控制。

序号、时间戳与快照是基础

UDP 不保证顺序，所以应用层通常会给包加递增序号、发送时间戳、快照编号或逻辑帧号。接收端可以根据序号发现缺口，判断是否丢包，也可以丢弃已经过期或重复的包。服务端定期下发权威快照，客户端维护一个快照缓冲区，在较新的状态之间插值，避免对象瞬移。对于乱序到达的数据，如果序号落后于当前已处理状态，一般直接丢弃；如果是可靠消息，则进入重排、确认或补发流程。

ACK、NACK 与选择性重传

关键消息需要在 UDP 之上做轻量可靠传输。常见做法是发送端为可靠消息分配消息序号，接收端返回 ACK 表示已收到；如果发现中间缺失，也可以通过 NACK 请求补发。为了避免每个包都单独确认带来过多开销，ACK 往往会合并到后续上行或下行包中，并携带最近收到的最大序号和一个位图，表示某一段范围内哪些包已收到。这样发送端可以做选择性重传，只补真正缺失的消息，避免把已经收到的数据重复发送。

高频状态通常不重传

对于玩家移动、怪物位置、弹道中间状态这类高频数据，丢包后的优先方案通常不是补包，而是等待新快照、预测和插值。客户端可以根据上一次位置、速度和输入进行短时间预测，使本地操作立即有反馈；服务器返回权威状态后，客户端再进行平滑纠偏。其他玩家或远端对象则常用插值，让客户端稍微延迟展示一小段时间，从缓冲区取两个快照之间的状态，这样即使偶发丢包，也能保持连续运动。

冗余与 FEC 用来减少重传依赖

在移动网络或跨地区网络中，等待重传可能已经错过实时窗口，所以可以用冗余和 FEC 降低丢包影响。冗余是把关键状态在连续多个包中重复携带，例如最近一次血量、状态标记、技能阶段，丢一个包仍可从后续包恢复。FEC 则是发送额外校验数据，让接收端在少量包丢失时通过剩余数据恢复，不必等待发送端重传。但冗余和 FEC 都会增加带宽，因此通常只用于关键状态或高丢包环境，不能无节制开启。

状态同步与一致性由服务端兜底

游戏网络一般不能完全相信客户端，尤其是竞技或交易相关逻辑。客户端预测主要解决手感，权威结果仍应由服务端计算。丢包导致客户端本地状态偏离时，服务端快照会把状态拉回正确结果；为了避免突兀跳变，客户端会做平滑修正。对于背包、货币、结算、排行榜等强一致场景，不应该只靠状态覆盖，而应走可靠消息或请求响应流程，确保服务端处理成功、客户端确认展示，并能处理重复请求。

带宽与时延是最终权衡

所有可靠化手段都有代价。重传会增加时延，ACK 和 NACK 会占用带宽，冗余和 FEC 会提高流量，过大的缓冲会让运动更平滑但操作反馈变慢。优秀的设计不是把 UDP 包装成完整 TCP，而是按业务重要性设置不同策略：实时状态宁可丢旧保新，关键事件必须可靠到达，弱网场景动态降低同步频率或减少非关键对象更新。面试回答要体现这个取舍意识，而不是只停留在协议概念。

易错点

只回答“丢包就重传”，没有区分实时状态和关键事件的不同处理策略。
把 UDP 可靠化理解成完全复制 TCP，忽略游戏最怕队头阻塞和延迟堆积。
没有提序号、时间戳、快照编号，无法解释如何发现丢包、乱序和重复包。
忽略客户端预测、服务端快照、插值和平滑纠偏，只从传输层角度回答问题。
对所有消息都使用可靠通道，导致高频位置同步在弱网下越积越多、越补越慢。
只强调省带宽，不说明冗余和 FEC 在高丢包实时场景中的价值与代价。

面试官追问

UDP 丢包后为什么不直接全部重传？

因为游戏数据大量具有时效性。移动位置、朝向、动画帧等信息一旦过期，补回来价值很低，甚至会造成回退、抖动和队列堆积。全部重传会把网络延迟越拖越大，破坏实时性。更合理的做法是只对关键事件可靠化，对高频状态使用新快照覆盖旧状态。

如何发现 UDP 包丢了？

应用层可以给每个包或消息加递增序号、逻辑帧号和时间戳。接收端发现序号不连续，就能判断中间存在丢包；如果后续又收到较小序号，则说明乱序或重复。对于普通状态包，可以丢弃过期数据；对于可靠消息，可以记录缺口并触发 NACK 或等待超时重传。

ACK 和 NACK 在游戏 UDP 中怎么用？

ACK 表示某些可靠消息已经收到，发送端可以停止保留这些消息；NACK 表示接收端发现某些序号缺失，希望发送端补发。实际实现中通常不会每条消息单独发确认，而是把确认信息合并到后续包里，并用序号加位图表达一段范围内的接收情况，从而支持选择性重传。

客户端预测和服务端快照如何配合？

客户端预测用于让玩家输入立即产生反馈，例如按下移动键后本地角色马上移动。服务端仍然周期性下发权威快照，客户端收到后比较本地预测状态和服务端状态。如果偏差较小就平滑修正，如果偏差较大则回滚或强制校正。这样既保证操作手感，又避免长期状态不一致。

插值和预测有什么区别？

预测是根据输入、速度或物理规则估算未来状态，常用于本地玩家以降低操作延迟。插值是在已经收到的两个历史快照之间取中间状态，常用于展示其他玩家或远端对象。预测强调即时反馈，可能需要纠偏；插值强调平滑稳定，通常会引入很小的展示延迟。

FEC 和重传相比有什么优缺点？

重传只在确实丢包后补发，带宽相对节省，但需要等待发现丢包和补包到达，延迟较高。FEC 提前发送额外校验数据，少量丢包时接收端可直接恢复，减少等待时间，但会持续消耗额外带宽。实时游戏通常会在高丢包或关键状态上谨慎使用。