优化IncNet——可变长packet size

最近的工作中用到了WebSocket协议,研究了下它的数据帧格式,发现其payload length的表示方式很适合用来优化以前用到的网络库。

简单来说就是把固定4字节表示包大小的方式,改为用可变字节数表示包大小,大部分包的大小可以用1个字节表示,可表示的大小范围为0 ~ 253字节,稍微大点的包用1+2字节表示,大小范围为0 ~ 64KB,再大的包才用1+3字节表示,大小范围为0 ~ 16MB。对于游戏来说,16MB的包大小足够用了。如果不够,也是有对策的。

先来看下WebSocket的数据帧格式。

WebSocket数据帧格式

RFC 6455 给出了 WebSocket 协议的详细规范,其中第5.1节说到,在WebSocket协议中,数据是使用一系列frame来传输的,随后5.2节详细介绍了frame的格式:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+

我们只关注payload部分,RFC中写的比较清楚了,这里再复述一遍:

WebSocket数据帧中所承载的上层数据(payload data)的长度由payload len表示,payload len是不定长的,可能是7bits,也可能扩展到7 + 16 bits,也可能扩展到7 + 64 bits。

如上图,7 bits的payload len部分,可取值范围为0 ~ 127,其中:

  • 0 ~ 125:表示payload len只占7 bits,此时其表示的数值就是payload data的长度。
  • 126:126不是payload data的长度,而表示payload len随后的2字节( 16 bits )所表示的无符号整数,才是payload data的长度,范围0 ~ 64KB。此时,整个payload len占用7 + 16 bits。
  • 127:同126,127也不是payload data的长度,而表示payload len随后的8字节(64 bits)表示的无符号整数,才是payload data的长度。但最高位必须是0(没有深究其原因),那么此时可表示的payload data的长度为0 ~ 2 ^ 63,基本可以认为是无限大了。整个payload len占用7 + 64 bits。

可以看到,当payload data比较小时(125字节以内),WebSocket只需要7个bit表示其长度。而7 + 64 bits可表示的数据长度就是天文数字了。

个人猜测是因为WebSocket是通用协议,所以尽可能不给单个数据帧能包含的数据长度设限。不过我们自己用的协议是私有协议,有明确的使用场景,可以根据自己的需求来修改具体的数值。

WebSocket和IncNet都是构建于TCP之上,都属于OSI模型的第七层(应用层)协议,两者是对等的,因此我们可以粗略地将WebSocket的frame和IncNet的packet划等号,只是叫法不一样而已。

现在再来看看IncNet中packet的格式:

IncNet的Packet格式

在《 拆解IncServer网络库 》一文中已经详细介绍过IncNet中packet的格式了,为了文章完整性,搬运过来:

Packet格式

IncNet的server模块和client模块之间的通信协议是以packet为单位的,上层逻辑可以定义不同种类的packet,每种packet的内容格式各不相同,收发packet的两端都按照定好的协议格式读写数据。

上图为一个packet的格式,先是4字节的packet大小,即整个packet(包括packet_size自身)的字节数,之后是两字节的packet_type(包类型),最后是packet的实际内容,其长度和格式因packet_type而异,由上层逻辑自行定义。

高频包优化

从packet的格式可以看出,每个packet的头部实际占用了6个字节之多。为了优化类似于位置同步、战斗相关逻辑收发的高频包,IncServer采取了一种连包优化策略,以减少packet的头部所浪费的空间。

准确的说这属于上层逻辑的优化,并不属于IncNet的底层机制。

IncServer定义了一种特殊的packet_type(ST_SNAPSHOT),其内容又是n个packet,只不过这些packet的packet_type只占用一个字节,而且不再有packet_size部分,从而减少了包头所占用的空间,如下图:

不过这种做法有一定的限制:

  • packet_type只有1字节,因此最多支持256个高频包。
  • 打乱了跟其他正常packet之间的顺序。因此时序相关的逻辑要么都用单字节包,要么都用双字节包。
  • 因为不再有packet_size,所以前序packet的格式错误会导致后续所有packet的错误。

改进IncNet

可以看到,IncNet使用固定的4字节来表示每个packet的长度,4字节可表示的长度范围为0 ~ 4GB,而大部分游戏协议的数据量也就几十个字节而已,有点浪费。

而为了优化高频包,IncServer中采取的方式虽然消除了packet size所占的4字节,并且将2字节的packet type降低到1字节,但为此付出的代价也是不容忽视的:1. 打乱了与正常packet之间的顺序,2. 单个普通包内的高频包一错皆错。在实际开发过程中,这也确实带来了不便。

还有一点,这是上层逻辑的优化,已经不属于网络库本身了。

所谓的高频包,一般的大小有多少个字节呢?来看下技能协议ST_STATE_SKILL

function broadcast_skill( _obj, _skill_id, _x, _y, _z, _degree, _tx, _ty, _tz, _is_request, _target_id)
    local ar = g_ar
    ar:flush_before_send_one_byte( msg.ST_STATE_SKILL )
    ar:write_ulong( _obj.ctrl_id_ )
    ar:write_uint( _skill_id )
    ar:write_pos_angle( _x, _y, _z, _degree )
    ar:write_float( _tx )
    ar:write_float( _ty )
    ar:write_float( _tz ) 
    ar:write_byte( _is_request )
    ar:write_ulong( _target_id )

    local invalid_ctrl
    if _is_request == 1 then
        invalid_ctrl = 0
    else
        invalid_ctrl = _obj.core_
    end
    g_playermng:c_broadcast_one_ar( ar, _obj.core_, invalid_ctrl )
end

数一数write的次数就知道,一共也才41个字节(假设long是4字节,且不考虑写write_pos_angle的内置优化)。

其实packet的大小跟高频不高频没啥必然联系,除了玩家序列化的packet比较大以外,大部分packet的大小其实也就几十最多上百字节。

想想WebSocket的7 bits可以表示多大来着?125字节,这完全足够覆盖绝大部分packet的大小了。因此,完全可以将WebSocket表示payload data大小的思路引入IncNet中。

仿照WebSocket,我们用8 bits即1 byte来表示packet size,不同的取值有不同的含义:

  • 0 ~ 253:表示packet size,此时只有1个字节用来表示包大小,可表示范围为0 ~ 253字节。
  • 254:表示随后的2个字节用来表示packet size,此时一共有3个字节用来表示包大小,可表示范围为0 ~ 2 ^ 16 = 64KB。
  • 255:表示随后的3个字节用来表示packet size,此时一共有4个字节用来表示包大小,可表示范围为0 ~ 2 ^ 24 = 16MB。

然后情况会变成绝大部分packet中,只有1字节用来表示packet size,偶尔大点的包可能用到3字节,能用到4字节的可以说是几乎没有了。

什么?16MB还不够用,那就把253也当成一个特殊值,表示用随后的4个字节来表示packet size,范围0 ~ 4GB。你的数据都超过16MB了,多一个字节表示packet size也无所谓了吧。

那还要不要区分普通包和高频包呢?

我觉得区别可能不是很大。如果还是觉得用两字节表示高频包的packet类型太浪费了,想用一个字节,也有办法:

从表示packet size的第一个字节里拿出一个bit,为0表示这个包不是高频包,说明后续用了一个字节表示packet type,为1则表示这个包是高频包,后续用了两个字节表示packet type。

这样做的代价就是,单字节可表示的packet size范围少了一半,变成0 ~ 125了。如果不想这样,那就用一个新增的bit表示是否高频包。

这样做的优缺点

优点:

  • 属于底层优化,业务层只管用即可,所有packet都受益。
  • 普通包和高频包一视同仁,不再有时序上的问题。
  • 某一个高频包出错,不会再导致后面的包也出错。

缺点:

  • 对于高频包的优化力度没有之前的方式大。之前每个高频包只有额外的1字节表示packet type,改进之后还需要有至少一个字节表示packet大小。

如果说,缺点无法接受,那么只用WebSocket的思路来优化普通包也是可以的。

说点什么

avatar
  订阅  
提醒