身为一名游戏客户端、工作三年以来除了使用过网络请求，完全没有使用过网络连接，最近使用Godot尝试局域网联机，因此研究一下网络模型
以下是您提供的文章的逐段详细解析，结合技术要点和实际应用场景：
一、P2P锁步模型（Peer-to-Peer Lockstep）
核心机制
- 工作原理：所有玩家设备（节点）直接互联，每帧交换操作指令（如移动、攻击）。所有设备从相同初始状态出发，通过完全相同的指令序列和逻辑计算推进游戏状态。
- 示例：《帝国时代》中，每个玩家的输入（如建造建筑）会被广播给其他玩家，所有设备独立计算整个游戏世界的状态。
优点
- 低带宽需求：仅传输操作指令而非完整状态，适合单位数量庞大的RTS游戏（如数千个单位）。
缺点
确定性难题
- 问题：不同设备的浮点运算、指令顺序等微小差异可能导致状态不同步（如单位路径计算误差）。
- 现实案例：某单位在A设备上因计算顺序早0.1秒到达战场，而在B设备上晚到，导致战术结果截然不同。
- 解决方案：严格限制非确定性操作（如禁用浮点运算，使用定点数），或通过定期同步校验状态。
延迟累积
- 问题：所有玩家必须等待最慢设备的输入，导致全体延迟等于最差玩家的网络延迟。
- 缓解手段：RTS游戏常通过“延迟补偿”（如预判单位动作）和视觉效果（即时音效）掩盖延迟。
初始状态同步困难
- 问题：中途加入游戏的玩家需获取完整的初始状态，这在实时对战中几乎不可行。
- 例外情况：部分游戏（如《星际争霸》）允许玩家中途加入，但需复杂的状态快照和回放机制。
二、客户端/服务器模型（Client-Server）
核心机制
- 架构变革：所有玩家作为客户端连接中央服务器，服务器负责计算权威游戏状态并同步给客户端。
- 示例：《Quake》中，客户端仅发送按键输入，服务器计算角色移动和碰撞，客户端仅渲染服务器返回的状态。
优点
- 消除P2P延迟瓶颈：延迟取决于客户端与服务器的直接连接，而非其他玩家的延迟。
- 动态加入支持：新玩家可随时加入，无需同步完整初始状态（只需当前状态快照）。
- 防作弊能力：服务器验证所有操作合法性（如移动速度是否合法），减少外挂可能性。
缺点
- 服务器成为单点故障：需高可用性架构（如《英雄联盟》的多区域服务器集群）。
- 带宽压力：服务器需向多个客户端广播状态更新，玩家数量增加时带宽消耗剧增。
- 客户端延迟感知：玩家输入需等待服务器响应，导致操作反馈延迟（如按下射击键后需等待服务器确认命中）。
三、客户端预测（Client-Side Prediction）
核心思想
- 本地模拟：客户端在发送输入后立即本地模拟角色运动（如向前移动），无需等待服务器确认。
- 示例：在《使命召唤》中，按下开火键后，子弹立即从屏幕射出，即使服务器尚未确认是否命中。
技术挑战与解决方案
服务器权威性与纠正冲突
- 问题：若客户端预测与服务器状态不符（如被击中后位置回滚），需“无缝修正”以避免画面突兀跳变。
- 解决方案：
- 状态缓冲区（Circular Buffer）：客户端保存过去N帧的输入和状态。
- 回滚与重放：收到服务器纠正指令后，丢弃冲突的未来状态，从纠正点重新模拟（使用缓冲的输入数据）。
- 示例：若客户端预测角色位于位置A，但服务器校正到位置B，客户端会“倒带”角色动作，使其看似从B自然移动到当前预测位置。
作弊防护
- 服务器校验：关键操作（如伤害计算、碰撞检测）必须由服务器执行，客户端仅作为“预测显示层”。
- 示例：玩家声称击中敌人，但服务器会根据武器弹道、位置等数据重新验证，防止“穿墙狙杀”。
四、技术演进对比
| 模型 | 适用场景 | 延迟体验 | 带宽需求 | 防作弊能力 | 实现复杂度 |
|---|---|---|---|---|---|
| P2P锁步 | RTS游戏 | 高 | 低 | 弱 | 中（需严格确定性） |
| 纯客户端/服务器 | 早期FPS（如Quake） | 中 | 高 | 强 | 低 |
| 客户端预测+服务器权威 | 现代FPS（如COD） | 低 | 中 | 强 | 高 |
五、现代技术扩展
插值与外推（Interpolation & Extrapolation）
- 插值：平滑过渡服务器状态（如角色移动时的渐变动画）。
- 外推：预测未来状态（如根据速度估算角色位置，用于快速响应）。
延迟补偿技术（Lag Compensation）
- 回滚射击（Rewind & Replay）：服务器根据客户端延迟时间回溯状态，验证射击有效性（如《CS:GO》的命中判定）。
混合架构
- 区域服务器+边缘计算：为降低延迟，将服务器部署在靠近玩家的地理位置（如AWS的全球加速服务）。
六、现实案例分析
- 《星际争霸》：坚持P2P锁步模型，因单位数量庞大且状态同步成本过高，但需严格限制非确定性因素（如禁用浮点运算）。
- 《守望先锋》：采用客户端预测+服务器校正，结合角色动画的“动画延迟补偿”（如提前播放受击动画，实际伤害稍后生效）。
- 《WebRTC》：现代浏览器实时通信技术，内置网络抖动缓冲和丢包重传机制，适用于低延迟多人游戏（如网页端小游戏）。
七、总结与启示
- 架构选择取决于游戏类型：
- RTS → P2P锁步（低成本同步）
- FPS/MMO → 客户端预测+服务器权威（平衡延迟与安全）
- 延迟优化永无止境：从锁步到预测，再到边缘计算，技术演进始终围绕“更流畅的体验”。
- 安全与性能的权衡：更高的客户端自主权（如预测）需搭配更严格的服务器校验，防止作弊。
💡 关键点：游戏网络编程的本质是在实时性、带宽效率和安全性之间寻找平衡，而技术方案的选择深刻影响游戏设计和玩家体验。
参考资料：