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

核心提示： 为了与普通的使用证书的 WS-Security 的性能相比较，WS-SecureConversation 配置被设置为仅在加密消息主体时使用会话令牌，Java Web 服务: WS-Security 的大开销(7)，图 2 展示了最终测试时间与 plain 及 encr 测试配置之间的比较，为便

为了与普通的使用证书的 WS-Security 的性能相比较，WS-SecureConversation 配置被设置为仅在加密消息主体时使用会话令牌。图 2 展示了最终测试时间与 plain 及 encr 测试配置之间的比较，为便于比较使用了相对 plain 配置时间的倍数：

图 2. WS-SecureConversation 时间比较

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

消息大小比较

从系列的前一篇文章中看到，WS-Security 可以会向 SOAP 消息报头添加大量块（bulk）。当数据通过网络在客户机与服务器之间传递时，这些添加的块会对性能造成显著影响（而在本文中，客户机和服务器是在相同的系统上运行的）。客户机与服务之间的网络连接的质量将决定这些增加的块会对性能造成多大的影响，但毫无疑问的是，消息越大，交换速度就越慢。

图 3 显示了不同测试用例中的典型消息的实际大小，为便于比较使用了相对 plain 配置时间的倍数：

图 3. 消息大小比较

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