目录

前言

一、帧同步是什么？

二、UDP的优缺点

三、帧同步的基本流程

Unity3D实现帧同步

单机游戏：手柄操作输入给程序，程序计算，推动游戏运行；

帧同步：所有的游戏逻辑都是在客户端计算，那么服务器做什么呢？

服务器基于帧的概念：每隔一段时间向客户端发送所有玩家的操作，同时等待玩家的操作进来，下次再发。

问题：这样做同步帧，服务器的带宽是否能承受？

每帧中发送的每个玩家的操作信息大概16个字节就能满足，王者中有十个玩家，每秒15帧，即每秒发送15次，16*10*15=2400Byte，一个房间的带宽需要2400Byte；假如同时有500个房间，2400*500=1200000/1024=1171.875kb/1024=1.1444M。其实所需的带宽应该是小于1.1444M，因为不是每帧所有玩家都有操作。

服务器每秒多少帧合适：服务器的帧对应的是用户操作，并不是游戏画面（60FPS即可接受）；用户反应速度在50ms~100ms之间，1秒=1000ms，也就是[10~20FPS]；王者荣耀服务器帧同步为15FPS。

TCP：面向连接的可靠的传送协议；socketAsocketB；

假如socketA要发送数据包1和数据包2给socketB，那么socketA先发送数据包1，socketB收到后回复OK给socketA，然后socketA再发送数据包2。如果socketA发送数据包1时由于某种情况，socketB没有收到数据包1，那么socketA会超时再发送数据包1，并等待socketB的回复。这种情况保证了准确性，但是没有实时性；数据包1会卡住数据包2，而且网络传送需要2次，这样发送下一个数据包的时间间隔成倍增加。

UDP：不是面向连接的，创建一个socket向IP+端口号发送数据，不在意另一端有没有收到；发完马上发送下一个数据包，高效，不会卡住。

UDP缺点：丢包，数据包在网路的某个传输节点丢掉了，这个时候目标是收不到相应的数据包的。 我们的数据包在网路里传输，走的物理路径有可能不一样；例如先发数据包1，再发数据包2，但是数据包2先被收到，这就出现了先发后到后发先到。

（1）游戏开始，帧同步就开始了；服务器的其他功能，如登陆，还是用的TCP协议，只有帧同步用UDP；

（2）在服务器上启动一个定时器，每间隔66ms触发一次，向客户端广播所有玩家的操作，这就是帧；

（3）服务器中，设置一个frameId，保存服务器当前进入的最新的帧ID，初始为1；

（4）服务器中，设置一个变量，保存当前游戏每一帧的所有玩家的操作，matchFrames，所有帧数据如：[帧1，帧2，帧3[玩家1的操作，玩家2的操作.......]]；

为何要记录所有的帧操作？因为有可能丢失，有可能断线，要现场。

（5）服务器中都设置一个成员nextFrameOpt，这个数据结构用来收集所有玩家的下一帧的操作，在66ms的时间间隔中收集玩家操作，当到达66ms时将所有玩家的操作发出去，然后清空再收集所有玩家的操作；

（6）当服务器的帧到达后，把nextFrameOpt采集到的所有玩家的操作保存到matchFrames；

（7）帧时间到了之后，将本次采集到的所有玩家的操作发送到所有客户端；

（8）服务器向客户端发送“服务器认为”客户端没有同步到的帧；

（9）在服务器上的每个玩家都保存了一个syncFrameId，记录玩家同步到了哪一帧，因为服务器中当前帧frameId初始值为1，所以syncFrameId初始值为0，此时未同步第一帧；

（10）每次服务器给客户端发送的不是最新的帧，而是从syncFrameId+1到最新的帧的一组数据，即[syncFrameId+1,最新的帧]的数据；

（11）此时流程进入到客户端，客户端会有一个代理对象专门和对应的服务器对接；对于来自服务器的消息，有一个统一的入口，有消息进入时，发布监听事件，同步玩家操作；

（12）在客户端定义一个变量syncFrameId，客户端同步完之后就把当前同步过的帧记录到这个变量中；即保存客户端真正已经同步过的帧id，初始值为0；

（13）如果当前从服务器收到的帧id