XML硬件加速技术研究

阎玮，施亮

0 引言

在网络传输世界中，XML[1]（Extensible Markup Language 可扩展标记语言）正逐渐成为Web服务的通用语言。但是，XML的灵活性对网络基础设施提出了很高的要求。实际上，执行转换、压缩和Web服务安全等CPU密集型任务可消耗多达80%的服务器处理能力。据结构化信息标准促进组织（Organization for the Advancement of Structured Information Standards）统计，由于XML的自我描述复杂性，计算机处理描述相同信息量的XML文档要比相应二进制文档多消耗 25倍的计算资源[2]。于是，以网络硬件或通信加速设备面目出现的 XML加速器应运而生。XML 加速器(XML Accelerator)可以降低应用服务器的处理负荷，除了处理XML数据外，还有助于执行安全数据交换，并支持服务质量（QoS）[3]。

本文介绍了XML加速器的基本原理，着重对硬件加速的关键环节---XML解析过程进行了探讨，较为详细地阐述了一种新的解析技术VTD-XML，分析它的性能优势和硬件实现前景，并给出了系统结构图。

1 XML加速器的工作原理

XML加速设备通常部署在数据中心的3层架构中，置于防火墙之后，负载均衡器和应用服务器（或兼具应用服务器和Web 服务器功能的设备）之间。负载均衡器负责将负载平均分布于XML加速器；应用服务器是XML 数据的主要制造者，同时也是最大的消费者。XML加速器在执行诸如解析、确认、转换和压缩等操作时，其速度要比应用服务器快得多，因为它是专为特定任务度身定制的。

XML流量可分为输入和输出数据流。对于输入流量，XML加速器负责解压、解密、确认和路由等工作，并处理HTTP 或SOAP（简单对象访问协议）报头和XML内容。它根据配置信息决定如何进行转换、验证或还原内容等工作。相应地，负载均衡器被配置为将经过选择的正确数据传送给XML加速器。例如，根据某个正从负载均衡器流向应用服务器的HTTP报头，XML加速器便可获知该数据是否已被压缩。

对于输出流量，XML加速器对从应用服务器流向负载均衡器的流量进行内容转换。当XML内容流经时，文件或配置中的参考样式表即被应用到文件中，并将其转换为HTML、无线标记语言（Wireless Markup Language）或其他形式的XML。此外，通过配置负载均衡器和Web服务器，XML加速器还可加快XML数据的加密和压缩。通常，XML加速器可以以线速运行，而这是应用服务器望尘莫及的。

在安全管理方面，XML加速器承担着网关的角色，负责对输入输出流量进行加解密、验证和授权操作。虽然在这种情况下，性能未必得到提高，但却可以对 Web业务数据进行有效控制。

图1 XML加速器工作原理

下面对XML加速器的工作模式进行简要的说明：

①负载均衡器接收来自Internet的输入流量。

②负载均衡器将XML流量引向XML加速器。

③XML加速器对 XML流量进行解压、解析、解密和确认后，把它们路由给适当的应用服务器。

④XML加速器接收来自应用服务器的流量，并对它们进行转换、确认、加密和压缩。

⑤XML加速器向负载均衡器发送XML数据，并将其传向Internet。

如图1所示，XML加速器把原来由应用服务器承担的许多大量耗费CPU时间的任务卸载到网络上，从而提高系统性能，并有助于实施安全数据交换和服务质量。

2 XML解析模型的选择

影响XML处理速度的因素主要包括3个：网络传输时间、消息处理时间和服务执行时间。在消息处理阶段中，XML解析是最消耗时间的一个环节。所谓解析就是用某种方法来提取其中的元素、属性和数据，以便用这些信息进行进一步的操作，例如用提取出的某些符合条件的信息与客户端交互。对于那些需要处理大量数据的应用程序，这种技术尤为重要。选择合适的解析技术对应用系统的性能有着较大的影响，不正确的解析会导致过度的内存消耗和过长的处理时间，从而大大降低系统的整体性能。

2.1 DOM和SAX解析技术

通常，根据解析方式的不同，我们大致有两种选择：基于树的DOM（Document Object Model文档对象模型）和基于事件的SAX（Simple API for XML 简单应用编程接口）。前者是W3C推荐的标准模型，它将XML的结构信息以树形的方式构建，提供了遍历这颗树的接口与方法。基于DOM的解析必须将XML文档整个读入内存中，所以当遇到较大的XML文档时，解析过程会变得较慢而且非常消耗内存。而SAX模型是串行操作的，逐个元素的向前只读处理，整个文档并不一次性地读入内存，这样就避免了处理大型文档时的速度问题，但是由于没有结构信息，无法遍历操作，可维护性比较差。两种方式各有利弊，都不是特别理想的解决方案，表1对他们的优缺点作了总结。

表1 两种解析方式的比较

可以看出，DOM和SAX基本上是正好相反的两个极端，两者都不能很好的满足XML加速的要求。所以我们选择了另外一种处理技术，它既有很好的易用性，占用内存少，而且运行速度也很高。这就是VTD-XML解析技术。

2.2 VTD-XML的基本原理

VTD-XML（Virtual Token Descriptor，虚拟令牌描述符）是一种新型的、开源的、非提取性的XML处理方式。非提取的意思，即解析器将XML文档视为一个大标记筐，并创建详细描述XML中标记位置的地图，解析器会将标记与原文中保持一样[4]。它能够实现数据的随机存取，而不会导致过多的资源浪费，这很好地解决了DOM占用内存过大的缺点。

在DOM中，内存的表达包括大量由指示器缝合起来的节点对象（无论网元、文本、CDATA或属性）。把一切当做节点对象的例程会降低性能，同时增加内存使用开销。这是DOM处理速度缓慢的一个主要原因。

VTD技术的关键优化就在于它采用非提取性的令牌环结构。VTD-XML在内存中保存完整及未解码的XML消息，并使用一个二进制编码规范来唯一地表示每个符号。这种规范被称为Virtual Token Descriptor（虚拟符号描述符）。每个VTD记录都是一个64位长的数据类型（如图2所示），它对XML中符号的长度、起始偏移量、类型、嵌套深度进行了编码。

图2 VTD记录的数位分布

VTD记录固定长度的目的就是为了提高性能，因为长度固定在读取、查询等操作的时候格外的高效，也就是可以用数组这种高效的结构来组织 VTD，从而大大减少了因为大量使用对象而产生的性能问题。它能够将XML这种树形的数据结构简单地变换成对一个字节数组的操作。举例来说，如果要查找一个元素并删除它，那么只需要找到这个元素的VTD，将这个VTD从VTD数组中删除，然后再将所有的VTD写出到另一个数组中就可以了，因为删除的VTD标明了要删除的元素的位置，所以在新写入的数组中就不会出现这段元素了。这就是所谓的增量更新，其效率相当的高。

关于遍历方式，VTD-XML采用位置缓存LC（Location Cache），简单来说就是以VTD深度作为标准构建一个树形的表结构。LC的条目也是64位长的数值类型，前32位代表一个VTD的索引，后32位代表了这个VTD的第一个孩子的索引。利用这些信息就可以计算出任何想要到达的位置了。

具体解析处理过程如下：

（1）首先建立一个内存数组，把要解析的 XML文档读入数组。

（2）使用VTDGen类：创建一个VTDGen类对象，使用成员函数setDoc把数组中的值赋给VTDGen对象，然后调用Parse方法产生VTD缓存记录和记录的层次信息。

（3）使用VTDNav方法导航定位：主要的导航功能是toElement。使用 ROOT、PARENT、FIRST_CHILD、LAST_CHILD、NEXT_SIBLING和PREV_SIBLING这六个预先确定的值来完成导航定位。

（4）用Autopilot方法遍历结点，并支持XPath处理功能。

2.3 VTD-XML性能的分析

在了解了VTD-XML的基本原理后，下面将把VTD独有的性能特点和其他的解析技术进行统一的比较。

VTD-XML的层次结构仅仅是由元素的节点组成，而在DOM中，无论是属性节点还是文本节点都被认为是节点的一部分，都能够成为它层次结构的一部分。另一方面，在VTD-XML中，有且仅有一个用于VTD遍历的指针。该指针不能被复制，但可以暂时地将指针地址保存在全局的堆栈中。VTDNav有两个堆栈存取的函数，push()和pop()。假设指针现在位于元素结构信息中的某处，记录下该位置，然后将指针移向文档的另一个部分，但希望仍能够回到原先保留的位置。为了实现这样一个过程，我们首先要调用 push()函数，将位置信息保存进堆栈。然后，在指针移到文档其他位置后，我们仍可以通过 pop()函数，快速返回刚才所记录的位置。

VTD-XML最独特的一个方面，就是它基于虚拟令牌描述符的“非提取（non-extractive）”特点，这使它明显区别于任何其他的解析程序。非提取式解析是 VTD-XML能够达到最佳处理性能和内存节省的关键技术。VTD-XML是通过如下方式实现它的非提取性能的。

第一，很多 VTDNav的函数，比如 getAttrVal()，getCurrentIndex()和getText()都会返回一个整数。这个整数实际上是一个VTD记录的索引，用于调用函数时描述所需令牌。解析之后，VTD-XML会产生一个由VTD记录构成的线性缓冲区。因为VTD记录长度固定，所以只要知道信息的索引值就可以在缓冲区中获取任何的记录。要注意的是，VTD记录都不是对象，因此不能够通过指针设定地址值。当 VTDNav函数没有计算出任何有意义的值时，它会返回-1，这个值类似DOM中的空指针。

第二，因为解析程序并不产生任何字符对象（毕竟令牌是虚拟构建的），VTD-XML是直接在VTD记录中进行比较对照的操作。比如，VTDNav的matchElement()函数用于测试VTD指针记录的元素名是否与给定的字符相匹配。相似的 VTDNav函数，比如 matchTokenString()、matchRawTokenString()和matchNormalizedTokenString()函数虽然都有各自的不同点，但都能够在字符和VTD记录中进行直接的比较。这样做的好处在于，用户完全不需要自己将令牌放入字符对象中。自行创建对象并将令牌存入是比较复杂的，尤其在大量创建对象的时候更是十分繁琐的工作。避免了对象的大量创建是VTD-XML性能显著优于DOM和SAX的主要原因。

这里有一组数据，取自于VTD-XML的官方网站[5]：

VTD-XML的解析速度是 SAX（with NULL content handler）的1.5x～2.0x。With NULL content handler的意思就是说 SAX解析中没有插入任何额外的处理逻辑，也就是SAX的最高速度。VTD-XML的内存占用是原 XML的1.3x～1.5x（其中 1.0x的部分是原 XML，0.3x～0.5x是VTD-XML占用的部分），而DOM的内存占用则是原XML的 5x～10x。

内存占用率上的重大优势使得 VTD-XML可以被用于处理大XML文档，并且对任意大小的文件都有较好的性能。

3 VTD解析的硬件实现

VTD-XML是一个开源项目，目前有C、C#、JAVA三种平台支持。对它的研究仍然有许多改进与完善的空间，比如它在硬件上的应用。我们研究的最终目标是将VTD解析移植到芯片上（本实验室采用的是 Altera NIOSⅡ硬件平台），连同TCP/IP协议栈、HTTP协议、SOAP处理器以及建立于 SOAP之上的服务逻辑等模块一起，共同组成整个XML加速系统，系统架构如图3所示。

图3 系统总体架构

在多数XML处理过程中，问题在于将数据处理带到芯片级别时，并不是依靠XML本身来完成的，就像XML所使用的处理模型一样。举例来说，DOM和SAX，两者都需要构建一个复杂的内存中的数据结构，以及在这些模型中任意向前浏览或向后浏览的能力。它们还使用动态数据结构，这种结构会随着时间不断变化，并且截取任意大小的数据块（有时候会非常大）。在某种情况下，这些会引起处理器与硅芯片之间映射的问题，导致难于应用，或者是降低芯片的工作效率，达不到最好的处理效果。在将特定的处理任务固化到硅芯片之中的过程中，它们并没有真正提供一种性能或处理特长，能够用来调整必要的工作。

VTD-XML技术正是在上述背景下产生的，并且发展迅速。这种模型在内存中保留了一份XML原始的文档（可以被分割成块），然后将这份文档利用令牌形式分割成固定大小的64位数据块。这种处理方式有很多好处。首先，该处理方式和加密/解密以及包数据的分割/组装操作类似，而后者已经被广泛的认可并应用到硅芯片之中[6]。现在，我们又有了用于XML处理的模型，能够帮助我们把软件程序移植到硬件芯片中，并且保留其中的性能和处理优点。可以预见这项技术必会大大促进XML硬件加速的发展。

4 结束语

随着更多Web服务应用通过网络交换XML信息，对于进行高速处理、过滤和保护信息的安全来说，XML通信处理将不可避免地从应用服务器软件层面向硬件方向发展，密切相关的课题是在芯片上移植XML处理。VTD-XML正是这样一种适合定制硬件实施的新型处理模型，它具有迷人的优良特性，在XML处理领域有着非常广阔的应用前景。

[1][美]Sas Jacobs著.许劲松,杨波,周斌译.XML基础教程入门、DOM、Ajax与Flash.北京:人民邮电出版社,2007.

[2]OASIS.Web Services Resource Framework (WSRF)-Primer[EB/OL]http://docs.oasis-open.org/wsrf/wsrf-prime r-1.2-primer-cd-01.pdf.

[3]张志刚,XML加速器:优化 XML应用[J].中国计算机报,2004.2.9.

[4]Jimmy Zhang.Non-Extractive Parsing for XML [EB/OL]http://www.xml.com/pub/a/2004/05/19/Parsing.html.

[5]VTD-XML: The Future of XML Processing [EB/OL]http://vtd-xml.sourceforge.net/.

[6]Jimmy Zhang.XML on a chip [EB/OL]http://www.xml.com/lpt/a/2005/03/09/chip.html.