WS-Security 的大开销

WS-Security 以现有的密码学以及 XML 加密和签名行业标准为基础，为 Web 服务应用程序提供了一组全面的安全特性，您可以通过 WS-Policy 和 WS-SecurityPolicy 来指定特定应用程序可以使用哪些特性，从而允许服务客户机自行配置以访问服务。通过跨多个平台和 Web 服务框架对这些标准的广泛支持，可以实现出色的互操作性（并且会不断改善）。

尽管能带来这么多好处，但 WS-Security 也存在一些缺点。在本 系列 的前两篇文章中，您已经知道 WS-Security 的配置有时会非常复杂，并且有时会在交换的消息中添加许多块（bulk）。那么，WS-Security 带来的收益在什么情况下才物有所值呢？在本文中，我们将深入探讨 WS-Security 以及相关 WS-SecureConversation 的运行时成本（在处理开销和添加块方面），并引申到如何应用 WS-Security 才能让应用程序受益的话题。

?

在测试中，客户机将查询范围调整为整体地震数据集的一部分，并生成一系列伪随机请求。每次使用相同输入参数运行客户机所生成的请求序列都是相同的，这允许我们测试不同的 Web 服务配置。通过更改客户机的输入参数（用于更改请求所使用的查询范围），可以轻松地测试不同的结果消息大小。

从 图 1 中可以看出，Secure Sockets Layer (SSL) — 从技术上说，现在应该称作 Transport Layer Security (TLS)，但本文仍然使用为人所熟知的旧表示方法 — 加密所提供的性能接近无保护措施时的性能水平（但其处理大消息比处理小消息的性能要好，处理小消息所花的时间要长 80％，处理大消息所花的时间要长 20％）。另一方面，使用 WS-Security 会造成性能显著降低。仅在请求消息上添加简单的 UsernameToken 报头会造成性能降低到 SSL 处理小消息时的性能水平，但比使用 SLL 处理大消息时的性能慢 几倍。在签名与加密相结合的情况下，测试时间比无保护措施下要长 2,100％。

从一定程序上说，WS-Security 带来的这种性能上的影响归因于 Rampart 处理程序实现的缺陷，这会造成每次有 Rampart 参与时都将各请求和响应消息转换成 Document Object Model (DOM) 格式（即使未对消息执行任何安全性处理）。应该在 Rampart 1.5 发行版中修复此问题以便它可以兼容 Axis2 1.5。根据修复的实现方式，它可以显著改善 UsernameToken 测试的运行时间。但是，即使修复了此问题可能也不会影响其他的 WS-Security 运行时间。

与 WS-Security 相结合的 XML Signature 和 XML Encryption 的运行方式，以及 WS-Security 和这些 XML 标准的实现所使用的库也是影响性能的因素之一。还记得 “Java Web 服务：Axis2 WS-Security 签名和加密” 这篇文章说过，签名 XML 消息需要一个叫做规范化 的步骤，用于在捕获签名值之前将 XML 转换为特定的规范格式。标准需要这一步骤是因为已经确定即使在解析器分解 XML 并重新生成它之后也需要保留签名。虽然这毫无疑问是 XML Signature 的一个实用的特性，但它为处理增加了大量的开销。在一定程度上，由于使用 DOM 模型是实现规范化最简单的一种方法，因此 XML 安全性库都被设计为操作 XML 的 DOM 表示。（这是为何 Rampart 处理程序即使在参与服务或客户机任务时也要生成 DOM 的原因，但前提是 DOM 有必要的作用）。仅将数据转换成 DOM 表示的步骤就会造成大量的 WS-Security 开销，这可以从 UsernameToken 时间看出。在大响应消息的情况中，这种开销看上去与实际的签名或加密处理相当（如 图 1 所示，比较 username 测试的红柱 — 其中，唯一的主要开销是 DOM 的创建 — 与 sign 和 encr 测试的红柱，其中，实际的加密处理是在创建 DOM 之后完成的）。

除了 DOM 问题之外，大部分 WS-Security 开销都是计算紧密型的生成摘要和加密数据的任务。这一部分的工作是必需的，而与所使用的实现方法无关，因此 WS-Security 处理时间的改善是有限的。本系列的后续文章将比较其他一些使用 Axis2/Rampart 的 WS-Security 实现的性能 — 但是，它们大多数都使用相同底层库，因此不要指望能看到巨大的差异。

如 图 2 所示，WS-SecureConversation 加密确实相对 WS-Security 提供显著的性能改善。这对于较小的消息尤为明显，其 WS-SecureConversation 配置的运行速度几乎是使用证书的 WS-Security 加密的两倍。而对于较大的消息来说，性能优势则逊色许多，但 WS-SecureConversation 仍然提供了 18％ 的速度提升。

与预期相符，username 配置仅增加了请求消息的大小，因为 UsernameToken 仅出现在请求消息中。其他安全性配置则同时增加了请求和响应消息的大小。WS-Security 添加的块对于较小的请求和响应消息来说更加明显。对于各配置来说，WS-Security 报头基本上是恒定不变的，因此当原始消息大小较小时，相同大小的增加会带来更加显著的影响。在使用加密时，加密数据所使用的 base64 编码中出现了单独的填充（padding）效果。

?

描述名字大小下载方法本文的源代码j-jws6.zip1.6MBHTTP

?

原文：http://www.ibm.com/developerworks/cn/java/j-jws6/