一聚教程网:一个值得你收藏的教程网站

热门教程

skynet框架去掉 cluster rpc 的消息长度限制方法

时间:2022-06-25 04:46:24 编辑:袖梨 来源:一聚教程网

为什么 skynet 提供的包协议只用 2 个字节表示包长度

skynet 提供了一个 lua 库 netpack ,用来把 tcp 流中的数据解析成 长度 + 内容的包。虽然使用 skynet 的同学可以不使用它,而自己另外实现一套解析协议来解析外部 TCP 数据流(比如 skynet 中的 redis driver 解析 redis server 的数据流就是用的换行符分割包),但依然有很多同学询问,能不能自定义包头长度。

这里的这个库定义的协议中,包长度是用 big-endian 的 2 个字节表示的,也就是说一个包的长度不得超过 64K 。这让很多人很为难。已经几次有同学建议,把长度放宽成 4 个字节,因为他们的应用环境中大部分包不会超过 64K ,但总有少量超过这个限制的。

历史上,skynet 的 gate 还是用 C 实现的时候(那个版本依然可以使用)的确可以自定义是使用 2 个字节还是 4 个字节表示包长。但经过一番考虑,我还是去掉了这个选择。

一个好的库,应该简洁,且引导使用者用正确的方法做正确的事情;而不应该提供让用户犯错的机会。在和游戏客户端通讯的时候,如果你只采用一个 TCP 连接,那么允许很长的数据包本身就是错误的。甚至 64K 都太大。

游戏通常需要比较快的响应速度,如果你允许在单个 TCP 连接中插入一个太大的数据块,比如 100K ,那么在比较弱的网络条件下(例如手机网络),处理这个包可能就需要超过 1 分钟的时间。而这么大的数据块,在业务逻辑上大多不期待立刻能发出或收到的。一个典型的应用场景就是用户在拍卖行中查询所有的上架物品,如果把所有返回数据都放在一个数据包中,很容易就变得很大。而查询大量这个操作,用户本身就对立刻回应没有期待。

而在单个 TCP 连接上,这样一个大数据块会阻塞住整个信道,后面本来需要快速送到的数据全部被延迟了。

如果你想在业务层做一个心跳包检测网络是否超时,很容易就把心跳包拦在后面。而通常网络处理层不会提供接口让业务层探知是否正在接受数据(skynet 的 gateserver 就没有提供这样的接口,虽然它很容易提供,只需要修改几行 lua 代码),只能在一个完整的数据包收到后才会交给业务层处理。

正确的做法是,在长度+内容这个协议上再加一个层次。加一条协议叫大数据块,允许把一个大数据块分几段发送。可以在这条协议中加上数据块 id ,在后面引用这个数据块的包中附上数据块 id 即可。

为什么要用这种比较绕的方式,而不直接把包头从 2 字节改成 4 字节?当你做这个设计时,就已经表明你重视了上面提到的问题。

当你把数据包都分割的比较小时,才能实现单个 TCP 连接上承载多个信道的能力。对于网络游戏,并不是所有的数据包都是上下文相关的,你可以看成隐含着有多条线索。比如聊天频道的信息和场景同步的信息就是相互独立的。skynet 为这种场景还提供了额外的 socket api 支持。socket.lwrite 可以把一个字符串(一个数据包)写到低优先级通道。只有等默认通道(高优先级)的包全部发送完后,低优先级通道上的包才至少被发送一个(单个包可以保证原子性)。

比如,你可以用它来发送聊天信息,就不会因为聊天信息泛滥把其它重要数据包都塞住。同样,你可以用来发送被分割后的大数据块。如果同时你还有很多其它重要的数据需要传输给客户端,那么这些数据块就会被打散穿插在其间。

当然,你也可以把所有给客户端的数据全部用 lwrite 发送,而仅仅把心跳包放在常规高优先级通道,可以保证心跳频率更稳定。

另外,采用 4 字节的包长度还有一个安全漏洞,可能被攻击利用。

一般的分割包的代码,在收到包头时,都会根据长度信息预先分配出相当长的空间,等着后面的数据达到后填入。如果攻击者不断在新建立的连接上发送一个恶意的长度信息,比如 2G ,服务器内存很容易被快速消耗光。

早期 skynet 的 gate 实现时,采用的是共享一个固定长度的 ringbuffer 的实现,可以避免这种攻击。但新的版本由于不再允许 4 字节长度,就没有做特别处理了。

如果你的应用环境非常特殊,坚持一个允许更大长度的数据包协议。那么我建议你慎重的实现一个分包模块,而不是简单的把 netpack 库中的 2 改成 4 。



去掉 skynet 中 cluster rpc 的消息长度限制

上面我们讲了 为什么 skynet 提供的包协议只用2个字节表示包长度 里面提到, 如果有体积很大的消息传递需求,那么应该在上一层去处理。

从另一方面来说,我们应该正视长消息的处理,而不应该将其和普通(较短)消息的处理混为一谈,在底层抹平之间的区别。

最近,需求就来了。

我们的一个新项目希望在 cluster 间通讯的时候,可以支持较大的消息。原本提出需求的同学想自己修改 skynet 的 cluster 模块,修改底层协议的包头长度的。我即使阻止了他,并自己动手做了修改。

简单说,就是在上一层的 cluster 协议上,增加了长消息的标识。由于之前就有一个字节做标识,其实并没有对协议做太大的修改。

当消息(无论是请求还是回应)太长时,就分开打包,并在标识字节上表明这只是一个完整消息的一部分。然后在接收方合并即可。

一开始我并不打算修改 cluster 依赖的 socket channel 模块 ,让分开的每个小包都有一个独立的 session 。做了一半以后,发现对 socket channel 做一些增强(不应该之前的接口)会更好一些。而且可以很容易利用上之前做的 socket 低优先级队列这个特性。

新的修改我暂时提交到一个叫 multipart 的 skynet 独立分支上,欢迎感兴趣的同学 review 。

同时,我把 skynet 之前的两个含义不明确的内部宏重新定义了,去掉了之前对内部消息长度的 16M 限制。

经过一些简单测试,目前可以达到设计目标:在 cluster 内部,rpc 的请求和回应消息都不再受之前的 64K 限制。而且,一旦消息过长(目前是以 32k 为界),长消息的传输会被分成多个小于 32K 的消息投递,并且其它短消息允许穿插在其间。也就是说,如果你用 cluster 向外投递一个几十 M 的巨大消息的话,不会因为消息过大而阻塞了通讯通道。


一个内存泄露 bug

起因是 skynet 的一个 Issue ,同时,这两天我们正在开发的一个项目也反应貌似有内存泄露。

我觉得两件事同时发生不太正常,就决定好好查一下。

其实在 skynet 里查内存泄露要比一般的项目容易的多。因为 skynet 天生就分成了很多小模块,叫作服务。模块申请的内存是独立的,内聚性很高。模块的生命期比整个进程短的多,模块的规模也不会太大,可以独立分析。一般说来,如果有内存申请没有归还,应该是 C 模块里的 bug 。而 skynet 会用到的 C 模块也很少,一旦有这样的问题,很快就能定位。

skynet 实现了一个内存管理的钩子,用于按服务分开统计内存的开销。代码在 skynetsrc 目录下的 mallochook.c 文件里。

我建议同事做这样的修改:

在每次内存分配释放时,按当前服务的 handle 做文件名记录 log 。这里有考虑一点点多线程并发的问题,但发生的概率很少,如果只是做临时的调试,可以暂时不理。因为同一个服务的分配行为不会并发,只有很少的情况释放在另一个线程中。如果发生了,会导致写 log 遇到一点错乱。

比较麻烦的是,在 hook 里第一次写 log 打开 log 文件有可能由 crt 触发 malloc 导致死循环。如果要避免这种情况,需要加一个 tls 标记,在进入 hook 后就设置上标记,避免被重入。

加上十多行代码后,内存管理的 log 就可以正常工作了。

一开始我认为 lua 本身的内存管理是没有问题的,所以可以将 malloc hook 里为 lua 定制的 skynet_lalloc 绕过 log (直接调用 je_malloc 即可)。这样就可以只记录 C 模块中的内存管理调用,数据量要少的多,比较容易排除问题。

但是加上 log 后,分析 log 似乎找不到泄露。我只好转而怀疑通过 lua 的分配器分配的内存有没有释放的。

怀疑点有两个,一是通过 lua_getallocf 取到分配器调用的。这个只在 lpeg 里发现过,应该没有问题;另外就是我自己对 lua 的修改了。

为了提高 skynet 下多 lua vm 的内存利用率,我曾经给 lua 打过一个 patch ,可以让不同 lua vm 共享相同的函数原型 。第一次加载的 lua 字节码是不会释放的,但第 2 次加载相同的代码,会复用之前的拷贝。

我仔细把 patch review 了一遍,没有发现问题。所以还是得靠新的 log 分析。

接下来把 log 重新写了一下,改成在 lua 定制分配器里记录。这个要容易的多,正好前几天刚做过 。还真发现了有一些长度为 88 字节的内存块没有释放。

lua 分配器在分配新内存时,会传入内存的用途(供什么类型的数据使用),这是一个重要的线索。这个泄露的 88 字节的类型为 0 (无记录),但它的上一条分配记录的类型是 9 也就是 LUA_TPROTO 。这说明很可能真的是函数原型中有数据没有释放。

而 88 字节恰好是我的 patch 中增加的 ShareProto 这个结构的长度。

最终 bug 的修复很简单:见这个 commit 。就是漏了一行 free 。

真是撞了鬼了。

因为我自己的硬盘上的本地代码明明一直是有这行的 :( 甚至我都不记得有过漏写这行代码。(这个 patch 是根据更早的 lua 5.2 版上的 patch 改过来升级到 lua 5.3 的。老版本是正确的。) git 的 diff 和 status 都没有察觉到我本地代码和仓库里有什么不同。这也是为什么这个内存泄露在我自己的机器上从来都没有发生过。

所以最后我重新 clone 了一份仓库,提交了这行遗漏的代码。但很难找到线索为何在操作 git 仓库的时候出现这个问题。或许是几个月前某次 push -f 强制推送导致的吧。

热门栏目