Java InputStream 自动拆分套接字消息

Question

我在 Java 中有一个非常奇怪的行为，我不知道这是故意发生的还是偶然发生的。

我确实有一个到服务器的套接字连接，它向我发送对请求的响应。我正在使用以下循环从 Socket 读取此响应，该循环封装在 try-with-resource 中。

BufferedInputStream remoteInput = new BufferedInputStream(remoteSocket.getInputStream())
final byte[] response = new byte[512];
int bytes_read;
while ((bytes_read = remoteInput.read(response,0,response.length)) != -1) {
    // Messageparsingstuff which does not affect the behaviour
}

根据我的理解，“读取”方法将尽可能多的字节填充到字节数组中。限制因素是接收的字节数或数组的大小。

不幸的是，这不是发生的事情：我正在传输的协议用几个较小的答案来回答我的请求，这些答案通过同一个套接字连接一个接一个地发送。

在我的情况下，“读取”方法总是返回数组中那些较小的答案之一。答案的长度各不相同，但适合数组的 512 字节总是足够的。这意味着我的数组始终只包含一条消息，并且数组的其余/不需要的部分保持不变。

如果我故意将字节数组定义为小于我的消息，它将返回几个完全填充的数组和一个包含其余字节的最后一个数组，直到消息完成。

（数组长度为 30 的 100 字节答案返回三个完全填充的数组和一个仅使用 10 个字节的数组）

InputStream 或套接字连接通常不应该以任何方式解释传输的字节，这就是我现在很困惑的原因。我的程序以任何方式都不知道使用的协议。其实我整个程序就是这个循环和建立socket连接需要的东西。

如果我可以依赖这种行为，它会使解析响应变得非常容易，但由于我不知道首先是什么导致了这种行为，所以我不知道我是否可以指望它。

我正在传输的协议是 LDAP，但由于我的程序完全不知道这一点，所以这不重要。

Answer 1

根据我的理解，“read”方法将尽可能多的字节填充到字节数组中。

你的理解不正确。该方法返回“读取的字节数”的重点是：它可能返回任何数字。准确地说：当谈到 blocking 读取时 - 当方法返回时，它已经读取了 something；因此它将返回一个 >= 1 的数字。

换句话说：您应该从不每次都依赖read() 读取特定数量的字节。你总是总是检查返回的数字；如果您正在等待达到某个值，那么 您 必须在您的代码中对此进行处理（例如再次缓冲；直到您自己的缓冲区中有“足够”的字节才能继续） .

问题是：在这样的读取操作中涉及到一大堆元素。网络、操作系统、jvm。你无法控制到底发生了什么；因此你不能也不应该像这样在你的代码中建立任何隐含的假设。

Answer 2

虽然您可能会在给定的机器上看到这种行为，尤其是在环回上，但一旦您开始使用真实网络并使用不同的硬件，这种情况可能会发生变化。

如果您发送消息的延迟足够长，并且阅读速度足够快，您一次只能看到一条消息。但是，如果写消息发送得足够近，或者您的阅读器有任何延迟，您可能会同时收到多条消息。

此外，如果您的消息足够大，例如大约 MTU 或更多，即使您的缓冲区足够大，也可以分解单个消息。