（对于新项目，应使用 5.1 版中引入的新网络系统。此信息适用于使用旧网络系统的旧版项目。）
由于与游戏的其他方面相比，网络通信可能很慢，因此将通信量降低到最低限度是非常重要的。所以，考虑交换的数据量和交换的频率还是非常重要的。
使用的网络带宽量在很大程度上取决于使用__不可靠 (Unreliable)__ 还是__可靠增量压缩 (Reliable Delta Compression)__ 模式来同步数据（该模式是从网络视图 (Network View) 组件中设置的）。
在__不可靠__模式下，所同步的整个对象将在网络更新循环的每次迭代中传输。此更新的频率由 Network.sendRate 的值来决定，该值在默认情况下设置为每秒 15 次更新。__不可靠__模式确保了频繁更新，但任何丢弃或延迟的数据包都将被忽略。当对象非常频繁地改变状态并且错过更新带来的影响非常短暂时，此模式通常是可供使用的最佳同步模式。但是，您应该注意每次更新期间可能发送的数据量。例如，同步变换组件的过程涉及传输九个浮点值（三个 Vector3 各有三个浮点数），相当于每次更新 36 个字节。如果服务器运行八个客户端并使用默认更新频率，则它将接收 4,320 KBytes/s (8*36*15) 或 34.6Kbits/s 并传输 30.2 KBytes/s (8*7*36*15) 或 242Kbits/s。您可以通过降低更新频率来显著降低带宽消耗，但默认值 15 基本适合快速移动的游戏。
在__可靠增量压缩__模式下，能够保证数据可靠发送并以正确顺序到达。如果数据包丢失，将重新传输，如果它们无序到达，将进入缓冲区，直到序列中的所有数据包都到达。虽然保证了正确接收传输的数据，但是等待和重传往往会增加带宽使用量。不过，数据也是增量压缩的，这意味着只传输最后状态和当前状态之间的差异。如果状态完全相同，则不发送任何内容。因此，增量压缩的好处取决于状态变化的程度和属性。
在设计游戏时有很多发挥创造性的机会，能够让所有客户端的状态_看起来_相同（即使可能并非严格相同）。这种情况的一个示例是动画同步。如果网络视图观察到动画组件，则该组件的属性将完全同步，因此动画帧将在所有客户端上以完全相同的方式显示。尽管在某些情况下这可能是合乎需要的，但通常只需将角色视为行走、奔跑、跳跃等。因此，可以简单地通过发送整数值来表示要播放哪个动画序列，从而粗略地同步动画。与同步整个动画组件相比，这将节省大量带宽。
通常不必在所有客户端上保持游戏完全同步，例如在有些情况下，玩家暂时位于游戏世界的不同区域，他们不会彼此相遇。这样可以减少带宽以及服务器上的负载，因为只有可交互的客户端才需要保持同步。此概念有时称为__相关集__（即总游戏的一个子集在任何特定时间与任何特定客户端相关）。通过使用 RPC 可根据客户端相关集实现客户端同步，因为 RPC 可以更好地控制状态更新的目标。
加载关卡时，极少需要担心使用的带宽，因为每个客户端只需等所有其他客户端加载完关卡后才能玩。关卡加载过程通常涉及传输相当大的数据项（例如图像或音频数据）。