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

Question

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

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

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

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

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

任何人对此有经验或能够找到一些文档的链接来解释确切的行为/可能的 SSL 优化配置？

Answer 1

是 - 默认情况下，带有 SSL 的 Java RMI 是否对每个方法调用进行完整的 SSL 握手？

没有。

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

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