带有 SSL 的 Java RMI - SSL 握手的性能/频率

Question

我正在设置一个使用 RMI 连接 2 个 Java 应用程序的解决方案。他们都使用 Spring。目前这 2 个组件，稍后将放在不同的服务器上并一起远程通信，在同一个应用程序(JVM)中，但必须提取一部分，放到另一台服务器上并与原始应用程序远程通信。有 3 个主要要求:

1) 我们希望尽快沟通
2) 我们希望能够以最少的额外编码进行远程通信(例如添加额外的层将请求转换为 XML/JSON 并通过网络服务进行通信)
3) 我们需要通过 SSL 保护通信(双方)

RMI 似乎是满足所有 3 个要求的理想解决方案。它应该非常快(根据 http://daniel.gredler.net/2008/01/07/java-remoting-protocol-benchmarks/ )，非常容易设置(尤其是在 Spring 中)并且可以配置也可以使用 SSL(通过在 Spring RmiServiceExporter 中使用 SslRMIServerSocketFactory/SslRMIServerClientFactory)。在这种情况下，“紧耦合”不是问题，因为这两个组件实际上只是内部组件， future 重用的可能性很小。

但是，我们对使用带 SSL 的 RMI 时的性能开销有一些疑问(上面提到的原始基准测试了没有 SSL 的通信)。我无法在任何地方找到带有 SSL 的 RMI 实际如何工作，即它是否必须为每个远程方法调用执行完整的 SSL 握手。如果是这样，可能会有相当大的性能开销，并且解决方案可能不符合要求 1。

问题是 - 默认情况下，带有 SSL 的 Java RMI 是否对每个方法调用都执行完整的 SSL 握手？
如果是，是否有任何方法可以优化通信而不是这样做(比如 SSL session 重用......)？
或者我们甚至可以使用完全另一种解决方案来通过 SSL 以最少的额外编码实现最佳速度(我想到了 Spring HttpInvoker，它应该几乎和 RMI 一样快 - 在没有 SSL 的默认配置中 - 根据基准测试)？

有没有人有这方面的经验或能够找到一些文档的链接来解释确切的行为/可能的 SSL 优化配置？

Answer 1

is - is Java RMI with SSL doing a full SSL handshake on every method call by default?

没有。

• 客户端有连接池，允许重用连接
• 默认情况下每个连接只有一次握手
• 新连接可以通过简化的 SSL 握手恢复现有的 SSL session 。

我指的是 RMI 的 Sun/Oracle 实现。