著名游戏网络同步方案
- 网络传输协议(Network Transport Protocol)
- 网络同步模型(Network Model): lockstep(停等同步算法)、statusstep(状态同步算法)
- 网络拓扑结构(Network Topology):P2P、CS
什么是网络同步?
网络同步 = 实时的多端数据同步+实时的多端表现同步(数据同步是后端操作,而表现同步就是让前端对后端同步过来的数据进行进一步的处理从而达到表现上的一致)
直接使用简单粗暴的数据同步会使得画面有顿挫感,并且受网络波动影响较大。
所以就出现了很多著名的游戏同步方案
只看同步关系的确定性锁同步:
本文不讨论快照同步(Snapshot Synchronization、Snapshot Interpolation),认为其等同于状态同步(State Synchronization)。
插值算法也就是跟随算法,比如说LOL:下路从塔下移动到草里,点击键盘标记一个点,服务器会计算角色移动属性值返回给客户端,客户端收到移动属性值后表现为匀速前进。对线下路也会收到对方坐标信息,可能是使用KCP协议做的同步。
一:网络传输协议(Network Transport Protocol)上的选择看:
大多网络游戏采用UDP。UDP增加了端口(Port)的概念,收发双方从而能通过约定好的几个端口来进行不同功能的通信;增加了校验和以增加了一定的校验能力。
所以也能看到UDP其对于网络游戏来说,和IP几乎有很相似的特性,不提供可靠传输、流量控制、拥塞控制。
TCP更加适用于回合制等慢节奏游戏,如炉石传说等。提供三次握手四次挥手的可靠传输;提供作用于接收方,控制发送方的发送速度,防止分组丢失的流量控制;作用于网络,防止过多的数据注入网络,避免网络过载拥塞控制。
慢开始:发送方先探测网络的拥塞程度,从小到大逐渐增大发送窗口。
拥塞避免:控制拥塞窗口的增长速率,每次RTT往返后,拥塞窗口+1。
快重传:当发送方没有在超时期限内收到确认信号时,立即重传丢失的报文段。
快恢复:在快重传后,避免直接重传导致网络阻塞,先将拥塞窗口设置为慢开始门限值,然后执行拥塞避免算法。
二:从目前国外谈及的网络同步模型上看:
主要的网络模型是锁步同步(Lockstep)和状态同步(State Synchronization)。
也就是逻辑帧输入一致的算法都叫做 锁步同步
帧同步具体优化手段
1)乐观帧锁定
2)把渲染与同步逻辑拆开
3)客户端预执行
4)将指令流水线化,操作回滚
5)要不要回滚?
6)要不要服务器跑一套完整逻辑?
7)操作要不要是键鼠?还是高级命令?
8)客户端要不要像视频播放器一样保证平滑缓存1-2帧?
9)要不要保证平滑加一层显示具体对象的对标插值?
大体的思路是利用玩家角色的SOI(Spheres of Influence,和AOI概念差不多),两个玩家如果相距很远互不影响,就采用本地时钟向前推进(非Lockstep方式同步),如果互相靠近并可能影响到对方就变回到严格的LockStep同步,这里并不保证他们的帧序列是完全一致的。
数据同步就是纯服务器干的事情了,帧同步就是2者一起干的。
越是要快的东西 就越不能让服务器去计算
有可能socket发出去的一个包给客户端,客户端会接收到2个不同的帧,合并在一起,有可能因为网络缘故去把帧接收慢了,表现上有误,那都是客户端的优化了。前端跑一遍帧,然后丢给服务器去跑一遍逻辑帧上的数值与效果计算。比如技能的实现,数值与伤害减扣数值 然后效果表现与技能释放
参考:
https://blog.csdn.net/weixin_43679037/article/details/125949008
https://blog.csdn.net/weixin_43679037/article/details/122848197
https://blog.csdn.net/weixin_43679037/article/details/121858644