java - 二进制和文本结构（数据包）的高效解码

Question

背景

有一个著名的工具叫做Wireshark。我已经使用它很多年了。这很棒，但性能是问题。常见的使用场景包括几个数据准备步骤，以便提取数据子集以供稍后分析。如果没有这一步，过滤需要几分钟的时间（有很大的痕迹，Wireshark 几乎无法使用）。

实际的想法是创建一个更好的解决方案，快速、并行和高效，用作数据聚合器/存储。

要求

实际要求是使用现代硬件提供的所有电源。我应该说有不同类型的优化空间，我希望我在上层做得很好，但技术是现在的主要问题。根据当前的设计，有几种数据包解码器（解析器）：

• 交互式解码器：解码逻辑可以在运行时轻松更改。这种方法对协议开发人员非常有用——解码速度不是那么关键，但灵活性和快速结果更重要
• 嵌入式解码器：可以用作库。这种类型应该具有良好的性能并且足够灵活以使用所有可用的 CPU 和内核
• 解码器即服务：可以通过干净的 API 访问。这种类型应该提供最好的品种性能和效率

结果

我目前的解决方案是基于 JVM 的解码器。实际的想法是重用代码，消除移植等，但仍然有很好的效率。

• 交互式解码器：在 Groovy 上实现
• 可嵌入解码器：在 Java 上实现
• 解码器即服务：Tomcat + 优化 + 嵌入到 servlet 中的解码器（二进制输入，XML 输出）

需要解决的问题

• Groovy 提供了强大的功能和一切，但在这种特殊情况下很幸运
• 将协议解码为树形结构是一条死胡同——太多的资源被浪费了
• 内存消耗有点难以控制。我做了一些优化，但仍然对分析结果不满意
• 各种花里胡哨的 Tomcat 仍然会引入很多开销（主要是连接处理）

我在任何地方都使用 JVM 做得对吗？您是否看到任何其他好的和优雅的方式来实现最初的目标：获得易于编写、高度可扩展和高效的协议解码器？

结果的协议、格式等不固定。

Answer 1

我发现了几个可能的改进：

交互式解码器

通过使用AST Transformations扩展 Groovy 语法，可以极大地提高 Groovy 的表达能力 。因此，可以简化解码器创作，但仍能提供良好的性能。AST（代表抽象语法树）是一种编译时技术。

当 Groovy 编译器编译 Groovy 脚本和类时，在过程中的某个时刻，源代码最终会以具体语法树的形式在内存中表示，然后转换为抽象语法树。AST 转换的目的是让开发人员能够在编译过程中修改 AST，然后再将其转换为将由 JVM 运行的字节码。

我不想重新发明轮子，引入另一种语言来定义/描述协议结构（拥有ASN.1就足够了）。这个想法是为了简化解码器的开发，以提供一些快速的原型技术。基本上，要引入某种 DSL。

进一步阅读

嵌入式解码器

Java 会引入一些额外的开销。有几个库可以解决这个问题：

• 高压PC
• 特罗夫
• Javolution
• 公地原语

坦率地说，我没有看到除 Java 之外的任何其他选项。

解码器即服务

这一层不需要Java。最后我有一个不错的选择，但价格相当高。Gwan看起来真的很好。

将需要一些额外的移植，但这绝对是值得的。

Answer 2

这个问题似乎与许多高性能 I/O 实现问题有相同的特点，那就是内存副本的数量决定了性能。异步 I/O 的分散-聚集接口模式遵循这一原则。使用 scatter-gather，内存块就地操作。只要协议解码器将块流而不是字节流作为输入，您就可以消除大量移动内存以保留字节流抽象的性能开销。字节流对于节省工程时间来说是一个非常好的抽象，但对于高性能 I/O 来说不是那么好。

在一个相关的问题中，我会提防 JVM 只是因为 basic type String。我不能说我熟悉StringJVM 中的实现方式，但我确实认为没有办法在不进行内存复制的情况下从块列表中生成字符串。另一方面，一种可以与 JVMString兼容互操作的原生字符串可能是一种区分差异的方式。

---

这个问题的另一个似乎相关的方面是形式语言。本着不复制内存块的精神，您也不希望一遍又一遍地扫描同一块内存。由于您想要进行运行时更改，这意味着您可能不想使用预编译状态机，而是使用递归下降解析器，它可以在每个下降级别分派给适当的协议解释器。当外层没有指定内层的类型时，会涉及一些复杂性。当您甚至不知道内部内容的长度时，这些并发症会更糟，因为那时您依靠内部内容的良好格式来防止失控。然而，值得关注的是了解单个块将被扫描多少次。

Answer 3

网络流量正在增长（一些分析），因此需要每秒处理越来越多的数据。

实现这一点的唯一方法是使用更多的 CPU 功率，但 CPU 频率是稳定的。只有核心数量在增长。看起来唯一的方法是更有效地使用可用内核并更好地扩展。