状态同步
优点：
- 数据在服务器运算，客户端接收到的数据一定准确
- 防止数据作弊，角色数据在服务器，客户端只上传操作，想作弊没门
- 网络波动不敏感
- 多端表现可以不一致，重视数值准确。
缺点：
- 前后端数据包体大，
- 服务器压力比较重（计算量、传输量）
研发特点：战斗逻辑全部在服务器，客户端等着服务器数据刷表现。
适合使用状态同步的游戏类型：魔兽世界、传奇等MMORPG游戏
帧同步
?优点：
- 只转发用户操作，网络带宽压力小
- 适合回放、直播（省流量）
缺点：
- 网络波动及其敏感
- 由于只同步用户操作，多端要保证根据相同的输入获得相同的输出
- 随机数确保一致
- 浮点数精度不同
- 物理引擎不可靠
研发特点：?服务器只负责转发用户操作，可以外加操作校验防作弊，主要的战斗逻辑代码都在客户端。
总结：
通过上述分析，
帧同步的分支：
我个人认为帧同步主要分为三个研发方向：第一种实时竞技类如CS/CF/守望先锋，第二种是MOBA类如王者荣耀，另三种是卡牌类(阴阳师)，主要区别我列个表格
| 网络方式 | 物理引擎 | 随机数 | 行为预测 | 快照与回滚 | 数据表现分离 | 定点数 | | 实时竞技 | UDP或TCP | 自己写物理 | 不经常 | 需要 | 需要 | 需要 | 需要 | | MOBA | UDP或TCP | 自己写物理 | 经常用 | 需要 | 不需要 | 需要 | 需要 | | 卡牌类 | TCP | 不需要物理 | 经常用 | 不需要 | 不需要 | 需要 | 需要 |
为何同样是帧同步缺差异如此之大，主要还是因为游戏类型不同、设计需求不同导致的，下面以CS、王者荣耀、阴阳师的具体工作流程做对比。
首先以CS举例，假设当前房间有AB两个玩家，具体流程：
- 第一帧（A玩家点击鼠标左键，B玩家无操作）
- 第二帧（操作1A，操作1B发送给服务器，请注意，所有玩家操作都发给服务器，0操作也需要发空操作指令）
- 第三帧（服务器打包操作1A、操作1B并广播给AB玩家）
- 第四帧（玩家A收到1A、1B操作，玩家B收到1A、1B操作，刷新实体数据形成数据快照）
- 判断子弹的前进方向有没有与角色发生碰撞(确定性物理引擎重写)，如果碰撞了，判断是否是B角色，如果是B，判断射击部位并扣血
下面是?
UDP为什么比TCP快
- TCP为了可靠性保证，增加了3次握手4次挥手，复杂的拥塞控制，以及流量控制，让网络传输的延迟进一步增加。
- 采用TCP基于滑动窗口，一旦发生丢包，TCP会将后续的包缓存起来，等前面的包重传并接收到后再继续发送，延时会越来越大，基于UDP对实时性要求较为严格的情况下，采用自定义重传机制，有包就发，能够把丢包产生的延迟降到最低，尽量减少网络延迟。
- TCP头部的大小，进一步增加了，传输的数据量。
|