状态同步
- 客户端只上传操作指令，但是接收所有客户端的状态信息。
- 整个游戏的逻辑全都在服务端，客户端只是展示的功能。
- 客户端反外挂能力强。
- 由服务端统一下发状态，不可能会有不同步的情况。
- 耗流量不稳定，数据传输量会随着游戏单位和单位信息的增多而增大。 6.开发效率低，由于整个游戏的逻辑都需要在服务端重新开发，某些引擎（比如 Unity）就完全无用了。
帧同步
- 客户端只上传操作指令，也只接收操作指令。
- 整个游戏的逻辑在客户端，服务端没有客户端的状态信息。
- 客户端反外挂能力弱。
- 对客户端程序要求高，很容易出现不同步的情况，而且不容易查找。
- 耗流量低，数据传输量始终只有各个客户端的操作指令。
- 开发效率高，对于已经开发好的单机客户端，只需要按照帧同步的策略去修改部分代码即可。
传统帧同步
客户端在一定时间内收集操作指令，以一定时间间隔（PVP 游戏一般为 50ms）上传操作指令，并且携带当前的帧编号（帧编号不断增加），服务端必须在收集到所有客户端的当前帧数据后才会下发，也就是会等待所有客户端正常上传操作指令才认为这一帧数据是正常的。这样做有个非常大的缺点，就是网络延迟永远等于延迟最高的那位玩家，这对于 PVP 这种实时性要求非常高的游戏来说是致命的，就游戏性而言也是不公平的。尽管有些开发者做了一些改进措施，比如超时机制，当服务端超过一定时间没有收到某个客户端的帧数据时，便舍弃这个客户端，直接广播数据给所有客户端。这样虽然能使得延迟效果好一些，但对网络要求较高，如果有一个客户端网络环境很差，那么每一帧数据都要等到这个超时才会下发，游戏肯定不会平滑了。
乐观帧同步
由服务端来控制帧速率（比如 50ms 增加一帧），客户端有了操作指令即时上传，空闲时间不用上传，服务端在一帧时间内把收集到的所有操作指令广播下去，客户端根据操作指令执行本地代码。这种模式的好处有几点：
- 客户端不用在无操作指令的时候上传。
- 客户端不用控制帧速率（在不同平台客户端要想控制相同的速率也不是简单的事）。
- 不会因为某个客户端延迟而影响没有延迟的客户端，这点对于 PVP 游戏尤其重要。