tcpserver检测断开qt_TCP连接如何断开连接

场景：

5.12  Termination of Server Process

5.13  SIGPIPE Signal

5.14  Crashing of Server Host   --服务器崩溃

5.15  Crashing and Rebooting of Server Host   -服务器崩溃 重启

5.16  Shutdown of Server Host   --服务器关闭

我们知道，一个基于TCP/IP的客户端-服务器的程序中，正常情况下，我会是启动服务器使其在一个端口上监听请求，等待客户端的连接；通过TCP的三次握手，客户端能够通过socket建立一个到服务器的连接；然后，两者就可以基于这个socket连接通信了。连接结束后，客户端(进程)会退出；在不需要继续处理客户请求的情况下，服务器(进程)也将退出。而且，当一个进程退出的时候，内核会关闭所有由这个进程打开的套接字，这里将触发TCP的四次挥手进而关闭一个socket连接。但是，在一些异常的情况下，譬如：服务器进程终止、服务器主机奔溃/奔溃后重启、服务器关机的情况下，客户端向服务器发起请求的时候，将会发生什么呢？下边，我们来看看这几种情况。

注意：一下描述的各种情况所使用的示例程序在文章的最后贴出

一、服务器进程终止

我们启动客户/服务器对，然后杀死子进程(模拟服务器进程崩溃的情形，我们可从中查看客户端将发生什么)。

1：在同一个主机上启动服务器和客户，并在客户上输入一行文本，以验证一切正常。正常情况下，改行文本将由服务器回射给客户。

2：找到服务器子进程的ID，通过kill命令杀死它。作为进程终止处理的部分工作，子进程中所有打开着的描述字都被关闭。这就导致向客户发送一个FIN，而客户TCP则响应以一个ACK。这就是TCP连接终止的前一半工作。

3：子进程终止时，内核将给父进程递交SIGCHLD信号。

4：客户上没有发生任何特殊之事。客户TCP接受来自服务器TCP的FIN并响应一个ACK，然后问题是客户进程此时阻塞在fgets调用上，等待从终端接受一行文本。它是看不到这个FIN的。

5：此时我们如果运行netstat命令，可以看到如下的套接口的状态：

FIN_WAIT2即为我们杀掉的那个子进程的，因为我们知道主动关闭的那端在发送完fin并接受对端的ack后将进入fin_wait2状态，此时它在等待对端的fin。

6：现在我们在客户上在输入一行文本，我们可以看到如下的输出：

当我们输入“after server close”时，客户TCP接着把数据发送给服务器，TCP允许这么做，因为客户TCP接受到FIN只是表示服务器进程已关闭了连接的服务端，从而不再往其中发送任何数据而已。FIN的接受并没有告知客户TCP服务器进程已经终止(在这个例子中它缺失是终止了)。当服务器TCP接收到来自客户的数据时，既然先前打开那个套接口的进程已经终止，于是响应一个RST。

7：然而客户进程看不到这个RST，因为它在调用write后立即调用read，并且由于第2步中接收到FIN，所调用的read立即