在套接字的输入流上关闭需要太长时间

Question

我们时不时遇到一个客户的问题，这些客户的连接在特定时间后断开。 客户端上的异常显示“读取超时”消息。 由于我们不在Java应用程序中使用套接字超时（我们使用默认值0），因此我们首先想到的是客户端的超时必须来自其代理或路由器。 他们的IT部门正在调查此问题。

但是，当连接中止时，我们的客户端应用程序将关闭套接字，然后建立与服务器的新连接。 收到来自同一客户端的新连接后，服务器将在开始使用新连接之前对旧连接发起清除操作。 当服务器检测到EOS或任何其他读取异常，或者同一客户端接受新连接并且无论出于何种原因尚未清除旧连接时，都会发生这种清除（这是由于服务器故障导致的情况）以检测EOS）。 该清除操作实际上包括一些日志记录，清除各种路由数据结构以及最终关闭输入和输出流。 到那时，我们已经观察到，旧套接字的输入流关闭15分钟，并且时间总是相同的。 如您所知，然后一切都会出错，因为新的连接开始饿死并且相同的问题反复地从头开始。

现在，我想我们服务器端的套接字正处于不确定的FIN_WAIT_2或TIME_WAIT状态，在这种状态下，套接字保持在这些状态之一，而没有收到必要的ACK（也许被丢弃），这可能会将其移至CLOSED状态。 尽管我们的服务器并不是一开始就断开连接的服务器，但我想它是客户端的代理或路由器，它可能已经启动并使其看起来像我们服务器的关闭。 我已经读到将服务器端的SO_LINGER选项设置为0可以在这种情况下提供帮助（尽管通常不建议这样做）。 仅供参考：到目前为止，我们还没有弄清楚SO_LINGER选项，但是由于这个问题，我们正在考虑这样做。

您能解释一下这个理论是否正确吗？ 而且，为什么要使插座关闭操作要花费15分钟？ 这远远超出了正常的2 * MSL（最大段生存时间）持续时间，这应该是套接字等待关闭的时间。 我们是否应该将SO_LINGER选项（Java中的setSoLinger方法）的值设置为大于0的值？ 无论如何，客户端已经中止了另一端的连接，因此，仅在关闭套接字之前将linger选项设置为0不会在客户端上导致任何其他异常或错误状态。 此外，您有没有可用的工具可以用来模拟环境中丢弃的数据包？

进行套接字创建和清理的代码没有什么特别的。 这是一个片段：

Socket socket = new Socket(ipAddress, port);
OutputStream dataOutputStream = new BufferedOutputStream(socket.getOutputStream(), 64000);
InputStream dataInputStream = new BufferedInputStream(socket.getInputStream(), 64000);

流关闭代码

 try {
       if (dataInputStream != null) {
          LOGGER.info("Going to close input stream....");
          dataInputStream.close();
       }
    } finally {
       if (dataOutputStream != null) {
          LOGGER.info(".closeReaderWriter()", "Going to close output stream...");
          dataOutputStream.close();
      }
    }

Answer 1

关闭套接字的输入流会关闭套接字和输出流，而不会刷新它。 影响插座的唯一实际操作是关闭插座。 除非您已经弄乱了SO_LINGER选项，否则关闭套接字是异步的，因此通常不会出现您描述的情况。

结论：您已经弄乱了SO_LINGER选项。

解决方案：不。

您说服务器在重新连接之前无法检测到客户端问题。

结论：发生这些读取超时时，您不会在客户端应用程序中关闭套接字。

解决方案：将其关闭。 然后，服务器将读取EOS，关闭套接字，然后继续运行。

不需要关闭套接字的输入流。 只需关闭您包装在套接字输出流周围的最外面的输出流/写入器，以确保将其刷新即可，并且可能将套接字本身放在finally块中。

其余的提出的问题多于答案。

1. 您如何“完全禁用Java应用程序中的套接字超时”？
2. 您说您的服务器正在“清理”，但您也说它“首先没有启动关闭”。 为什么不？