1、概述
在技术选型方面，之所以选择帧同步方案，在Kevin的一篇介绍PVP帧同步后台实现的文章中已经做了详细叙述，这里简单摘要如下：
高一致性。如果每一帧的输入都同步了，在同样的上下文中，计算得出的结果应该也是同步的。
低流量消耗。除了帧同步，其它方案（比如状态同步）想做到高一致性，需要同步非常大量的数据。无论是对于移动网络，还是固络都是不合适的。
服务器逻辑简化。采用帧同步方案，服务器只需要做简单的帧同步，不需要关心太多的业务细节。有利于客户端功能的扩展和服务器的稳定和性能。
反作弊。客户端只需要在适当机时上报校验数据给服务器，服务器对2个客户端上报的数据进行对比，就可以快速识别是否有人作弊。然后通过无收益的方式间接防止作弊。
那么，为什么选择UDP而不是TCP呢？主要有2点原因：
弱网络环境。
实时性要求。
我们通过一个测试APP，在WIFI和4G环境下，采用TCP和UDP两种方式连接同一个服务器，分别获得对应的RTT进行对比。
| RTT (ms) | UDP | TCP |
| WIFI | 270 | 320 |
| 4G(%20丢包) | 240 | 400 |
| 4G(50MS抖动) | 220 | 320 |
| 4G(%5丢包50MS抖动) | 200 | 300 |
我们可以发现，在弱网络环境下，UDP的RTT几乎不受影响。而TCP的RTT波动比较大，特别是受丢包率影响比较明显。
由于UDP具有不可靠性，所以在UDP的基础上实现一个自定义的协议栈：FSP，即FrameSyncProtocol。
FSP的基本原理就是防照TCP的ACK/SEQ重传机制，实现了传输的可靠性，同时还采用冗余换速度的方式，又保证了传输的**速率。在帧同步方案中一举两得。
如下图所示，客户端A的操作A1与客户端B的操作B1封装成OperateCmd数据发送给PVP服务器。PVP服务器每66MS产生一个逻辑帧，在该帧所在时间段内收到A1和B1后，生成一个Frame数据块，在该帧时间结束时，将Frame发送给客户端A和B。Frame数据块内有该帧的帧号。客户端A和B收到Frame数据后，便知道该帧内，客户端A和B都做了什么操作。然后根据收到的操作A1和B1进行游戏表现，最终呈现给玩家A和B的结果是一致的。从而实现客户端A与B的数据同步。
图1 帧同步技术原理
如下图所示，发送者维持一个发送队列，对每一次发送进行编号。每一次发送时，会将待发送的数据写入队列。然后将队列里的数据+编号发送给接收者。
接收者收到数据后，会将该编号回送给发送者以确认。发送者收到确认编号后，会将该编号对应的数据包从队列中删除，否则该数据仍保存在发送队列中。
下次发送时，会有新的数据进入队列。然后将队列中的数据+最新的编号发送给接收者。以此循环反复。
图2 FSP协议栈原理
上图解析：
第1次发送，在发送队列里只有Data1，于是将Data1和编号1（Seq=1）发送给接收者。收到确认编号1（Ack=1）后，将Data1从队列中删除。
第4到7次发送，由于从第4次发送开始就没有收到确认编号，于是队列中包含了Data4到Data7。第7次发送后，收到确认编号6，于是将Data4至Data6从队列中删除。
第8次发送，队列中包含Data7和Data8。发送后收到确认编号8，从而将Data7和Data8从队列中删除。
以上的关键点是，发送者未收到确认编号，并不一直等待，而是会继续下一次发送。结合图1：
如果发送者是服务器，则会每隔66MS会将一个Frame数据写入发送队列，然后将该队列里的所有Frame数据一起发送给客户端 。
如果发送者是客户端，则会在玩家有操作时，将玩家的每一个OperateCmd数据写入发送队列，然后将该队列里的所有OperateCmd数据一起发送给服务器 。如果发送队列不为空，则每隔99MS重复发送。如果发送队列为空，则不再发送。直到玩家下一次操作。
由于服务器和客户端即是发送者，又是接收者。则服务器和客户端的每一次发送，除了会带上该次发送的编号，还会带上对对方发送编号的确认 。
图3 PVP通讯模块整体框架
这是一个典型的手游PVP通讯模块的整体框架。这里主要分享一下FSP模块和帧同步模块的技术实现。
FSP模块主要用来实现FSP协议栈。其协议格式定义如下。
FSP上行协议定义：
| Seq | Ack | SomeData | OperateCmd List | CheckSum |
· FSP下行协议定义：
| Seq | Ack | Frame List | CheckSum |
如下图所示，是FSP模块的接收逻辑流程。
图4 FSP模块接收逻辑流程
其中关键点是：
对Recv New Ack判断，对曾经发送过的Operate进行确认删除。
对Recv New Seq判断，过滤掉因为网络问题造成乱序的包。
上图中，接收到的Frame最终都存储在RecvQueue中。我们将接收逻辑放在子线程中。所以只需要在主线程中需要Recv的时刻从RecvQueue中读取FremeList即可。
如下图所示，是FSP模块的发送逻辑流程。发送逻辑同样放在子线程中。发送逻辑有2种触发方式：
业务层主动调用发送
每隔指定时间触发一次（在WIFI和4G下使用不同的时间，可以减少服务器收到的纯确认包比例，有利于提高通讯性能）
图5 FSP模块主动发送逻辑流程
图6 FSP模块定时发送逻辑流程
下图是帧同步模块的实现框架。
图7 帧同步模块实现框架
按照上图箭头编号描述如下：
（1）负责接收来自FSP模块的FrameList。
（2）将FrameList里的每1帧都存入FrameQueue。
（3）同时将FrameList的每1帧的帧号进行变换后，得到客户端帧号。同时，在等下1个服务器帧到来之前，需要将客户端的帧锁定在下1个服务器帧的前一帧（LockFrameIndex）。然后 将FrameIndex和LockFrameIndex传入FrameBuffer。
（4）客户端每1帧从FrameBuffer中取出当前可能需要跳帧加速的倍数（SpeedUpTimes）。
（5）如果SpeedUpTimes为0，则表示正在缓冲中，没有需要处理的帧。如果SpeedUpTimes是1，则表示缓冲结束，但是不需要加速，只需要处理最新的1帧。如果SpeedUpTimes大于1，则从FrameQueue里取出这SpeedUpTimes个帧， 将里面的SyncCmd取出来。
（6）将SyncCmd传入OperationExecutor。
（7）OperationExecutor与具体游戏的业务逻辑相关联，负责将SyncCmd传入给业务逻辑和预表现模块进行具体的处理。
其流程图如下：
图8 帧同步逻辑流程1
图9 帧同步逻辑流程2
在传统网络模块开发思想中，当发送超时达到阀值，或者底层判定断开连接时，需要重新建立连接。之前这部分工作是交给一个偏上层的模块来执行，该模块需要等Apollo通讯模块连接成功之后，才进行PVP通讯模块的连接。这样使逻辑变得复杂。
由于UDP本身的不可靠性，可以认为网络断线也是其不可靠性的一部分。
而FSP协议栈就是为了解决UDP的不可靠性而设计的，所以也附带解决了断线重连问题。
去除了原来的断线重连逻辑之后，用FSP模块本身的特性来处理断线重连，实测能够提高网络恢复的响应速度。由于PVP服务器设定的超时阀值是15秒，有些时候，其实网络已经恢复，但是由于Apollo通讯模块对网络的恢复响应过于迟钝，造成不必要的判输。
从目前接入GSDK后的数据来看，能够减少一定的网络延时，但是并不明显。
AckOnly优化是指减少服务器收到的纯确认包数据。这样做的目的是：
减少包量，有助于在WIFI下节省路由器性能。GSDK有个统计表明，有大概20%多的网络延时是因为路由器性能造成。
节省流量，一定程度上也可以节省网络设备性能，同时在4G下为用户省钱。
该优化分2部分实现：
（1）空帧免确认
（2）WIFI延迟确认
在优化前的AckOnly比例为：57%
空帧免确认优化后降到：38%
WIFI延迟确认优化后降到：25%
将FSP模块抽象得与业务无关，使之可快速完成一个使用帧同步方案通讯的Demo成为可能。
实验了本地局域网PVP对局，只要在同一网段下，可以成功对局。（如果有需求，可以实现该功能）
实验了本地蓝牙PVP对局，发现蓝牙是带连接态的，并且其通讯是用类似TCP的数据流进行的。同时它与WIFI信号有干扰，如果开启WIFI，其延时非常高。在非WIFI下，其单条数据的延时很低，但是如果以66MS的频率发送数据，则延时又非常高。
建立了一套用于FSP在线诊断和断线诊断的工具。
感谢Gates让我重构PVP通讯模块，以及Kevin帮忙统计数据。
946
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
