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接收的瞬间是过去的信息。