3

整个代码很复杂，所以我直接进入重点。代码如下

SSLContext ctx = SSLContext.getInstance("TLS");

如果您阅读getInstance(String protocol) 方法的文档，它会说

This method traverses the list of registered security Providers, starting
with the most preferred Provider. A new SSLContext object encapsulating
the SSLContextSpi implementation from the first Provider that supports the
specified protocol is returned.

Note that the list of registered providers may be retrieved via the
Security.getProviders() method.

对我来说 Security.getProviders() 方法提供以下提供者

在此处输入图像描述

现在我已经验证了“TLS”协议在com.sun.net.ssl.internal.ssl.Provider（索引 2）中并且总是被选中。

但是相应的 SSLContextSpi 对象在 Java 6 和 Java 7 中有所不同。在 java 6 中，我得到了com.sun.net.ssl.internal.ssl.SSLContextImpl@7bbf68a9，而在 java 7 中，我得到了sun.security.ssl.SSLContextImpl$TLS10Context@615ece16. 这会产生非常糟糕的影响，因为稍后我创建 SSL 套接字时它们属于不同的类。

那么为什么会这样呢？有解决办法吗？我希望将相同的com.sun.net.ssl.internal.ssl.SSLContextImpl@7bbf68a9SSLContextSpi 对象封装在com.sun.net.ssl.internal.ssl.Provider上下文中（在两种情况下都是相同的）。

4

1 回答 1

5

这会产生非常糟糕的影响，因为稍后我创建 SSL 套接字时它们属于不同的类。

这不是一个坏影响。您从公共 API 中的工厂获得的实际类由 JRE 实现决定：这些具体类不是公共 API 的一部分。

您在 Java 6 和 Java 7 之间获得不同的类这一事实并不重要。即使他们有相同的名字，如果将它们相互比较也是没有意义的。

编辑：

public int read(byte[] b)当我给它一个长度为 4 的字节数组时，函数只读取 1 个字节，而且我已经确认流中有 4 个字节。

SSLSocket当你得到这个时，Java 7 中的行为是正确的。事实上，它可能表现得更好，因为这个最初的 1 字节读取是由于BEAST-prevention measure造成的。我将复制并粘贴我自己对该问题的答案，因为您犯了完全相同的错误。

您所做的关于byte[]在另一端完全按照您编写的方式阅读的假设是典型的 TCP 错误。它实际上并不特定于 SSL/TLS，但也可能发生在 TCP 连接上。

在 TCP（和 SSL/TLS）中，不能保证读取器的缓冲区将填充与写入器缓冲区中的数据包完全相同的数据包长度。所有 TCP 保证都是按顺序交付的，因此您最终会获得所有数据，但您必须将其视为流。

这就是为什么使用 TCP 的协议依靠指示符和分隔符来告诉另一端何时停止读取某些消息。

例如，HTTP 1.1 使用空行来指示标头何时结束，并使用Content-Length 标头告诉接收者期望的实体长度（或分块传输编码）。SMTP 还使用换行符和.在消息的末尾。

如果您正在设计自己的协议，则需要定义一种方式，让接收者知道您定义的有意义的数据单元何时被分隔。当您读取数据时，读取此类指示符并填充您的读取缓冲区，直到您获得您期望的字节数或直到您找到您定义的分隔符。

于 2013-09-17T18:35:53.077 回答