帧同步
这是《王者荣耀》公开材料里写得最清楚的一层。孙勋对比了《霸三国》的 Client-Server 和 MOBA 的帧同步，并解释为什么最终用 UDP 而不是 TCP。
玩家A
玩家B
对局服
玩家C
本帧操作
▶
本帧操作
▶
66ms 打包成有序帧
▶
广播帧 + 冗余前几帧
◀
同一份序列
◀
同一份序列
▶
确定性重放
▶
为什么不用 Client-Server 传状态
孙勋给出的工程理由：
- CS 更安全（服务器算结果），中间丢包也可以靠最终结果补齐。
- 但 MOBA 同屏单位可到近 100，一个 AOE 打到 20 个单位再挂 debuff，状态量很大。
- 客户端表现和服务器判定要完全对齐很难。
- 帧同步在端游《星际》《DOTA》里更常见：传输入，端上确定性演算。
66 毫秒
王者逻辑是 66ms 一次，1 秒 15 个包。服务器做三件事：按间隔打包所有人的输入；丢包时补发；用新输入替换过期的上行冗余。帧同步不允许乱序：必须是 1-2-3-4-5。
UDP 和应用层可靠
| 问题 | 公开做法 |
|---|---|
| TCP 重连卡顿 | 改 UDP，避免慢启动和窗口把对局拖死。 |
| UDP 丢包 | 服务器按序号从内存缓存补发。 |
| 弱网 | 每个下行包先冗余前 3 帧；丢包严重再加大冗余。 |
| 大包 | 应用层按 MTU 分包，丢了再补，拼回整包。 |
| 录像 | 理论 20 分钟约 10MB；外网 5v5 约 3MB。 |
重连不是快照
传统帧同步崩溃后必须从开头把中间运算跑完。王者把操作缓存在服务器内存，按编号补发。演讲还提到尝试过延迟投递来抹平抖动。不同步率通过哈希校验、自动化和体验服，从约 2% 降到 0.03%（公开复盘口径）。
GCloud LockStep
GCloud 后来把帧同步做成云服务：TCP / UDP / RUDP，强调弱网可靠和计算一致性检查。这说明「输入广播 + 确定性重放」已被收成可复用组件，而不只属于王者一局。