（对于新项目，应使用 5.1 版中引入的新网络系统。此信息适用于使用旧网络系统的旧版项目。）
通过从 State Synchronization 下拉选单中选择 Reliable Delta Compressed 或 _Unreliable__，可启用给定网络视图 (Network View) 的状态同步 (State Synchronization)。随后必须使用 Observed_ 属性选择要同步的数据类型。
Unity 可以同步变换 (Transform)、动画 (Animation)、刚体 (Rigidbody) 和 MonoBehaviour 组件。
变换是通过存储位置、旋转和比例来实现序列化的。不会通过网络传输父子化 (Parenting) 信息。
动画可序列化每个正在运行的动画状态，即时间 (time)、权重 (weight)、速度 (speed) 和启用 (enabled) 属性。
刚体可序列化位置、旋转、速度和角速度。
脚本 (MonoBehaviour) 将调用函数 OnSerializeNetworkView()。
网络视图目前支持两个可靠性级别：可靠增量压缩 (Reliable Delta Compressed) 和不可靠 (Unreliable)。
两者都有其优缺点，游戏的具体细节将决定最适合使用哪种级别。
有关最小化带宽的其他信息，请阅读最小化带宽页面。
__可靠增量压缩__模式会自动将客户端上次接收的数据与当前状态进行比较。如果自上次更新后没有数据发生更改，则不会发送任何数据。但是，数据将按每个属性进行比较。例如，如果变换组件的位置已更改但其旋转尚未更改，则只有位置才会通过网络发送。通过仅传输更改的数据可以节省带宽。
Unity 还将确保每个 UDP 数据包均可靠到达，其做法是重新发送数据包，直至确定收到。这意味着，如果发生丢包，则在重新发送并收到丢弃的数据包之前，不会应用稍后发送的任何数据包。在此之前，所有后续数据包都将在缓冲区中等待。
在 Unreliable 模式下，Unity 将发送数据包，但不检查是否收到数据包。这意味着它不知道已接收哪些信息，因此仅发送已更改的数据是不安全的 - 每次更新都要发送完整状态。
网络层使用 UDP，这是一种不可靠的无序协议，但使用这种协议可以可靠发送有序数据包，就像 TCP 一样。为此，Unity 在内部使用 ACK 和 NACK 来控制数据包传输，确保不丢包。使用可靠的有序数据包的缺点是，如果某个数据包被丢弃或延迟，一切都会停止，直到该数据包安全到达为止。在存在显著网络延迟的情况下，这可能导致传输延迟。
当您知道无论如何每一帧数据都会改变时，不可靠的传输非常有用。例如，在赛车游戏中，您几乎可以确定玩家的汽车始终在移动，因此错过的数据包的影响将很快被下一个数据包修复。
一般而言，如果快速频繁的更新比丢失数据包更重要，应使用不可靠发送。相反，当数据不经常变化时，可使用可靠增量压缩来节省带宽。
当服务器对世界状态具有完全权限时，客户端仅根据从服务器接收的更新来更改游戏状态。这种机制的一个问题是因等待服务器响应而引起的延迟会影响游戏运行。例如，当玩家按下按键以向前移动时，从服务器接收到更新状态之前，玩家实际上不会移动。这种延迟取决于连接的延迟，因此连接质量越差，控制系统变得越不灵活。
一种可能的解决方案是__客户端预测__，即客户端通过使用大致相同的内部模型来预测来自服务器的预期动作更新。因此，玩家可立即响应以输入信息，但服务器将从上次更新中看到玩家位置。当状态更新最终从服务器到达时，客户端将比较预测的情况与实际发生的情况。二者可能会有所不同，因为服务器可能更了解玩家周围的环境，而客户端只知道所需知道的信息。预测错误将在发生时得到纠正，如果这些错误持续得到纠正，那么结果将更加平滑，也不容易注意到。
可以将客户端预测的基本原理应用于玩家的对手。__外推__是存储对手最后几个已知位置、速度和方向值的过程，使用这些值可以预测对手在不久的将来应该会在什么位置。当下一个状态更新最终以正确的位置到达时，将使用确切的信息更新客户端状态，如果预测错误，可能会使角色突然跳跃。在 FPS 游戏中，玩家的行为可能非常不稳定，因此这种预测的成功几率有限。随着预测错误逐渐累积，如果滞后变得足够严重，对手将剧烈跳跃。
如果数据包在前往客户端的途中丢失，可使用__插值__。这种情况下通常会导致 NPC 的移动暂停，然后在新数据包最终到达时跳到最新位置。通过将世界状态延迟一定的时间量（例如 100 毫秒），然后在最后的已知位置和新位置之间进行插值，这两个位点之间的移动（二者间发生了丢包）将是平滑的。