不使用客户端证书的 WS-Security
许多 WS-Security 配置要求客户端和服务器都使用 public/private 密钥对，使用 X.509 证书保证公共密钥的身份。这是使用 WS-Security 进行消息签名或加密中最广泛使用的技术，而且它有一些优势。特别地，客户端证书对请求提供了较严格的客户端身份验证和较严格的签名保证。但是它也有缺点，包括不对称加密的性能开销和每个客户端获取和维护证书的繁琐管理。
“WS-SecureConversation 性能” 介绍 WS-SecureConversation — 虽然仍然使用客户端证书 — 是如何使用对称加密来减少客户端和服务器之间持续交换消息的性能开销。在本文中，您将会了解您可以如何更一步地打破在普通的 WS-Security 和 WS-SecureConversation 交换方面都需要客户端证书的现状。
Axis2 的测试结果没有包含在 图 1 中，因为测试过程中出现了一个问题。Axis2 一开始的运行速度是可接受的，然后随着循环次数的增加，速度明显变慢。使用 Axis2 运行这个测试的总时间最后超过 Metro 的 40 倍。这种类型的变慢通常表示出现了问题，如由代码所存储值的线性查找，这里错误出现在 Axis2 对于对称加密的安全性处理中（可能是在处理客户端生成的密钥时，因为每一个请求都会生成一个新的保密密钥）。
图 2 显示了大响应测试所测得的时间。这里 Metro 又一次是运行最快的，但是 CXF 的速度很接近 — 两者的区别只有 10%。Axis2 比其他两种工具速度慢很多，这和之前文章中所介绍的 WS-Security 和 WS-SecureConversation 测试是一样的。
图 2. 使用大响应的测试时间 
这些结果（除了 Axis2）是与您根据正在进行的安全性处理得到的预期是一样的。通过这两种安全性配置，客户端和服务之间的消息交换使用了对称加密。这两者最大的不同是 WS-Security 对称加密配置使用了客户端为每一个请求/响应消息对生成的一个新的保密密钥。这个保密密钥需要使用服务器的公钥进行不对称加密，然后它会作为请求消息的一部分发送，这样 WS-SecureConversation 就可以在许多消息对中重用一个保密密钥。这意味着 WS-Security 配置为每个请求带来严重的过载，这主要显示在 图 1 的时间中。
这些工具并不支持使用 WS-Security 对称加密来只 加密一条消息，而是同时还要求使用签名才能完成。这使得我们很难作直接的性能比较，但是您可以通过将这些图表与 “WS-SecureConversation 性能” 中的图表进行比较来了解它们之间的区别。前一篇文章显示 WS-SecureConversation 对称加密显然比 WS-Security 不对称加密具有更好的性能，特别是在加密消息时。这些结果表明使用客户端生成的密钥进行 WS-Security 对称加密几乎和 WS-SecureConversation 一样快，特别是对于较大的消息。
?
描述名字大小下载方法本文的示例代码j-jws17.zip5.29MBHTTP
?
原文：http://www.ibm.com/developerworks/cn/java/j-jws17/
