游戏服务器开发指南（二）：优化包体传输

大家好！我是长三月，一位在游戏行业工作多年的老程序员，专注于分享服务器开发相关的文章。

这个系列本来计划每周更新一篇。本周因工作事情比较多，拖到周日才更新，让大家久等了。这次的主题是优化包体传输，是网络通信类别下的第二篇。

在游戏服务器的部署环境中，机房的网络带宽都是有限制的。如果通信传输的数据总量太大，会挤占带宽甚至达到带宽上限，影响正常消息发送。另外，如果包体太大，在弱网环境下的通信质量会变差，更容易发生丢包重传和延迟，而且大包对于截包和查找问题也不方便。因此我们需要对消息通信做优化，减少包体的大小和数量，进而减小传输的数据总量。

缩减包体大小

我们很容易理解包体太大对网络通信造成的负面影响。因为一个完整的数据包在通信协议底层也是拆成多个小包发送，在弱网环境下，每个小包都有可能发生丢包重传和延迟，叠加起来会让整个完整数据包也更容易出现问题。另外有实际经历的人会很理解从一大堆冗余数据里查找目标字段时的痛苦。

缩减包体大小的第一个方法是只传必要字段。

首先是使用前端静态表。策划配置的数据一般称为静态表，与存储玩家数据的动态表不同，静态表是只读不可修改的。建议对静态表的数据归类，数值类的放在服务端，显示类的放在客户端，这样好处是很多数据前端可以直接从前端静态表读取，不再依赖后端传输，后端通常只需要传一个id作为索引。

对于前后端静态数据如何划分是一个值得权衡的问题。通常来说，衡量的标准有两个维度：与前后端业务的相关性，以及该数据占用空间的大小。例如，数值类的数据与服务端计算强相关，因此适合放在服务端；而描述性的文字占用字节多，不宜通过服务端传输，因此放在客户端；图片和动画资源路径类的数据与客户端业务强相关，也放在客户端。

不过有时候前后端静态数据的划分界限并不那么清晰，这时候还需要结合其他要素做判断。例如，一个数值类的数据前后端都用到了，那么是否还需要放在回包消息中由后端传输呢？我们可以提前预判这个数据在将来变化的可能性大小，如果不太可能变化，那么就让前端直接从前端静态