为什么在没有尝试I / O的情况下不可能检测到TCP套接字已被对等端正常关闭？

作为对最近一个问题的回应，我想知道为什么在Java中如果不尝试在TCP套接字上进行读/写操作就无法检测到套接字已被对等端正常关闭了，这是为什么？不管是使用pre-NIO Socket还是NIO，似乎都是这种情况SocketChannel。

当对等方正常关闭TCP连接时，连接两端的TCP堆栈都会知道这一事实。服务器端（启动关闭操作的服务器）以状态结束FIN_WAIT2，而客户端端（未明确响应关闭操作的服务器）以状态服务器结束CLOSE_WAIT。为什么没有一个方法Socket或SocketChannel可以查询TCP堆栈看到底层的TCP连接是否已经终止？TCP堆栈不提供此类状态信息吗？还是为了避免昂贵地调用内核而做出的设计决定？

在已经发布了该问题的一些答案的用户的帮助下，我认为我知道问题可能来自何处。没有显式关闭连接的那一侧将以TCP状态结束，CLOSE_WAIT这意味着该连接正在关闭过程中，并等待该一侧发出自己的CLOSE操作。我想这是公平的，以至于isConnected收益true和isClosed回报false，但为什么没有像isClosing？

以下是使用pre-NIO套接字的测试类。但是使用NIO可以获得相同的结果。

import java.net.ServerSocket;
import java.net.Socket;

public class MyServer {
  public static void main(String[] args) throws Exception {
    final ServerSocket ss = new ServerSocket(12345);
    final Socket cs = ss.accept();
    System.out.println("Accepted connection");
    Thread.sleep(5000);
    cs.close();
    System.out.println("Closed connection");
    ss.close();
    Thread.sleep(100000);
  }
}


import java.net.Socket;

public class MyClient {
  public static void main(String[] args) throws Exception {
    final Socket s = new Socket("localhost", 12345);
    for (int i = 0; i < 10; i++) {
      System.out.println("connected: " + s.isConnected() + 
        ", closed: " + s.isClosed());
      Thread.sleep(1000);
    }
    Thread.sleep(100000);
  }
}

当测试客户端连接到测试服务器时，即使服务器启动了连接的关闭，输出仍保持不变：

connected: true, closed: false
connected: true, closed: false
...

我经常使用Sockets，大多数情况下是使用Selectors，尽管不是网络OSI专家，但据我了解，调用shutdownOutput()Socket实际上会在网络（FIN）上发送某些内容，从而唤醒另一端的Selector（C语言中的相同行为）语言）。在这里，您可以进行检测：实际检测到尝试读取操作将失败的读取操作。

在您提供的代码中，关闭套接字将关闭输入流和输出流，而无法读取可能的数据，因此会丢失它们。Java Socket.close()方法执行“优美的”断开连接（与我最初的想法相反），方法是发送留在输出流中的数据，然后发送FIN，以指示其关闭。FIN将被另一端确认，就像任何常规数据包一样¹。

如果需要等待另一侧关闭其插槽，则需要等待其FIN。为了实现这一点，您必须检测Socket.getInputStream().read() < 0，这意味着您不应该像关闭它的那样关闭InputStream套接字。

从我在C语言以及现在在Java语言中所做的工作来看，应该这样完成同步关闭：

1. 关闭套接字输出（在另一端发送FIN，这是此套接字将发送的最后一件事）。输入仍处于打开状态，因此您可以read()检测到遥控器close()
2. 读取套接字，InputStream直到我们从另一端收到Reply-FIN（因为它将检测到FIN，它将通过相同的正常双连接过程）。这在某些操作系统上很重要，因为只要它们的缓冲区之一仍包含数据，它们就不会真正关闭套接字。它们被称为“ ghost”套接字，并在操作系统中用完描述符号（对于现代操作系统，这可能不再是问题）
3. 关闭套接字（通过调用Socket.close()或关闭其InputStream或OutputStream）

如以下Java代码段所示：

public void synchronizedClose(Socket sok) {
    InputStream is = sok.getInputStream();
    sok.shutdownOutput(); // Sends the 'FIN' on the network
    while (is.read() > 0) ; // "read()" returns '-1' when the 'FIN' is reached
    sok.close(); // or is.close(); Now we can close the Socket
}

当然，双方都必须使用相同的关闭方式，否则发送方可能一直在发送足够的数据以使while循环保持繁忙（例如，如果发送方仅在发送数据而从不读取以检测连接终止）。但您可能对此无法控制）。

正如@WarrenDew在他的评论中指出的那样，丢弃程序（应用程序层）中的数据会导致应用程序层的异常断开连接：尽管所有数据都是在TCP层（while循环）处接收的，但它们却被丢弃了。

¹：摘自“ Java基础网络 ”：见图。3.3第45页，以及整个3.7节，第43-48页

我认为这更多是一个套接字编程问题。Java只是遵循套接字编程的传统。

从维基百科：

TCP提供了从一台计算机上的一个程序到另一台计算机上的另一个程序的字节流的可靠，有序的传递。

握手完成后，TCP不会在两个端点（客户端和服务器）之间进行任何区分。术语“客户端”和“服务器”主要是为了方便。因此，“服务器”可能正在发送数据，而“客户端”可能正在同时发送其他一些数据。

术语“关闭”也具有误导性。只有FIN声明，这意味着“我将不再向您发送任何东西”。但这并不意味着就没有飞行中的数据包，或者其他没有更多要说的。如果将蜗牛邮件实现为数据链路层，或者您的数据包经过不同的路由，则接收方接收到数据包的顺序可能有误。TCP知道如何为您解决此问题。

另外，作为一个程序，您可能没有时间继续检查缓冲区中的内容。因此，在您方便时，您可以检查缓冲区中的内容。总而言之，当前的套接字实现还不错。如果实际上有isPeerClosed（），则每次调用read时都要进行额外的调用。

基础套接字API没有此类通知。

无论如何，发送TCP堆栈直到最后一个数据包都不会发送FIN位，因此从发送应用程序逻辑上关闭其套接字之前（甚至在发送该数据之前）开始，可能会有很多数据被缓冲。同样，由于网络比接收应用程序更快（我不知道，也许您正在通过较慢的连接中继数据）而被缓冲的数据对接收者来说很重要，并且您不希望接收应用程序丢弃它只是因为FIN位已被堆栈接收。

由于到目前为止，没有一个答案可以完全回答这个问题，因此，我正在总结我对这个问题的当前理解。

建立TCP连接并且一个对等方在其套接字上调用close()或shutdownOutput()在其套接字上进行连接时，连接另一端的套接字将转换为CLOSE_WAIT状态。原则上，可以从TCP堆栈中找出套接字是否处于CLOSE_WAIT状态而无需调用read/recv（例如，getsockopt()在Linux上：http : //www.developerweb.net/forum/showthread.php? t= 4395），但这不是便携式的。

Java的Socket类似乎旨在提供与BSD TCP套接字相当的抽象，可能是因为这是人们对TCP / IP应用程序进行编程时所​​习惯的抽象级别。BSD套接字是一种通用的支持，而不仅仅是INET（例如TCP）套接字，因此它们没有提供一种可移植的方式来找出套接字的TCP状态。

isCloseWait()之所以没有类似的方法，是因为人们习惯于在BSD套接字提供的抽象级别上对TCP应用程序进行编程，而不希望Java提供任何额外的方法。

可以使用java.net.Socket.sendUrgentData（int）方法检测（TCP）套接字连接的远程端是否已关闭，并在远程端关闭时捕获它抛出的IOException。这已经在Java-Java和Java-C之间进行了测试。

这避免了设计通信协议以使用某种类型的ping机制的问题。通过在套接字上禁用OOBInline（setOOBInline（false），接收到的所有OOB数据都将被静默丢弃，但仍可以发送OOB数据。如果远程端已关闭，则尝试进行连接重置，失败并导致抛出IOException异常。

如果您在协议中实际使用OOB数据，则里程可能会有所不同。

Java IO堆栈在突然崩溃时被破坏时肯定会发送FIN。根本无法检测到这一点毫无意义，因为大多数客户端仅在关闭连接时才发送FIN。

...我真正开始讨厌NIO Java类的另一个原因。似乎一切都有些混蛋。

这是一个有趣的话题。我刚刚浏览了Java代码以进行检查。根据我的发现，有两个不同的问题：第一个是TCP RFC本身，它允许远程关闭的套接字以半双工传输数据，因此远程关闭的套接字仍处于半开放状态。根据RFC，RST不会关闭连接，您需要发送一个显式的ABORT命令。因此Java允许通过半封闭套接字发送数据

（有两种方法可以读取两个端点的关闭状态。）

另一个问题是实现表示此行为是可选的。随着Java努力实现可移植性，他们实现了最佳的通用功能。我猜，维护（操作系统，半双工的实现）的映射将是一个问题。

这是Java的（以及我研究过的所有其他）OO套接字类的缺陷-无法访问select系统调用。

在C中的正确答案：

struct timeval tp;  
fd_set in;  
fd_set out;  
fd_set err;  

FD_ZERO (in);  
FD_ZERO (out);  
FD_ZERO (err);  

FD_SET(socket_handle, err);  

tp.tv_sec = 0; /* or however long you want to wait */  
tp.tv_usec = 0;  
select(socket_handle + 1, in, out, err, &tp);  

if (FD_ISSET(socket_handle, err) {  
   /* handle closed socket */  
}  

这是一个me脚的解决方法。使用SSL;），SSL会在拆卸时进行紧密握手，因此会通知您套接字已关闭（大多数实现似乎是在进行适当的握手拆卸）。

出现这种情况的原因（不是Java特定的）是因为您没有从TCP堆栈中获取任何状态信息。毕竟，套接字只是另一个文件句柄，您无法找出是否有实际数据可以在不实际尝试的情况下从中读取（select(2)这对您没有帮助，它只是表明您可以尝试而不会阻塞）。

有关更多信息，请参见Unix套接字常见问题解答。

仅写要求交换分组，这允许确定连接丢失。常见的解决方法是使用KEEP ALIVE选项。

在处理Java Java半开放套接字时，可能需要看看 isInputShutdown（）和isOutputShutdown（）。