Games104现代游戏引擎笔记 网络游戏架构基础

挑战1:网络同步

挑战2:是网络的可靠性，包括应对网络的延迟，丢包和掉线
挑战3: 反作弊和安全系统，因为网络游戏的本质是经济系统
挑战4:多样性(不同设备，不同服务器)，在不停服的情况下热更新
挑战5:大量人数时对高并发，高操作的要求

Network Protocols 网络协议

Socket编程，通过接口，确认好相互的协议，就可以快速的建立持续的链接
国内是IVP4 居多，最好兼容IPV6，这是世界标准
通过三次握手建立可靠的连接，确保发送的包是有顺序的，会进行流量控制，但网络阻塞时会自动降低发包的效率
基本原理：当任何一个接受者收到一个信息时，给sender发送一个ACK(告知)，当sender收到ACK时，才持续的往后发包。如果sender未收到ACK，会持续发送同一个消息
阻塞控制：滑动窗口，可以动态的控制发送数据的大小，当发生阻塞，丢包或者超时时，按照一定算法减少滑动窗口
端对端的传输，更简单，不需要建立长时间的连接，不需要一定要保证稳定，不管有没有收到，不管顺序，不管流量控制。发送完就不管了
对于时间(延迟)不太敏感的操作类型的游戏，可以选择TCP，对于响应特别快速(FPS类)，尤其在公网这种不稳定的网络下，用UDP反应较快
对于大型的MMO类型这种来说，不会用单一协议，会用组合协议，用TCP协议来进行签名认证，确认登陆，建立账号连接，心跳包等。当游戏进入到战斗，进入到这个世界里时改用UDP，在聊天，邮件等，又走回TCP通道。

TCP太慢了，需要稳定发送上一个消息，才能继续发下一个消息，并且效率随着带宽变化不稳定

UDP不可靠，无法确认消息到底有没有发送成功

实战中常常对协议进行深度的改造，定制适合的协议：基于UDP的可靠连接
1.需要可靠的连接(TCP)
2.保持一定的顺序(TCP)
3.需要非常快的反应，最好没有延迟 (UDP)
4.需要群发(UDP)

ACK：确认收到
NACK：什么包没收到
SEQ：序列号

ARQ：当我建立一个网络连接传包时，如果我丢包或者未收到，能够有办法能告诉对方


滑动窗口协议：当有很多数据要传输时，会一次性把窗口里的数据全部传输，当我收到接收方返回的ACK包时，如果我收到的2号包的ACK，便确定0，1，2都已传输到位，接下来传输3，4，5，6，因为3已经传了，只需传输4，5，6，直到收到剩下包的ACK，窗口便继续往下滑动

窗口设成1，每个包发送完后要等ACK收到，才往下走

如果发现窗口里的一个包丢失，只把窗口里的包再传输一遍。窗口持续往下走，会被告知NACK(哪个包丢失)，把丢失的包重新发送。连接更稳定，能减少带宽的浪费，但是有额外ACK类型，即NACK
解决UDP丢包的问题
丢包率低一个值的时候不管，然后通过FEC的方式把丢掉的包在传输段的另一头计算回来，通过额外的数据量换取稳定性


增加一个E(异或运算校验位)，丢包后的数据可以通过异或校验位还原

对D构建一个矩阵B(确保任意抽掉若干行，仍然是一个可逆的矩阵)，
B矩阵 乘以 D 矩阵 得到了 G，包含了三个其他多算出来的
传输中出现丢包
B`相对于 B的去掉了丢包数据的行数

B` 的逆矩阵可以重新将数据还原

总结：构造一个矩阵，确保矩阵抽掉若干行仍然可逆。将拿到的信息乘上，抽掉了对应行矩阵的逆，就可以恢复原始信息
定制自己独立的UDP策略：对ARQ有所理解，使用滑动窗口的方法(一个pool)去传递数据，确定resending/retransimission的策略，加上一定FEC的算法，保证即使在一定的丢包率下，包体仍然能正确收到，确保ACK尽量的成功

Clock Synchronization 时钟同步

RTT和Ping非常接近，区别是Ping更底层，是不同的协议层
RTT 很多时候是应用层自己写的，游戏里很多时候不用区分的太严格，RTT用的多一点




在协议包里有四个时间
t0：客户端发送的时间
t1：服务器收到的时间
t2：服务器发送的时间
t3：客户端收到的时间

通过这个算法可以估算出RTT
案例：延迟delay是4秒，按延迟即服务器发送的时间t3，客户端接收到的时间应该是35秒，与客户端本地时间05秒相差30秒。则估算出客户端和服务器相差30秒

算法与现实不符合的假设是：
1.网络的速度是恒定的
2.上下两路是对等的

1.先跑一边NTP算法，算出服务器和客户端的时间差
2.快速调整客户端的时间，然后做多次NTP算法，算出一系列NTP算法
3.把大于offset平均值50%的值扔掉，然后按剩下的offset值取平均值做时钟校准
链路不可靠的情况下，只能逼近准确的服务器时间，无法真正的完全校准

RPC Remote Procedure Call 远程程序调用

socket 编程模式缓解了复杂计算机网络架构的困难，但是在游戏业务逻辑方面其还有一系列的问题

socket 编程会需要使用到Messages的方式来工作，定义很多的消息，消息里面会包含很多的参数

客户端和服务端很多时候系统 OS 不一样
1.常见的有Linux作为服务器收发处理数据，客户端是安卓， IOS，Windows
2.Big Ending 和 Small Ending, 高位在前还是低位在前
3.数据打包之后需要对齐（4个Byte为单位），否则就会有很多空间浪费
4.解密和加密
让程序员像正常写业务代码，作为一个库存在，然后传入参数。之后如何变成Message，如何打包，如何序列化，网络如何路由到服务器，服务器如何接受，处理消息，如何返回等等这些都交给RPC来完成
案例
免去后台的处理过程，专注业务逻辑

IDL Interface Definition Language 界面定义语言

IDL 会定义各种参数，类似schema的定义
RPC Stubs RPC 存根:
当一个客户端或服务器起来之后，彼此会告诉对方自己上线，然后注册一大堆的RPC（用来个函数调用）。
每次call RPC时可以在RPC的存根里查询，如果没有对应RPC，系统会报错，但不影响其他业务逻辑的运行。

真实RPC路径：发出RPC请求后，首先进行压缩，加密，然后网络传输，服务器接收后，进行解密，解压缩

Network Topology 网络拓扑

现在多人游戏用的比较少，很多时候是点对点时使用，主要是switch这种局域网上使用p2p连接
p2p一般不会考虑作弊，没有什么限制
相比P2P，会选择一个玩家作为一个主机然后传输，早期网吧很多局域网游戏是这种类型。
现在一些沙盒类游戏，还有steam上的很多游戏是这种方式
不需要开发商维护一个服务器，玩家自己可以作为服务器
专用服务器：用于更复杂的大型MMO，电竞对战
会在服务端维持一个一致的世界，所有的客户端获得相对公平且稳定的连接

当跨越大洋的时候，物理延迟就是也需要考虑的。尤其是对于全球发行的游戏
所以各个区域一般都设置Protol，然后protol通过专有网络会链接到服务器上，从而不会使用公网的转跳，大大降低延迟
网络游戏加速器也是基于这个原理

Game Synchronization Intro 游戏同步

单人运行，单人输入


操作和显示是有延迟的，所以需要同步两个世界
1.快照同步 2.帧同步 3.状态同步

Snapshot Synchronization：

客户端只负责把输入发给服务器
服务器进行整个游戏世界的模拟
把整个游戏世界的状态生成一个快照（每个物体的血量，位置，速度。。。）
将快照发送给客户端
客户端展示快照的数据信息，（渲染绘制）
保证了整个世界状态的一致性，客户端只是一个渲染绘制的表现。


服务器会希望快照的计算不要占用过多的带宽，帧率会较低，10-20左右，客户端为了更丝滑的效果，帧率会更高。
客户端会在两个服务器快照之间进行插值


快照的数据量较大，且往往两个快照间多数物体没有变化，因此快照一般传递的是变化量，减少传输数据的大小
优点：
1.代码非常的简洁干净
2.绝对一致，无法作弊
缺点：
1.客户端的算力被浪费掉
2.生成快照的数据量很大，所需的上传带宽非常大

Lockstep Synchronization


可以理解为军队行走，整齐划一，某种程度上的高度性
也可以理解为是有回合制的，是有顺序的，类比与下棋
所有的信息一致性的同步的传递给目标，目标一致的处理

最简单的思想
所有客户端的操作统一的发给服务器，服务器再同一的分发给客户端，客户端做一致的模拟。
服务器一般做信息的汇总，同步及转发的处理


第一步初始化游戏内的初始状态（王者荣耀的加载条），必须要做到完全的一致，因为同步的是操作，如果初始条件有一丝偏差，最终结果可能误差非常大。
还需要同步时钟

每一帧都接受所有的客户端输入，确认收到所有输入后统一的发给所有人，所有人然后同时开始模拟

优点：简洁明了
缺点：延迟非常明显，所有人的延迟等于延迟最高客户端的延迟


公网帧同步的优化：
引入了Bucket，每隔一个Bucket(例如100ms)的时间内， 未收到客户端的操作，则丢弃这个客户端的操作

网络差者获利，与网络优者获利。权衡一致性和实时性

帧同步需要整个游戏逻辑具有确定性(Deterministic)
一样的输入，经过各种复杂的迭代运算后，保持一致结果很难
浮点数
随机数
数据容器，计算的算法
数学库
物理的模拟
逻辑执行顺序
帧同步上述一定都要保证一致

浮点数存储要符合IEEE754的标准，可以严格意义上保证浮点数一致性
但是不同平台的实现是不一样的

很多数学运算中需要用到三角函数，根号等，需要用查表法：所有的数字必须要是锁死的，不能各自算各自的
使用Fixed-point number 定点数的方法来计算，使用固定长的数字来处理数学运算，从而保证高度的一致性

整个游戏保持一致确定性几乎是不可能的，要把最核心的业务逻辑确定一致性。比如角色的移动，位置，血量，一些游戏的状态。但是渲染这种不确定不会有太大影响

同步随机数种子，且随机算法必须一致

游戏的确定性是帧同步的基础，如果无法保证一致性，则帧同步不能成立

跟踪和调试
错误是会不断累积的，需要不停地把游戏的状态保存下来，使用checksum的方法。
checksum：把现在所有的变量存在一起，算出一个md5编码，存出去，把游戏里所有的函数的call和parameter编程一个hash值存在那。可能每5-10帧，存下快照，包括input也保存快照

滞后和延迟
把服务器传过来的帧cache几帧，当服务器出现延迟，本地逻辑帧依旧能从cache获取
例如网络视频播放，是分成很多块，每次下载好几块作为cachebuffer
逻辑帧和渲染帧分离：
服务器差不多10帧，期间插入很多渲染帧。

当网络出现延迟或者各种问题时，渲染帧，画面不会因此出现各种各样的抖动。


断线重连：
客户端不仅仅只接收input，每隔一定帧数会有特定key frame把当前所有游戏的状态做一个snapshot并存在本地的内存或磁盘，保证游戏即使崩溃，snapshot的快照还在。
每次重连，从上一次快照的帧数开始演算到当前的帧数。避免从头开始演算

如果发生了重连情况，那么可以放弃渲染帧，只跑逻辑帧，以更快速度的逻辑帧，一定能追上现在游戏的进度

服务器再一些特定的keyFrame保存一个快照

当有些玩家断线时间过长，服务器可以给个更新的快照，帮助客户端设置游戏的状态

另一个应用是观战模式
观战实际上与断线重连的底层技术一模一样。服务器把前面关键帧的信息发送给客户端，再把参与玩家的input发送给客户端。注意观战发送的数据是有主动延迟防止作弊
回放同理

帧同步防作弊
多人情况下：投票机制，每隔一段时间，让所有客户端把游戏里状态的checksum校验码发给服务器，然后进行对比，有不一样的直接踢掉
双人对战的情况下，服务器会有个checksum。有来校验。（通常大部分双人游戏，都是采用p2p，很少帧同步。除非是电竞属性很强的游戏）

帧同步的一个难点是：所有的信息和状态都在客户端上模拟，理论上可以还原出一些不该让玩家看见的信息，例如moba的全图和fps的透视
现代的游戏不会单纯的使用最简单的帧同步，会有很多复杂方法策略的帧同步来规避
优点：
1.带宽要求低，仅同步指令
2.解决确定性问题之后，开发效率很高
3.可以做一些对打击操作非常敏感，精确的游戏
4.方便做游戏录屏

缺点：
1.保持一致性很难
2.难以防止全图挂这种问题
3.如果没有服务器快照，断线较长时，追赶问题会比较严重

State Synchronization

核心思想是不会同步整个宇宙。
每个玩家只会提交自己部分的信息和部分的状态，每个玩家自己模拟自己的世界。
服务器会模拟一个完整的全宇宙，只会把部分的信息，和当前玩家相关的信息发给对应客户端
放作弊的能力会好一点点
Server最大，一切指令以服务器优先级最高
Authorized：是这个玩家对于本身local的操作
Replicated：其他玩家看到的这个玩家的复制品，依赖于服务器传输的信息
玩家1与玩家2客户端看到的情况
玩家1:开火，发送服务器
服务器：玩家1开火，广播所有客户端
玩家2：收到通知，玩家1开火


服务器通知每个客户端重复玩家1炮弹的运动

服务器判定击中了一个单位，广播给所有客户端
状态同步核心思想：
每个人提出自己的动作，整个世界的核心业务逻辑由server完成。server产生的结果与client提出的动作都会被同步给所有客户端。
并不要求所有的客户端保持高度一致性，只需要服务器做出判断。
状态同步只同步对于客户端需要的信息，即一个感知范围内的信息(AOI算法)
有个问题是玩家A如果自己需要操作，如往前走，依旧需要等待服务器的确认，这就会造成非常大的延迟，导致操作不顺手。
1.客户端预测
2.服务器校验

根据客户端预测，提前移动，服务器校验没问题则保持不变
由于RTT和一个command frame的延迟，会导致客户端永远比服务器超前
守望先锋：估计一个RTT，约160ms，半个RTT 80ms，一个command frame 16ms(刷新率60帧每秒)，则客户端永远往前预测16+80ms，等服务器消息回来后，进行对齐，对齐是个插值的过程，尽可能使移动变得平滑
client本地一个消息发出到从server回来接收可能长达上百毫秒，本地可能已经跑了好几帧，此时会把本地的每一次预测和每一个状态全部buffer到一个序列帧里。当server的每一个信息回来时，会和过去的信息进行检验。因为从server回来的信息是经过了半个RTT时间的传输，对于client接收的瞬间是过去的信息。
如果和server的校验信息不一致，则以server的信息反向校准
从client角度看，会有做了某件事，但被校准回退的情况发生client需要一个ring buffer，存储在过去几帧的数据，当发现校验问题时，ring buffer之后的数据全部无效，重新算一遍
online游戏很常见，对网速慢的玩家不利，因为对世界的更新不及时，操作反应不如网速快的玩家
丢包问题：
1.server会把用户的输入，用一个ring buffer存储起来，会存储好几帧的输入
2.如果在一定时间内，接收不到用户的输入，有时候会自动把过去的最后一次操作进行复制(如，跑动过程中断网，在其他客户端展示的是扔在一直跑)
3.不同游戏有不同的处理丢包策略

number of players反了
帧同步：适合注重打击感，对抗感，竞技类的游戏。对引擎的要求很高，需要引擎的核心逻辑业务确定性非常高
状态同步：适合网络本身比较复杂，不太稳定，并且游戏业务比较复杂。以及游戏的参与者非常多
现代主流引擎大部分能实现状态同步，实现帧同步通常需要自己的引擎团队专门定制。