网络同步在游戏历史中的发展变化（三）—— 状态同步的发展历程与基本原理（上）...

前言：

网络同步属于游戏开发中比较重要且复杂的一部分，但是由于网上的资料内容参差不齐，很多人直接拿别人的结论写文章，导致很多人对这一块的很多概念和理解都是错误的。本文参考了大量的相关论文和资料（花了半年的时间看了不下70篇论文、博客、视频），从网络同步的基本概念讲起，进一步深入到服务器架构与同步算法的实现细节，可以帮你系统的梳理网络同步技术的发展与应用。该系列估计有6篇，本篇核心内容为“状态同步的发展历程与基本原理”，首发在网易雷火官方的知乎账号上。

注：在公众号后台回复“网络同步论文”可获取文中所引用的论文

网络同步在游戏历史中的发展变化（一）—— 网络同步与网络架构

网络同步在游戏历史中的发展变化（二）—— Lockstep与帧同步

目录（第三篇）：

四.State Synchronization 状态同步

  1.雷神之锤与快照同步

 （Quake and Snapshot）

  2.星际围攻：部落中的网络架构 （The TRIBES Engine  Networking Model）

  3.客户端预测与回滚（Client-side prediction and Rollback）

  4.事件锁定与时钟同步 (Event Locking and Clock  Synchronization)

  5.插值技术（Interpolation and Extrapolation ）

四.状态同步State Synchronization 

上一篇我们曾提到，国内对“Lockstep”的翻译经常会引起一些初学者的误解。但好在网上的参考文献和资料比较丰富的，查证起来还比较容易。反倒是当我开始仔细研究大家都耳熟能详的“状态同步”时，我竟然一时半会难以追溯其发展来源。可能是因为早期的技术领域里面好像并没有这个概念，笔者能找到最早的关于状态同步的资料源于上世界90年代的防火墙产品——FireWalls-1[1][2][3]。这款产品出自公司Check Point，是第一个使用状态检测（stateful inspection）的商业防火墙软件。其中的stateful inspection表示让多个防火墙共享各自状态表中包含的信息，这种信息传递的方式与我们游戏中的状态同步非常相似。由此可见，状态同步与Lockstep一样，也是经历了一个相对漫长的时间才发展成如今我们熟知的模样。

在二十年前，相比于使用帧同步（为了方便描述，后续的文章中以帧同步代替Lockstep）还是状态同步，开发者们更关心的是网络架构的实现方式（P2P/CS)。换句话讲，在当时业内看来，P2P架构的同步模型虽然减少了延迟，但由于作弊、跨平台、难以维护大型网络游戏等问题，人们更希望用CS架构来取代P2P。同时，开发者们虽然可以继续在CS架构下使用逻辑比较简洁的帧同步，但有不少开发者都认为刚刚诞生的状态同步貌似更符合CS架构的同步理念。

需要强调的是，帧同步与状态同步并不是一个简单的对立概念，其中的差异包括“数据格式与内容”，“逻辑的计算位置”，“是否有权威服务器”等 。随着时间的推进，两种算法互相借鉴互相发展，早已不是当年的样子。网上存在很多概念模糊的文章，包括一些大佬对同步的概念理解也有偏差，这些都很容易对新手产生误导。所以笔者建议，如果你想真正的了解或者学习网络同步，不妨跟着这篇文章去了解二者的发展历史，相信看过后的你一定能更深刻的理解到帧同步与状态同步的异同。（文末同上篇一样贴出了大量的文献内容）

1.雷神之锤与快照同步（Snapshot）

快照是一个通用的行业术语，即在任何给定时刻记录设备的状态并在设备出现故障时进行还原。快照技术常用于计算机的各种存储系统，例如逻辑卷管理、数据库、文件系统等。在游戏领域中，快照的含义更像是照片一样，将当前场景所有的信息保存起来。严格来说，快照同步应该属于状态同步的前身，虽然思想相似但是具体实现却有不小的差异。

1996年，在doom发行不久后，Id software就公开了新作——雷神之锤（Quake）。在Quake里他们舍弃了之前的P2P而