Q64: 如何优化网络带宽？

核心结论

带宽优化最有效的手段，通常不是“把包压得更小”，而是先减少根本不该发的内容。

真正的优化顺序往往应该是：

• 少发
• 晚发
• 合并发
• 最后再压缩

如果广播范围、同步频率和消息语义都没控制好，单纯上压缩收益会很有限。

一、先看带宽都花在哪

在线游戏里，大头通常不是低频系统消息，而是：

• 位置同步
• 动画和状态更新
• 战斗广播
• AOI 内实体创建与销毁

所以带宽优化应优先盯高频状态流，而不是先从冷门消息开始抠。

二、最有效的第一步是减少消息数量

常见做法包括：

• AOI 裁剪
• 降低低价值消息频率
• 状态覆盖旧值
• 去掉无意义字段

这些往往比压缩算法本身带来的收益更大。

三、要先区分事件和状态

1. 状态消息

例如：

• 位置
• 朝向
• 当前动作

这类消息更关注“最新值”，很适合：

• 增量同步
• 覆盖旧消息
• 客户端插值

2. 事件消息

例如：

• 技能释放
• 死亡
• 掉落生成

这类消息更关注语义完整性，不能简单只保留最新。

如果两者混用同一种发送策略，带宽和体验通常都会出问题。

四、批量和合并常常很有价值

很多高频小消息单条不大，但包头、系统调用和协议开销累计起来很可观。

所以常见做法是：

• 一个 tick 内批量发送
• 同类型更新合并打包
• 多实体状态做批量快照

但批量窗口不能过大，否则会增加感知延迟。

五、压缩要按消息类型选择

压缩不是越多越好。

要考虑：

• 小包压缩收益可能很低
• 压缩和解压也消耗 CPU
• 高频实时消息不一定适合重压缩

所以更常见的是：

• 大包、低频包适合压缩
• 高频小包优先靠结构优化和批量发送

六、字段设计会直接影响带宽

常见优化点包括：

• 用枚举和整数代替字符串
• 用定点或量化代替高精度浮点
• 只同步脏字段
• 去掉客户端可本地推导的字段

这些都比“上 gzip”更基础。

七、工程上更稳妥的带宽优化顺序

常见做法是：

1. 先统计消息类型占比
2. 优先优化高频状态消息
3. 用 AOI 和优先级减少无效发送
4. 再做批量、增量和结构压缩

这样通常最符合收益顺序。

八、常见误区

1. 带宽优化就是消息压缩

压缩只是最后一层，前面还有更大的收益空间。

2. 所有消息都应该高频实时同步

很多低价值状态完全不值得。

3. 包越小越好

也不一定。过度切碎会增加包头和系统调用成本。

参考资料

• 实时状态同步、快照压缩与 AOI 裁剪实践资料