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