游戏服务器同步方案小结

TCP与UDP的选择：UDP相对与TCP快速，但不可靠。在网络较差环境下，可以选择UDP+手动解决丢包乱序问题。

帧同步+UDP：自定义的协议栈：FSP，即FrameSyncProtocol：https://www.cnblogs.com/shown/p/6108617.html

主机模式同步：
具体实现方案：以参与对战的一个客户端为“主机”，其他的客户端为“副机”。游戏逻辑的主要运算由 “主机”完成，所有的“副机”把操作指令，通过服务器中转，集中发送给“主机”；“主机”完成游戏运算后，把结果指令再通过服务器中转，广播给所有的“副机”。
优点：服务器端无需再开发二维、三维空间中的位置运算、碰撞检测等功能，承载的人数有数量级上的提升，“主机”客户端运行游戏逻辑，所以其体验是最好的。
缺点：安全性

状态同步模式：
具体实现方案：客户端负责发送各自的操作，服务端收集操作后进行逻辑判断，统一发送给所有客户端。可以理解为，服务器是控制层，客户端为视图层。
优点：容易防止外挂信息安全，游戏逻辑更新方便适用游戏类型：同局人数不多，玩法变化快，安全性需求高。
缺点：流量高，服务端压力大，客户端与服务端耦合性过高，单独开发困难

帧同步模式：
具体实现方案：客户端负责发送各自的操作，服务端收集操作后按固定帧频率将所有客户端操作返回给客户端，在客户端进行逻辑判断。核心原理：相同状态+相同的输入=相同的输出对不同客户端的计算结果要求严格，如不能使用浮点数、随机种子需一致。
优点：流量低，服务器压力小
缺点：反外挂压力大（对比不同客户端计算数据），客户端计算压力大

帧同步发展：
囚徒模式：必须收集完所有玩家操作数据才执行下一帧
缺点：一个玩家的网速会影响所有玩家
乐观帧同步：若某一帧缺失某玩家数据视为无操作，帧流程继续

玩家体验优化：
核心方向：即时反馈
详细实现方案：缓存帧数据：客户端缓存N帧服务端发送的数据，网络波动大时先执行缓存数据，N过大时客户端延迟过高。
预表现：
表现层与逻辑层分离，当逻辑层无法得到即时反馈的数据时，由表现层预先渲染。
1、必定能实现的操作直接表现，无需等待服务端的计算结果。
2、尽量延长动画时间，为得到计算结果之前争取时间。
预测：
预测非我方控制单位的运算轨迹，当预测结果与实际计算结果不同时，进行回滚。

参考文章：
帧同步方案详解：https://blog.csdn.net/heyiwen555/article/details/84591070
状态同步与帧同步：https://blog.csdn.net/jiange_zh/article/details/78509457
三种方案的比较：https://blog.csdn.net/w174504744/article/details/53886520