原标题：帧同步（LockStep）该如何反外挂 及 优化

01. 帧同步（LockStep）该如何反外挂

在中国的游戏环境下，反挂已经成为了游戏开发的重中之重，甚至能决定一款游戏的生死，吃鸡就是一个典型的案例。

目前参与了了一款动作射击的MOBA类游戏的开发，同步方案上选择了帧同步技术（LockStep而非snapshots以下同）。那么就有很多人担心起来，客户端会跑全部逻辑帧同步该如何反外挂，和状态同步有什么区别呢？

首先我们来分析一下手游的风险和外挂的分类，这里推荐腾讯游戏安全中心的文章，有着非常详细深入的介绍。

手游的风险：

• 静态修改文件：将游戏解包修改资源 ，配置，代码等之后再重新打包

○ 修改资源，例如替换游戏的贴图做广告，修改玩家碰撞资源 或删除部分关键资源使玩家可以作弊等

○ 修改代码，直接修改游戏代码，实现无敌，免CD，无限伤害等等

○ 修改配置，修改策划配表等

• 动态篡改逻辑：通过注入和钩子的方式，在游戏运行时修改游戏代码，修改游戏内存等

○ 修改代码，运行时注入进程直接修改游戏代码或者钩住关键逻辑函数修改逻辑，实现无敌，免CD，无限伤害等等

○ 修改内存，例如烧饼，葫芦侠等修改器，在游戏运行时修改堆栈和全局变量等

• 游戏协议

○ 篡改游戏协议，直接修改协议的内容，修改结算结果，修改伤害数值，修改血量等等

○ 重复游戏协议，例如多次重复伤害协议

• 其他，按键精灵。脚本宏，盗号，恶意发言，打金工作室等，这些和同步技术无关，暂不做详细讨论

外挂的分类 ：

摘自腾讯游戏安全实验室

从上文可以看出外挂的主要方式还是修改客户端的资源，代码，和内存。因此反外挂的手段也不外乎以下几种：

• 服务器计算关键逻辑。例如一些MMO战斗逻辑泡在服务端

• 服务器验证客户端逻辑。包括通过完整战斗逻辑验证和数值范围验证，例如早期的酷跑（可能误杀牛逼的玩家）

• 包体加密加签名加验证，防止破解包体。例如一些第三方加固，Unity的MonoDll加密，代码混淆等

• 加密本地保存的一些文件。例如对加密PlayerPrefs文件

• 加密和扰动运行时内存中关键数据（例如血量数据等）。例如崩3等

• 防注入检测（杀死注入进程或者发现注入之后杀死自己）

• 虚拟机加密

• 加速检测，防止修改本地时间的变速齿轮

• 穿墙检测，客户端对关键碰撞做校验

• 集成守护进程以及守护进程的自我加密更新

• 鼠标宏，按键精灵等进程检测，防止玩家使用这些工具

• 增加举报系统查证封号

• 通过暴力机关严厉打击外挂制作者(个人感觉非常有效)

• 其他

但很遗憾，因为理论上再牛逼的客户端也是可以破解的，所以客户端的东西都是不可信任的。就像市面上也有很多第三方的加固工具，反作弊插件等，但不管用什么eye，什么火眼精睛，该作弊的还是作弊。因此反外挂的核心还是在于是否服务器是否计算了关键逻辑，就像Unreal老大说的The Server Is The Man。而和同步技术和客户端是否跑完整逻辑关系不大（严格说是有一点关系）。不管是状态同步还是帧同步，只要做到了服务器有完整逻辑并验证，绝大部分外挂都可以防掉（例如锁血挂，穿墙挂，加速挂等）。

对于状态同步来说关键逻辑在服务器的比重越高反外挂就越完美。最极端的例子就是就是云游戏，服务器计算所有逻辑和画面，客户端只是显示图像，基本上杜绝了所有其他外挂（除了按键精灵，鼠标宏，手速挂等可以模拟玩家操作，捕捉像素计算操作，只能通过进程检测，举报，法律打击等其他方案）。

而对于帧同步来说，我们同样可以在服务器验证完整的战斗逻辑。一般分为两种：

1. 实时验证。例如战斗实时运行战斗逻辑和客户端不断同步验证关键数据的hash，和状态同步类似。但这种方案服务器负载较高，运维成本高昂；

2. 离线验证。这是帧同步的优势，战斗结束后服务器收集整场的操作序列，然后加速播放战斗（几十上百倍），最后校验结果，例如刀塔传奇。这个好处是服务器不用实时跑战斗，只需在结束时花几百ms即可验证一场战斗，大幅降低服务器成本。

如果是这种验证方式帧同步也一样能防掉绝大部分外挂，但是会多一个弱点就是全图挂。因为客户端有了所有玩家的位置信息，所以无法防掉全图挂。

那么如果这么说，只要服务器跑逻辑就行了，为什么外挂还这么泛滥呢？其实因为种种原因很多游戏服务器并没有完整的逻辑和校验，对于绝大部分游戏使用状态同步来说有以下一些原因：

1. 性能问题。服务器运行完整逻辑开销很高（特别是一些复杂运算，例如物理弹道等），因此将部分逻辑放在客户端分布运算

2. 因为开发效率和开发能力的限制。例如开发技能，如果所有逻辑都在客户端开发就会简单很多，响应也非常及时。如果要涉及服务器和客户端同步，就会多很多工作量特别是一些位移技能，很多逻辑可能还要写两份（帧同步更高效更容易实现打击感也是这个原因，很多动作游戏，MOBA游戏也会选择帧同步）

3. 经验问题。一些公司在反外挂上经验不足重视程度不够，特别是国外游戏环境较好法律健全

4. 为了极致的体验。例如为了降低网络延迟，很多游戏会让客户端预表现和加入延迟补偿，在一定范围内信任客户端（特别是FPS游戏，状态同步在延迟感上有较优势）

5. 为了弱网体验。为了让玩家在网络极差甚至断线的情况下也能玩，将绝大部分逻辑都放在客户端

6. 多种原因混合，其他一些个别问题。

但是以上的问题对于帧同步来说不也一样吗？如果为了成本和快速开发，服务器不跑逻辑不也一样抓瞎吗？其实帧同步会更简单一些。对帧同步来说有以下几种情况：

1.基于RelayServer多人PVP。这种会相对简单很多，因为每个客户端都计算了完整逻辑，作弊玩家修改的只是本地数据无法影响其他玩家，只能自嗨。最终结果服务器只要简单的比较投票就可以找到作弊者，除非作弊的玩家多余非作弊的玩家并且作弊玩家还要修改一样的数据（有点比特币算力的意思：），另外也可以在游戏运行时不断生成关键数据的hash码，随时校验；

2.基于P2P的多人PVP。和RS差不多但是无法防主机作弊了，参考魔兽争霸，但网游基本不会使用；

3.双人PVP和单机。这就没办法了，只能服务器做校验；

综上所述，因为天然的客户端强一致性，总体来说帧同步在防外挂上甚至会更简单一些（参考王者荣耀）。但成也萧何败也萧何，正因为这个机制的问题，无法完全防住全图挂，也因此甚至有MOBA游戏，同时使用两种同步机制来保证线上赛和线下赛的公平和体验。

02.帧同步和状态同步该怎么选（上）

前言

随着王者荣耀的崛起，使用帧同步（Lockstep）的游戏也越来越多，关于帧同步和状态同步的讨论争论也有不少，那么到底该选哪种同步机制呢？两种机制都使用过，各有优缺点也都踩过不少坑，这里对帧同步和状态同步进行一下总结和讨论。

首先需要说明， 这里的帧同步其实是指 LockStep， 是指服务器按帧转发客户端的操作，客户端进行确定性运算和一致性模拟（同步操作两边客户端通过完全一致的操作计算出完全一致的状态）。 每帧同步状态这里也认为是状态同步。

这两种同步机制都是为了达到即时同步不同客户端的状态的目的，帧同步需要参与者去管理和维护其自有的那份拷贝，通过施加一致的逻辑来推动所有的状态去同步地更新；状态同步则随着时间的流逝不断地比较和发送最小的状态变化和差异。

我们先看一些使用这两种同步机制的案例：

可以看到大部分类型游戏，两种同步方式都可以使用，但 绝大部分游戏使用状态同步，大量玩家战斗的游戏只能使用状态同步。

网络模型发展历程

下面简单介绍一下网络同步模型的发展。我们可以从DOOM/QUAKE I/II/III的演化来看到同步模型的发展。可以参考 DOOM3网络模型的演化与网络架构这篇文章。同步方式的历程大概是帧同步（Lockstep），快照同步（Snapshot synchronization），状态同步（State synchronization），目前绝大部分多人游戏都使用状态同步。

P2P 模型 (DOOM)

DOOM (1994) 的网络模型是基于P2P的帧同步。有着帧同步的各种问题，后面会介绍。并且因为没有主机，每个玩家直连其他所有玩家任何一个人卡所有人都卡，是一个非常古老的同步技术。

Packet Server (包的简单中继)

这个模型在原版 DOOM 的基础上增加了一个 Packet Server，负责转发所有的 tick command。玩家不再直连其他所有玩家，而是连到这个服务器 (某个玩家机器上) 以获取最新的状态。这样改进后，同步量降低了，一个玩家卡只会自己卡，当然如果服务器卡就会卡。 体感可以参考魔兽争霸，主机卡了所有人都会卡。同时如果主机是服务器可以避免绝大部分作弊情况，但如果主机是玩家主机作弊就没办法了。帧同步的其他缺陷也没有得到解决。

Client Server (Quake I/II/III)CS架构

Quake I/II/III 实现了比较典型的 C/S 架构 (1996)。这个模型中 服务器负责所有的逻辑判断，客户端 本质上只是一个渲染终端。玩家把自己的操作和输入发送给服务器，收到一个实体列表用于渲染。服务器把压缩后的快照按照固定频率发送客户端 客户端使用这些快照来插值或推导出平滑连贯的体验 。

这时候同步机制已经变成了服务器同步操作客户端计算逻辑，服务器同步状态的状态同步了， 解决了帧同步的大部分问题。但 Quake I还做的比较简单，和帧同步不同的是把所有逻辑相关的放在了服务器，客户端在发送操作之后就要等服务器同步状态。延迟问题还是没有得到解决，同时因为要同步所有状态信息带宽占用很高，当游戏越复杂带宽就越高。

Quake III做了进一步的优化。客户端不是等待服务器而是 会预测可能的游戏状态，预测状态和服务器端逻辑使用一套代码，如果服务器和客户端确实不一致，则服务器为准强同步。

预测也是降低延迟感的一个重要方式，对延迟要求很高的FPS特别重要。并且状态同步服务器永远所有信息也能允许玩家中途加入和退出了。但同样的开发 复杂度也变的更高了，代码需要区分服务器和客户端， 需要逻辑和表现分离，需要处理一些联调的问题（服务器和客户端处理时间不一致，预表现差值问题，强同步问题）。

半条命（基于Quake引擎开发）在这个基础上引入了一种 延迟补偿 (lag compensation)，当玩家向某个目标 (若干毫秒前的状态) 射击时，做实际检测的服务器会采用该目标若干毫秒前的状态来检验是否击中。这么做需要服务器把之前一小段时间的状态持续地保存下来，这样不仅增加了实现复杂度，而且导致了某种程度的不一致性。延时高的玩家反而更容易因为补偿获得更有利的判断，严重影响游戏体验 。这种补偿只能对目标的位置回滚，而所有其他环境状态的改变却已无法倒退，这也会影响实际的体验。

Quake III里对同步信息做了进一步压缩和优化， 只有在 PVS 内的实体才会被同步状态，而且被同步的是 压缩后的与上一次同步的 差值(delta compressed relative to the entity states from a previous snapshot，Delta技术) 。

可以看到当玩家比较少的时候，帧同步只需要同步操作，流量会比较小，非常适合同屏大量小兵的情况（小兵不需要同步任何信息），极省带宽。但是当玩家多的时候每个玩家的操作都要互相同步，带宽就会 指数增长，无法优化，反而状态同步可以通过分区域的方式同步 支持更多的玩家。

与 Quake III 不同， Doom III的服务器和客户端使用同一份代码来更新/预测实体的状态，这样不用担心服务器和客户端逻辑的互相干扰，同时客户端和服务器也一相同的逻辑帧率运行60fps，每帧客户端上传玩家输入，服务器按固定间隔同步PVS范围内的状态快照，也可以理解为 按帧同步的状态同步。

Doom III在网络上使用UDP，自己通过冗余包和滑动窗口保证服务器消息不丢失和有序并且允许客户端上行丢包，在弱网情况下比TCP延迟更低，不需要TimeOut机制。

两者的优缺点对比

那么我们再来对比一下帧同步和状态各自的优缺点：

03. 帧同步和状态同步该怎么选（下）

那么依据上篇文章的分析，我们可以总结一下，对于大部分游戏来说，两种同步方式都可以使用。但相比之下状态同步适用型更广，特别适合复杂度高，延迟要求高，玩家多的游戏，例如FPS，MMO等等。帧同步相对适合小兵很多，玩家少且固定，单局时间短，对打击感公平性要求高，追求一致性的游戏，例如格斗，运动，RTS，卡牌，MOBA等。

从技术角度来说，帧同步有一些技术限制，大量玩家战斗，随时进入退出，难以预表现等，而状态同步有更多的优化手段可以更好的降低延迟感。 可以说用帧同步的一定能用状态同步，但反过来不成立。

当然帧同步也有自己的优势， 实现成本相对简单开发比较快速（一套逻辑不太需要联调），在 玩家较少小兵较多的情况下（由于只同步事件而非状态，所以网络传输的数据和游戏里的对象数量无关 ）服务器性能和带宽开销极低，甚至可以没有服务器（服务器可以完全不跑战斗逻辑只在需要反挂的时候跑），有点去中心化的意思。也非常适合一些单机游戏改成联网得游戏，非常适合中小公司（之前开发的一个MOBA游戏 只有一个服务器同学）。

我们在选择的时候需要综合考虑游戏类型，未来需求，战斗时长，游戏模式，网络带宽，延迟响应，防作弊，开发成本周期和实力等因素来选用不同的同步方案， 甚至混合使用。 没有最好的技术只有最适合的技术。下面是一些在选择时可以思考的一些参考问题：

帧同步的难点

因为帧同步的一些限制并且使用的相对较少，最后再补充一些帧同步的优化方案和心得，可以参考后边：“帧同步技术目标总结 ”

这篇文章。

延迟方面：帧同步难以做预表现，所以对网络和延迟要求更高，必须在网络层上有更深度极致的优化（一些状态同步的游戏优化不好开可以通过预表现蒙混过关）。

以下是之前尝试过的一些优化手段：

1.首先要分析延迟是否有逻辑问题，比如我们一开始有部分延迟是因为逻辑在FixedUpdate里执行，因为更新顺序问题导致客户端相应操作慢一帧，解决之后有较大提升；

2.网络层面极致优化，使用自己开发的 UDP，通过 冗余包和滑动窗口的方式保证 可靠性降低延迟。冗余包的个数依赖 MTU并不固定，当然前提是 每个帧操作的包也要极致优化（方向操作分段，按位压缩等）。此外客户端 上行可以允许丢包允许非可靠，客户端关键操作立即发送( 发送频率比逻辑帧高)，网络 多线程， 多地多线部署匹配等等；

3.控制发包频率。非关键操作降低发送频率，服务器收到的操作会进行合并和优化，进行 帧聚合，避免堆积。甚至可以有选择的舍弃一些包；

4.客户端可以进行一些 预表现。比较好的做法逻辑层和变现层分离，客户端表现层可以预表现一定的位移，然后通过 航位预测算法逐渐差值到逻辑层的位置。对于帧同步来说解决平滑位移的 基础还是网络层的极致优化，然后再考虑平滑差值和预表现。

性能方面：帧同步需要每个客户端都完整计算所有逻辑包括小兵AI等，特别是很多帧同步游戏又是对帧率要求非常高非常稳定的，不能卡顿，也需要有更好的性能优化需求。

以下是之前尝试过的一些优化手段：

1.常规的一些客户端性能极致优化，保证客户端帧率稳定，可以参考后续发布的:

“Mack：Unity优化技巧 ”

。例如 多线程，分帧分摊，优化GC， 预加载预编译，优化算法，使用更优的平滑算法在渲染层差值，网络卡顿时进行分担等等；

2.帧同步有优势的一些优化手段。逻辑帧和渲染帧分离，降低逻辑帧，一般来说MOBA游戏逻辑只需要15帧即可， 在渲染帧较高时利用负载均衡拆分逻辑帧等消除毛刺等；

3.甚至一些复杂运算可以 分布式计算或者服务器计算，一人计算后同步给其他玩家。

开发效率：帧同步实现简单但维护和查bug极难，对工具，开发素养，规范都有非常高的要求。特别事帧同步只有一点不一致就会导致双方不一致（一个运算，一个错误导致一些代码跳过，更新顺序等），并且往往是在第一时间表现不出来的，累积到一定时间之后才会爆发。

以下是之前尝试过的一些优化手段：

1.程序框架上避免，开发时要求0warning0Error，详尽的保护，逻辑层和表现层分离更新帧率不同，一些随机数，顶点数学库等底层库也要区分开，有自动化的导表转换工具等，防止逻辑层使用浮点数，不是固定随机等；

2.提供自动化的检查工具。定期计算关键数据的hash值每帧校验，表现层使用逻辑层库会自动报错等；

3.出错时的排查工具。详细的本地日志，不同步时每个人上传服务器前100帧的日志；录像功能，记录每个玩家同步操作信息，同时出问题之后可以重复触发跟踪等

PS一些小误区

• 帧同步会受网络最差的玩家影响，延迟依赖于最差玩家，一个人卡所有人都卡 ：这是早期的P2P技术导致的，一个玩家要等所有玩家的操作都到了才到。最早Doom就有这个问题，如果使用Packet Server（服务器或者主机）就可以避免这个问题，卡的玩家只会影响他自己，就是 乐观帧 方案
• 状态同步服务器需要跑逻辑 ：状态同步也可以使用客户端之间的状态同步服务器只转发，帧同步也可以服务器跑完整逻辑（实时跑和结算后快速演算）
• 帧同步或者状态同步只能选一个 ：针对不同的需要也有项目同时使用帧同步和状态同步两种做法例如梦三国等，平时使用帧同步线下比赛的时候针对比赛玩家使用状态同步解决全图挂的问题
• 帧同步难反作弊： 除了全图挂等（客户端有完整信息）更容易反外挂，王者荣耀反外挂做的就很好
• MOBA适合帧同步： Dota2和LOL都是状态同步的

04. 帧同步技术目标总结

在写一些网络优化总结的时候，翻到了年初3月份写的技术目标。在此之前因为玩法在不断摸索，主要的时间都在独立解决一些问题上，几乎不会涉及到技术任务的分配。但因为4月份版本需要上线测试而且至关重要，但当时的版本还过于Demo化延迟性能等都有不少问题，因此也被委以重任制定技术上下个月版本的技术目标，希望能有所提升。

着实挖空心思了一番！丧尽天良的列出了一大堆优化目标(也厚颜无耻的请教了很多成功项目同事朋友>_<)。。。

经过大家的不懈努力，两个版本之后基本所有的优化点都已完成（游戏功能也在不断开发），之后的版本有了大幅提升，顺利的经过了n轮测试。现在回头看看，真是一个非常痛苦而又快乐的过程，痛并快乐着，我想这就是游戏开发的真实写照。

• 网络优化：

1. 客户端和服务器立即发消息的收发方式。【优先级高】。现在服务器和客户端有个缓存队列（可靠UDP的机制，改进后我们将使用TCP，可靠UDP，非可靠UDP三种网络方式）消息不回立即发送。降低延迟。
2. 客户端收发协议多线程。【优先级高】。更快的收发包，减少不受客户端帧率影响。
3. 实现非可靠UDP。【优先级高】。当用户网络不稳定丢包时可大幅降低延迟。使用冗余包的方式保证UDP可靠，比现在的ACK保证可靠性流量更大但延迟率低。
4. 网络数据测量分析。【优先级高】。测量纯网络ping值，和游戏真实ping值。定位延迟问题，目前正常ping值在30ms左右，但网络层实际ping值在100ms左右，定位问题和解决方案。实际主要是因为客户端逻辑层和表现层的更新顺序问题。
5. 断线重连。【优先级高】。分析和制定更好的断线重连方案，测试提供测试用例，需要策划配合。review和方案讨论的时间，具体修改方法还需要测试讨论。
6. 将帧协议从protobuff改为二进制流。【优先级低】。针对混战角色较多提升客户端收发包性能。
7. 移动的行为预测，表现层预表现一段时间玩家操作，使用航位预测算法平滑渲染层和逻辑层，降低移动延迟。
8. 协议包的压缩和限制，减小包的大小，忽略部分细微操作。

• 底层优化
• 1. 负载均衡机制，因为逻辑层是15帧，渲染层依赖玩家设备和游戏环境但几乎都会高于15帧，通过分摊逻辑运算降低帧率的毛刺。
  2. 道具掉落系统的格子算法统一。【优先级中】。目前IO模式使用了新的格子算法，匹配还是老算法。
  3. 贴图资源泄漏。【优先级中】。从主城到战斗等场景切换会有些贴图无法释放，导致玩家时间长之后内存膨胀。
  4. 堆内存优化。【优先级中】。解决游戏中顿卡问题，堆内存分析优化，通用内存池开发。
  5. 性能优化。【优先级中】。分析游戏的性能瓶颈解决游戏中卡，发热，帧率低等问题。已知有图形配置的调整，追帧隐藏场景等。【每次封板前后review，有针对进行优化】【持续】
  6. 阻塞加载场景，再来一局同一场景不进行loading。【优先级低】。提升loading速度。
  7. UI使用一些插件做一些动画。【优先级低】。
  8. 加密。使用关键数据内存加密的方式（仅客户端），使用关键数据上报服务器校验的防作弊方式。
  9. 使用IL2CPP取代Mono的DLL加密方式，防止代码逆向并提升性能。
  10. 更详细的图形配置测试，获得每个图形配置对帧率，发热耗电的数据提现，针对标杆机型普及率高的机型做深度的推荐配置，让玩家上来就获得最好体验。【优先级低】。（取决于已有机型的数量）
• 流程优化：
• 1. 服务器白名单。【优先级中】。这几次测试也有需求开服测试时可以屏蔽玩家，但是可以运行指定IP段提前连入测试，被服务器挡掉的玩家有未开服公告。
  2. 热更流程优化。【优先级中】。重构现在的热更代码，和自动构建集成，支持不同服的版本使用不同的CDN配置，支持更新表格和lua，支持更新部分UI资源。【后续更多的资源更新需要对资源做更大的调整】
  3. GM工具。【优先级低】。现在只有发公告。
  4. 开关服的流程优化。【优先级低】。登陆公告，跑马灯，踢人，封号，关服倒计时，更完善的公告。需要和策划一起梳理。
  5. 自动构建的Build号校验
• 工具优化
• 1. AI行为树编辑器。【优先级低】。暴露更多的接口给策划，让策划便于编辑修改。【开发中下周】【持续】
  2. CMT技能编辑器。【优先级低】。开发可视化的CMT编辑器，优点不需要写代码，缺点无法配置逻辑，不灵活。【持续】
  3. 自动的调试菜单更美观易用，支持分页。【优先级低】。
  4. 支持本地录像和日志记录功能，支持关键数据校验不同步时实时上报日志供呢个。
• 重构
• 1. MainUI拆分。【优先级低】。因为开发了多个模式，很多模式的UI都混在一个预制体，战斗界面非常庞大而且容易出错，性能也差，使用不方便。可以分摊到开发过程中。【持续】
  2. 玩家组件系统重构。【优先级低】。纯代码重构。
  3. UI使用消息事件系统。【优先级低】。使用消息系统可以使UI结构更清晰减少bug，新的界面使用了历史遗留的一些界面没使用。
  4. 帧同步游戏内换人加入优化。【优先级低】。因为IO模式支持中途换人，每次换人的时候需要发送该玩家拥有英雄数据天赋数据非常庞大，优化为只在换人的时候同步换的角色的属性和天赋，否则后期英雄数量的时候会出问题。【是否可以不换人】
  5. 状态机重构。【优先级低】。统一目前游戏内的多个状态机，游戏流程使用唯一的一个状态机。客户端2天。
  6. 资源管理方式使用引用计数方式。【待讨论】