有一个名为Wireshark的着名工具.我已经使用了很长时间.这很棒,但性能是问题所在.通用使用场景包括若干数据准备步骤,以便提取稍后要分析的数据子集.如果没有这一步,则需要几分钟才能进行过滤(Wireshark旁边的大痕迹无法使用).
实际的想法是创建一个更快,更平行,更高效的更好的解决方案,用作数据聚合器/存储.
要求
实际要求是使用现代硬件提供的所有电源.我应该说有一个不同类型的优化空间,我希望我在上层做得很好,但技术是现在的主要问题.根据目前的设计,有几种类型的包解码器(解剖器)：
>交互式解码器：解码逻辑可以在运行时轻松更改.这种方法对协议开发人员非常有用 – 解码速度并不重要,但灵活性和快速结果更为重要
>可嵌入解码器：可以用作库.这种类型应该具有良好的性能,并且足够灵活,可以使用所有可用的cpu和内核
>解码器即服务：可以通过干净的API访问.这种类型应提供最佳的品种性能和效率
结果
我目前的解决方案是基于JVM的解码器.实际的想法是重用代码,消除移植等,但仍然具有良好的效率.
>交互式解码器：在Groovy上实现
>可嵌入解码器：在Java上实现
>解码器即服务：Tomcat优化嵌入到servlet中的嵌入式解码器(二进制输入,XML输出)
需要解决的问题
> Groovy提供了更多权力和一切的方法,但在这种特殊情况下运气表现力
>将协议解码为树结构是一个死胡同 – 太多资源被浪费掉了
>内存消耗有点难以控制.我做了几次优化但仍不满意分析结果
> Tomcat与各种铃声和口哨仍然引入了很多开销(主要是连接处理)
我在各地使用JVM做得对吗？您是否看到了实现最初目标的任何其他优秀和优雅的方法：获得易于编写的高度可扩展且高效的协议解码器？
协议,结果格式等不固定.
解决方法
交互式解码器
通过使用Groovy语法扩展,可以大大提高Groovy表达能力
AST Transformations.因此,有可能简化解码器创作仍然提供良好的性能. AST(代表抽象语法树)是一种编译时技术.
When the Groovy compiler compiles Groovy scripts and classes,at some
point in the process,the source code will end up being represented in
memory in the form of a Concrete Syntax Tree,then transformed into an
Abstract Syntax Tree. The purpose of AST Transformations is to let
developers hook into the compilation process to be able to modify the
AST before it is turned into bytecode that will be run by the JVM.
我不想重新发明轮子引入另一种语言来定义/描述协议结构(它足以拥有ASN.1).这个想法是简化解码器开发,以提供一些快速原型技术.基本上,将引入某种DSL.
嵌入式解码器
Java可能会引入一些额外的开销.有几个库可以解决这个问题：
> HPPC
> Trove
> Javolution
> Commons-primitives
坦率地说,除了Java之外,我没有看到任何其他选项.
解码器即服务
此层不需要Java.最后我有一个很好的选择,但价格相当高. GWan看起来真的很棒.
需要一些额外的移植,但绝对值得.