Java Web服务: WS-Security的大开销(2)

WS-Security 性能

本文所示的测试结果基于两个请求序列。第一个序列使用 1,000 条请求，查询参数经过调整以便各查询只匹配整个地震数据库的一小部分（1,000 条请求仅返回 826 次匹配的地震）。第二个序列使用 100 条请求，同时调整以匹配更大的数据库部分（100 条请求返回 176,745 次匹配的地震）。每个请求序列都在不同的安全性配置下运行了多次，每种配置只取最好的测试结果。

运行测试的环境是 Mandriva 2009.1 64-bit Linux® 系统、Athlon X2 5400+ 处理器、4GB 内存和 Sun Java 1.6.0_13 32 位 JVM。服务器代码在 Tomcat 6.0.20 上运行，配置为使用 1,024MB 大小的堆，客户机代码使用 512MB 大小的堆。我们使用 1.5 版本的 Axis2，并使用最新版本的 Rampart 代码。（在本文测试时，还没有与 Axis2 1.5 代码相匹配的 Rampart 发行版可用。要运行完整的测试集，为 Tomcat 配置 1,024MB 大小的堆是非常必要的（为各安全性配置使用单独的 Web 服务应用程序）；刚开始使用 256MB 大小的堆执行测试时，WS-Security 测试有时会因为各种奇怪的错误（举例来说，未提供 DTD 时出现的 “SOAP message MUST NOT contain a Document Type Declaration(DTD)” 错误）或者 java.lang.OutOfMemoryError 而失败。

我们使用以下安全性配置运行各测试：

plain：无安全性

ssl：使用 HTTPS 连接到服务器

username：请求中使用 WS-Security 纯文本 UsernameToken

sign：WS-Security 主体和报头签名，使用时间戳

encr：WS-Security 主体加密

signencr：WS-Security 主体和报头签名，使用时间戳和主体加密

实际测试时间从 plain 配置的 4 秒到 signencr 配置的 55 秒。图 1 显示了相对测试时间，为便于比较使用了相对 plain 配置时间的倍数：

图 1. 测试时间比较

Java Web服务: WS-Security的大开销(3)

从 图 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 转换为特定的规范格式。标准需要这一步骤是因为

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!