Netty 报文解析长度加密

[lslvxy]

用 netty 解析 tcp 报文 格式是 固定 4 字节长度+消息体, 准备用 LengthFieldBasedFrameDecoder 解析的 但是这个消息头的 4 个字节也是加密的,要先解密一下才能获取到消息体的正确长度 这个要怎么搞呢

[AlexRoot]

固定长度的解析应该是提前在协议里确定好的吧。

[lslvxy]

@AlexRoot 不是固定长度,是消息头前 4 个字节表示消息长度,但是这 4 个字节也是加密过了的

[90xchun]

把长度这个字段也加下密就可以了吧，有啥问题呢？

[pmsg863]

加密后消息长度不会变吧？如果加密和解析后的 byte[]长度一致就比较简单，修改下 LengthFieldBasedFrameDecoder 源码，做个解密即可，对消息长度做个校验，超范围或解密失败跳过相关流数据或链路重置。

[darkengine]

这个协议定的有问题吧。完整消息包的长度是加密的，那么就无法知道应该取多长的 byte[]下来进行解密，然后不解密又不知道前 4 个字节的里保存的消息体长度是多少。。。这个项目已经跑起来了吗？好奇插个眼。

[lei2j]

长度也加密，那我挺好奇加密后的长度是多少呢？如果不是固定的，那怎么读取呢

[lslvxy]

@darkengine
@lei2j
我也觉得这个协议定的有问题
解析的时候就出现很多对不上的数据
还要自己拆包分包
先取前 4 个字节 解密得到 body 的长度
再根据长度获取消息体数据
再解析 body 到实体类上

[orionleo]

你可以试一下能不能在 LengthFieldBasedFrameDecoder 之前调用自定义的 handler 把消息头中的长度解密出来后重新封装成 [真实的消息长度] + [消息体]，传递给 LengthFieldBasedFrameDecoder(Integer.MAX_VALUE, 0, 4, 0, 4)。

[cubecube]

client server 都是你的话，那么你可以再加一层 length 包一下
如果只是 client，那么他们 server 怎么 encode 的，你去 decode 对应一下就行。总得有 demo 吧