一、背景
游戏（主要）使用状态同步，由服务器以固定间隔下发给客户端
1.使用状态同步的优势
1. 服务器权威保障公平性
- 反作弊能力突出：SLG 攻城涉及资源掠夺、胜负判定等核心利益，服务器作为唯一权威源（如计算部队碰撞、伤害结算）可有效防止客户端篡改数据。例如《部落冲突》的反作弊系统通过实时监控资源流动和操作轨迹，封禁率达 63%。
- 复杂逻辑集中处理：攻城时需同步建筑状态、部队移动、技能释放等大量数据，服务器集中运算可避免帧同步因客户端逻辑差异导致的状态不一致。
2. 带宽优化可行性高
- 差分同步与状态压缩：仅传输变化的状态（如部队位置增量），结合二进制压缩（如《部落冲突》将单位状态包从 12KB 压至 1.8KB），可大幅降低带宽消耗。
- 区域同步（AOI）：通过九宫格划分视野范围，仅同步玩家可见区域的部队和建筑状态，避免全服广播。例如《列王的纷争》攻城时，服务器仅向参战玩家同步战场数据，非参战玩家不受影响。
3. 支持大规模玩家并发
- 云服务器弹性扩展：采用分布式架构（如 AWS EC2+S3），可动态分配计算资源应对万人同服压力。例如《Top Heroes》通过云服务器实现全球同服，支持跨平台无缝切换。
- 延迟补偿技术：客户端预测 + 服务器校正机制（如《部落冲突》的预测补偿算法）可在 300ms 延迟下保持建筑升级进度 100% 同步。
2.使用状态同步的劣势：
1. 高延迟与网络抖动敏感
- 锁步机制的致命缺陷：帧同步要求所有客户端按固定帧率推进，若某玩家延迟过高，会导致全体卡顿。例如《魔兽争霸 3》的局域网对战常因个别玩家网络波动出现 “卡帧”。
- 延迟补偿难度大：SLG 攻城涉及长距离行军（如部队移动 10 分钟），帧同步难以预测路径变化，易出现 “瞬移” 或 “穿模”。
2. 计算压力与开发成本
- 客户端算力要求高：帧同步需每个客户端独立计算所有部队 AI、物理碰撞等逻辑，低端设备可能因性能不足导致同步失败。
- 代码确定性挑战：浮点运算、随机数生成等细微差异可能导致状态分歧，开发需使用定点数、统一随机种子等严格规范。
3. 扩展性与防作弊短板
- 玩家数量受限：帧同步服务器需转发所有客户端指令，随着参战人数增加（如百人攻城），带宽和算力呈线性增长，难以支撑大规模场景。
- 客户端作弊风险高：帧同步逻辑在客户端执行，易被逆向破解（如修改部队攻击力），需额外增加哈希校验、关键帧服务器验证等复杂机制。
3.绘图相关解释
横轴表示帧的编号，纵轴表示这个数据包在游戏内被处理的时间点与上一帧数据被处理的时间点的时间差。假设服务器发送UDP数据的频率为20帧/秒，即50毫秒/帧。
4.服务器的“帧”与客户端的“帧”的区别
1. 服务器 UDP 数据的帧：逻辑更新与状态同步
服务器发送的 “帧” 本质上是游戏逻辑的更新频率，用于同步游戏世界的状态。例如：
- 游戏规则执行：角色移动、物理碰撞、技能释放等逻辑计算，通常以固定频率（如 20 帧 / 秒）在服务器端循环执行。
- 状态广播：服务器将每一帧计算后的游戏状态（如玩家位置、血量、道具变化）打包成 UDP 数据包，发送给所有客户端。
- 网络协议设计：例如 Source 引擎的
tickrate（默认 66 帧 / 秒）决定了服务器处理玩家指令和物理模拟的频率，而客户端接收快照的频率（如cl_updaterate 20）可能低于服务器帧速，通过插值技术实现平滑显示。
2. 画面刷新率：GPU 渲染与视觉流畅度
画面刷新率是客户端 GPU 每秒渲染的图像帧数，直接影响视觉体验：
- 硬件驱动：显示器通常支持 60Hz（60 帧 / 秒）或更高的刷新率，而游戏引擎（如 Unity、Unreal）会根据硬件性能动态调整渲染帧率。
- 独立于服务器逻辑：即使服务器以 20 帧 / 秒发送数据，客户端仍可能以 60 帧 / 秒渲染画面，通过插值技术填充服务器帧之间的空隙，避免画面卡顿。
- 优化策略：若服务器帧速较低（如 20 帧 / 秒），客户端会通过外推法预测物体运动轨迹，确保画面流畅。
3. 两者的关系与技术实现
- 解耦设计：服务器帧与渲染帧相互独立，避免互相拖累。例如：
- 服务器专注于逻辑计算（20 帧 / 秒），客户端专注于高帧率渲染（60 帧 / 秒）。
- 物理引擎（如 Unity 的 FixedUpdate）可能以更高频率（如 50 帧 / 秒）运行，与服务器帧或渲染帧均不绑定。
- 网络同步机制：
- 状态同步：服务器将逻辑帧的结果发送给客户端，客户端根据接收到的状态更新本地画面。
- 帧同步：所有客户端以相同帧率（如 20 帧 / 秒）执行逻辑，并通过服务器同步操作指令，确保状态一致。
- 延迟补偿技术：服务器会记录玩家的历史位置，处理攻击判定时考虑网络延迟，避免因客户端与服务器帧不同步导致的不公平现象。
5.状态同步和帧同步对比
见此链接
二、不同网络状况下的散点图表现
① 正常运行（无网络卡顿）
- 点基本沿一条水平带聚集，纵坐标在 ≈50 ms 附近，只有小抖动（比如 ±几 ms）。
- 横轴帧号连续，点均匀分布在横轴上。
- 视觉印象：接近一条粗直线（y ≈ 50ms）。
② 丢包
- 在发生丢包时，横轴上会出现“跳号”（帧号不连续，缺了被丢的帧）。
- 对应的纵坐标会出现 倍数的 50 ms 峰值（例如丢 1 包时下一点 ~100 ms，丢 2 包时 ~150 ms，……）。其他大多数点仍在 ~50 ms 带。
- 视觉印象：大部分点在 50 ms 水平带，偶尔在某些 x 上出现明显的垂直“尖刺”并且那些 x 前后有编号缺口。
③ 数据包积压（帧堆积 / backlog）
（常见场景：网络抖动或延迟使多帧到达客户端排队，客户端随后快速消费队列以追帧）
- 横轴帧号通常连续（因为包没丢，都是到达了）。
- 当客户端“追帧”时，会看到许多相邻帧被快速连续处理，因此这些相邻点的纵坐标会非常小（接近 0 ms 或几 ms）——即一簇簇垂直靠近 x 轴的点。
- 在处理完一簇后，可能会出现一次较长的等待（等新数据到来），那时会看到一次较大的纵坐标（可能是几百 ms），然后又是一簇小值。
- 视觉印象：横轴上帧号连续，但点聚成“簇”：很多点靠近 0（短时间内快速处理多帧），簇与簇之间有较大的间隔/少数高位点（长等待）。
数据包积压示意图：
三、丢包情况下散点图情况研究
丢/不丢是二值事件（0/1），单个包的自然模型是伯努利试验（概率 ppp 的“失败/丢包”）。对一段时间内的丢包计数，才会是二项分布；在样本量很大且做平均时，根据中心极限定理，均值可能近似正态（不等同于“每个包的丢包概率服从正态”这个说法）
实际网络常有突发丢包（burst）、重传、队列溢出等机制，产生时间相关性——这不符合独立同分布的正态近似。延迟/jitter 在某些条件下偶尔可用接近高斯的模型描述，但丢包通常更稀疏且可能有长尾或成簇特性。
1) 独立伯努利丢包（每包丢失概率 p，相互独立）
2) 泊松/随机稀疏模型（按时间发生）
- 丢包事件在时间上近似为泊松过程时，丢包间隔（以帧数计）近似服从指数分布，故 Δ 的“倍数”出现间隔为指数分布——看起来是随机但孤立的尖刺（没有长簇）。和独立伯努利类似，但更侧重时间尺度建模。
3) 成簇/突发丢包（Gilbert–Elliot 等马氏模型）
- 这里丢包不是独立的：在“坏”状态丢包概率非常高，在“好”状态很低。结果是长连续丢包段比 p^k（独立模型）更常见。
- 散点图表现：会看到较长且连续的高倍数尖刺（例如连续若干个很大的 Δ，对应多帧连续丢失），而且这些尖刺往往成簇出现（在一段时间内频繁大间隔），不是孤立的单个大尖刺。
