游戏帧同步设计：原理、取舍与落地细节

帧同步不是“把每一帧的状态发给所有客户端”，而是让所有客户端在同一套规则下处理同一批输入。它看起来节省网络流量，真正难点却在确定性、弱网处理、预测回滚和异常恢复。

目录

• 一、先说清楚：帧同步解决的是什么问题
• 二、帧同步的基本模型
• 三、帧同步不等于服务器不管状态
• 四、网络层：UDP、KCP 与 ACK 的边界
• 五、客户端上传的不是“操作结果”，而是输入意图
• 六、服务器固定帧推进：不要被弱网玩家拖住
• 七、下发帧数据：让客户端知道这一帧为什么这样算
• 八、预测、输入延迟与回滚
• 九、确定性：帧同步最容易被低估的部分
• 十、状态 Hash：用来发现问题，不是用来投票裁决
• 十一、快照与断线重连
• 十二、推荐落地路线
• 十三、总结

一、先说清楚：帧同步解决的是什么问题

多人游戏的同步方式大体可以分成两类：

一种是状态同步。服务器计算权威状态，然后把角色位置、血量、技能结果、投射物位置等状态同步给客户端。客户端更多负责表现、插值、预测和修正。

另一种是帧同步。服务器不频繁下发完整游戏状态，而是按逻辑帧收集玩家输入，再把每一帧的输入广播给所有客户端。所有客户端拿到相同输入后，用相同逻辑模拟，得到相同结果。

帧同步适合这些场景：

• 玩家数量相对可控。
• 游戏对象数量较多，但输入量较小。
• 需要完整回放或战斗复盘。
• 客户端逻辑可以做到高度确定性。
• 游戏能接受输入延迟或预测回滚。

它不一定适合这些场景：

• 强依赖复杂物理引擎，且物理结果跨平台不稳定。
• 大世界 MMO 这种对象数量、视野范围和玩家连接状态非常复杂的场景。
• 服务器必须实时掌握完整权威状态，但又不愿承担服务器模拟成本。
• 客户端逻辑难以统一，比如不同平台使用不同运行时、不同浮点行为。

所以，帧同步不是“更高级的同步方案”，而是一种取舍：它用更低的状态带宽，换来对确定性、输入管理和异常恢复更高的要求。

二、帧同步的基本模型

帧同步的核心流程可以概括为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

客户端采集本地输入
    |
    v
上传输入到服务器
    |
    v
服务器按固定 tick 聚合输入
    |
    v
生成第 N 帧的输入集合
    |
    v
广播给所有客户端
    |
    v
客户端按第 N 帧输入推进本地模拟

这里同步的是输入，不是结果。

例如玩家按下技能键，客户端不应该上传“我打中了敌人，造成 100 点伤害”，而应该上传“我在第 1024 帧释放了技能 3，目标是 entity_15，释放方向是 dir”。至于是否命中、造成多少伤害、是否触发暴击，都应该由同一套战斗逻辑在各端算出来。

一个最小的帧同步模型通常包含：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

InputMessage:
  playerId
  inputSeq
  clientFrameId
  operationData
  clientTime
  receivedServerFrameAck

FrameMessage:
  serverFrameId
  frameTime
  playerInputs[]
  fallbackInfo[]
  checksum(optional)

服务器维护一个递增的 serverFrameId。每到一个 tick，就把当前窗口内收到的输入归入对应逻辑帧，生成 FrameMessage，然后广播。

客户端只要按同样的 FrameMessage 序列执行，就应该得到同样的战斗状态。

这句话听起来简单，但里面藏着帧同步的全部难点：网络可能丢包，输入可能迟到，随机可能错位，浮点可能不一致，逻辑遍历顺序可能不同，客户端还可能断线重连。

三、帧同步不等于服务器不管状态

很多人第一次设计帧同步时，会自然想到：“服务器只转发输入，状态都由客户端自己算。”这确实是最轻量的方案，但它不是唯一方案，也不一定适合强竞技游戏。

常见有三种模式：

如果是休闲联机、弱竞技、好友房，纯输入转发可以成立。
如果是强竞技、排行榜、付费对抗，服务器最好至少能做关键校验，甚至直接跑权威模拟。

也就是说，帧同步的“同步单位”是输入，但这不代表服务器一定完全不计算状态。是否让服务器模拟，要看游戏对公平性、成本和反作弊的要求。

四、网络层：UDP、KCP 与 ACK 的边界

帧同步追求低延迟，因此很多项目不会直接使用 TCP。TCP 的可靠有序传输很省心，但队头阻塞会放大实时对战里的延迟：一个旧包丢了，后面的新包即使已经到了，也要等旧包重传后才能交给上层。

更常见的选择是：

• 使用 UDP，自定义可靠性、重传、ACK 和拥塞控制。
• 使用 KCP 这类可靠 UDP 库。
• 对不同类型消息拆分多个逻辑通道。

这里要注意一个边界：传输层 ACK 和业务帧 ACK 不是一回事。

传输层 ACK 关心的是某个网络包是否到达。
业务帧 ACK 关心的是某个 serverFrameId 是否已经被客户端收到、缓存、应用。

如果自己实现 UDP 可靠层，包头通常需要：

1
2
3
4
5
6

packetSeq      当前网络包序号
ackWindowStart ACK 窗口起点
ackBitmask     从窗口起点开始，标记最近若干包是否收到
messageType    消息类型
sendTime       用于 RTT 估算
payload        业务数据

不要只用“最新收到的包号”或“最新收到的帧号”做确认。UDP 会乱序，客户端可能收到 100、101、103，但 102 丢了。如果只上报“我收到了 103”，对端可能误以为 102 也到了。

更合理的方式是直接标注一段窗口内的接收情况，例如：

1
2

ackWindowStart = 100
ackBitmask     = 标记 100、101、102、103... 是否收到

这样接收方不需要把“最新收到”解释成“之前都收到了”。发送方只看位图就能知道：100 收到了，101 收到了，103 收到了，但 102 没收到，需要重发。

业务层也可以有类似设计：

1
2

frameAckStart     = 100
receivedFrameMask = 标记 100、101、102、103... 这些服务器帧是否已收到

但业务层 ACK 不应该替代传输层 ACK。一个是网络可靠性，一个是帧历史补发和重连恢复，职责不同。

如果使用 KCP，也不要以为“用了 KCP 就万事大吉”。KCP 本质上提供可靠、有序的字节流或消息传输能力，仍然可能出现旧数据阻塞新数据的问题。实践里可以考虑拆分多个 KCP 会话或业务通道：

真正要避免的是所有消息都挤在一个严格有序队列里，让一个旧消息拖住后续实时帧。

五、客户端上传的不是“操作结果”，而是输入意图

客户端每个逻辑帧采集一次输入。一个输入消息可以设计成：

1
2
3
4
5
6
7
8
9
10
11

playerId
inputSeq
clientFrameId
operationMask
moveDirection
aimDirection
skillId
targetId
clientTimestamp
lastAppliedServerFrame
receivedFrameMask

其中 inputSeq 用来去重和排序，clientFrameId 用来辅助调试客户端本地预测，lastAppliedServerFrame 和 receivedFrameMask 用来告诉服务器：我已经收到或应用到了哪些服务器帧。

输入需要按语义分类：

这是一个非常重要的细节。

如果玩家一直按着移动键，丢一两帧输入时复用上一帧方向，体验通常更平滑。
但如果玩家只按了一次技能键，服务器不能因为缺帧就反复复用这个技能输入，否则一次操作可能变成多次释放。

所以缺失输入补偿不能简单写成“复用上一帧输入”。更合理的做法是按输入类型、状态机和游戏规则分别处理。

六、服务器固定帧推进：不要被弱网玩家拖住

服务器通常按固定 tick 推进，例如：

1
2
3
4
5
6
7
8

tickRate = 20
tickInterval = 50ms
serverFrameId += 1
收集当前帧输入
补齐缺失输入
生成 FrameMessage
写入 frameHistory
广播给客户端

一个常见误区是：服务器等待所有玩家输入都到了再出帧。这样看起来公平，但实际会让一个弱网玩家拖慢整个房间。

更常见的策略是：

• 服务器固定时间出帧。
• 输入迟到则进入后续帧，或按规则丢弃。
• 当前帧缺失的玩家输入由服务器补偿。
• 补偿策略必须可追踪、可调试。

服务器可以为每个玩家维护：

1
2
3
4
5
6
7
8
9

playerId
lastInputSeq
lastReceivedClientFrame
lastAckedServerFrame
pendingInputQueue
lastValidInput
rtt
packetLossRate
disconnectState

房间级别维护：

1
2
3
4
5
6
7
8

roomId
serverFrameId
tickRate
players
frameHistory
snapshotHistory
baseRandomSeed
startTime

缺失输入补偿可以这样处理：

补偿策略不是越“智能”越好。越复杂的补偿越容易造成客户端预测和服务器权威帧不一致，也越难排查。先用简单、可解释、可记录的策略，通常更稳。

七、下发帧数据：让客户端知道这一帧为什么这样算

服务器下发的帧数据可以包含：

1
2
3
4
5
6

serverFrameId
serverTime
playerInputs[]
frameEvents[]
randomIndex(optional)
checksum(optional)

playerInputs 里除了输入本身，建议带上输入来源：

1
2
3
4
5

playerId
inputSeq
inputFrame
operationData
inputSource

inputSource 可以是：

1
2
3
4
5

REAL_INPUT
REUSE_LAST_MOVE
EMPTY_INPUT
LATE_INPUT_DROPPED
SERVER_CORRECTED

这个字段不是为了玩法，而是为了排查。

线上同步问题往往不是一句“客户端不同步了”就能定位。你需要知道某一帧：

• 真实输入到了没有？
• 是服务器补的空输入，还是复用了移动？
• 某个玩家是不是连续几十帧都在补偿？
• 客户端预测错，是因为本地输入不同，还是远端输入迟到？

帧同步系统要从第一天就考虑可观测性，否则后期排查会非常痛苦。

八、预测、输入延迟与回滚

帧同步有两种常见体验策略。

第一种是输入延迟。客户端采集到输入后，不立刻在本地执行，而是延迟若干帧，等服务器广播回来再统一执行。RTS、战棋、卡牌这类游戏常用这种方式。它简单、稳定，但操作反馈会慢一点。

第二种是本地预测 + 回滚。本地玩家输入立即生效，客户端先预测模拟。等服务器权威帧回来后，如果本地预测和服务器帧不一致，就回滚到出错帧前的状态，再用服务器帧重新模拟到当前帧。动作游戏、格斗游戏、强操作游戏更依赖这种方式。

预测回滚需要客户端维护：

1
2
3
4
5
6

confirmedServerFrame
localPredictedFrame
inputHistory
stateHistory
serverFrameBuffer
maxRollbackFrames

回滚流程通常是：

1
2
3
4
5
6
7

收到 serverFrame N
检查本地第 N 帧使用的输入是否与服务器帧一致
如果一致：标记 N 已确认
如果不一致：
  回滚到 N - 1 的状态快照
  使用服务器权威输入从 N 重新模拟
  一直追到当前预测帧

回滚窗口不能无限大。比如可以设置：

1

maxRollbackFrames = 8 或 12

超过窗口后，可以选择：

• 轻微状态修正。
• 短暂停顿追帧。
• 使用权威快照重置。
• 进入断线重连或重同步流程。

预测回滚不是免费午餐。它要求状态快照足够轻、逻辑模拟足够快、表现层能接受瞬间修正。对于不需要强即时反馈的游戏，适当输入延迟反而更简单可靠。

九、确定性：帧同步最容易被低估的部分

帧同步真正困难的不是“把输入发过去”，而是“所有客户端拿到同样输入后，算出同样结果”。

随机数是最典型的问题。

可以在房间开始时由服务器下发：

1

baseSeed

然后每一帧用固定算法派生随机数：

1

random = PRNG(baseSeed, frameId, randomStreamId)

或者维护一个严格递增的 randomIndex，所有客户端按相同顺序取随机。

但无论哪种方式，都要避免业务代码随便调用系统随机函数。否则客户端 A 多调用了一次随机，客户端 B 少调用了一次随机，后续所有随机结果都会错位。

除了随机数，还要注意：

• 关键战斗逻辑尽量不用平台相关浮点结果。
• 位移、速度、伤害计算可以考虑定点数。
• 对象遍历顺序必须稳定。
• 同一帧内系统执行顺序必须固定。
• 不要让 hash map / dictionary 的遍历顺序影响逻辑。
• 不要依赖非确定性的物理引擎结果。
• 多线程结果不能直接参与核心逻辑顺序。
• 本地时间、帧率、动画事件不能改变战斗结果。

确定性最好从项目早期就作为工程约束，而不是上线前再补。等战斗系统、技能系统、Buff 系统都写完以后再回头排查非确定性，成本会高很多。

十、状态 Hash：用来发现问题，不是用来投票裁决

客户端可以定期上报状态 Hash，例如每 30 帧或 60 帧一次：

1
2
3
4
5
6

serverFrameId
playerId
stateHash
importantStateHash
randomIndex
clientVersion

Hash 内容可以包括：

• 玩家位置。
• 血量。
• 技能 CD。
• Buff 状态。
• 投射物状态。
• 关键实体状态。
• 随机数索引。

Hash 的作用是发现不同步，而不是直接修复不同步。

如果所有客户端 Hash 一致，说明至少这些关键状态在这一帧对齐。
如果某个客户端 Hash 不一致，说明它可能发生了逻辑分歧、丢帧、回滚失败、版本不一致，或者存在作弊风险。

但不要简单认为“多数客户端一致，所以多数就是权威”。这在强竞技游戏里很危险。客户端本身是不可信的，多数一致也不代表结果一定正确。

更合理的策略是：

• 服务器也跑模拟：以服务器状态为准。
• 服务器不跑完整模拟：Hash 只用于发现异常和触发诊断。
• 异常客户端上传快照、日志、输入历史，供服务器分析。
• 对强竞技场景，关键结果最好由服务器校验。

“多数客户端为准”可以作为弱联网、弱竞技游戏的兜底策略，但不应该写成核心权威方案。

十一、快照与断线重连

快照有两个来源：

一种是服务器快照。服务器如果运行权威模拟，就可以定期保存权威状态快照。
另一种是客户端快照。客户端可以上传自己的状态快照，但它只能作为诊断、回放和弱恢复参考，不能天然当作可信权威。

快照的用途包括：

• 断线恢复。
• Hash 不一致后的对比。
• 回放和问题定位。
• 保存关键战斗阶段。
• 帧历史不足时的恢复基准。

频率上不要每帧发完整快照，太重。可以这样设计：

断线重连时，客户端可以上报：

1
2
3
4
5
6

playerId
sessionToken
lastReceivedServerFrame
lastAppliedServerFrame
lastStateHash
clientVersion

服务器恢复逻辑可以是：

1
2
3
4
5
6
7

如果 lastAppliedServerFrame 之后的 frameHistory 还在：
  补发缺失帧
否则如果有可用服务器快照：
  下发最近快照
  再补发快照后的增量帧
否则：
  进入观战、重开、或强制重同步

例如：

1
2

frameHistory 保留 10 秒
snapshotHistory 保留最近 3 到 5 份

这里也要注意：如果服务器没有权威状态，客户端上传的“完整快照”不能直接相信。它可以帮你恢复显示、定位问题、辅助回放，但用于竞技裁决时必须非常谨慎。

十二、推荐落地路线

如果从零实现帧同步，不建议一开始就把预测回滚、复杂补偿、完整快照、反作弊全部做满。可以按阶段推进。

第一阶段，先做最小可用链路：

1. 固定服务器 tick。
2. 客户端上传输入。
3. 服务器广播每帧输入集合。
4. 客户端按帧执行确定性逻辑。
5. 保留基础 frameHistory。

第二阶段，补网络可靠性：

1. 传输层加包序号、选择性 ACK、RTT、重传。
2. 业务层加 serverFrame ACK。
3. 支持缺失帧补发。
4. 区分控制消息、帧消息、非关键消息。

第三阶段，处理弱网体验：

1. 服务器缺失输入补偿。
2. 客户端输入延迟缓冲。
3. 本地玩家预测。
4. 有限窗口回滚重算。

第四阶段，增强确定性和诊断：

1. 统一随机数管理。
2. 固定逻辑执行顺序。
3. 定点数或确定性数学库。
4. 周期性状态 Hash。
5. 输入日志和帧日志。

第五阶段，再做恢复和权威：

1. 断线重连。
2. 帧历史补发。
3. 快照恢复。
4. 服务器旁路校验或权威模拟。
5. 异常客户端处理和反作弊策略。

这个顺序的好处是，每一阶段都能验证一个核心假设。不要一上来就写一个巨大而复杂的同步框架，否则最后很难判断问题到底出在网络、逻辑、随机、回滚还是恢复流程。

十三、总结

帧同步的核心是“同输入、同逻辑、同结果”。它不是简单地把客户端输入转发一遍，也不是天然比状态同步更好。

一套可靠的帧同步方案，至少要回答这些问题：

• 输入如何采集、编号、去重和补偿？
• 服务器是否固定 tick 推进？
• 网络包 ACK 和业务帧 ACK 是否分层？
• KCP 或 UDP 通道是否会被旧消息阻塞？
• 客户端是否需要输入延迟、预测或回滚？
• 随机数、浮点数、遍历顺序是否确定？
• Hash 不一致时如何定位，而不是盲目投票？
• 快照来自服务器还是客户端，是否可信？
• 断线后用帧历史恢复，还是用快照恢复？

如果游戏更偏 RTS、战棋、卡牌，可以优先考虑输入延迟和简单补帧，让系统稳定。
如果游戏更偏动作、格斗、射击，就要认真设计预测回滚和状态快照。
如果游戏强竞技、强反作弊，服务器最好不要只做输入转发，而要至少具备关键校验能力。

帧同步真正难的地方，不在“同步”两个字，而在它要求整个战斗系统从网络、逻辑、随机、恢复到排查工具都围绕确定性来设计。这个前提想清楚了，后面的架构才不会走偏。