服务端主动终止连接的情况分析

矫情吗；* 2022-09-27 14:24 168阅读 0赞

前面我们已经学习了基本的网络套接字编程，下面是与本文相关的网络编程源码github连接：  
[https://github.com/clearoff/Network-Code/tree/master/%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%92%8C%E5%AE%A2%E6%88%B7%E7%AB%AF(1V1)][https_github.com_clearoff_Network-Code_tree_master_E6_9C_8D_E5_8A_A1_E5_99_A8_E5_92_8C_E5_AE_A2_E6_88_B7_E7_AB_AF_1V1]  
然后下面我们给出与本文相关的博客连接，因为涉及到了TCP的“三次握手和四次挥手过程”：  
[http://blog.csdn.net/bit\_clearoff/article/details/60478661][http_blog.csdn.net_bit_clearoff_article_details_60478661]

## 正常退出情况 ##

首先我们来看看一次服务器和客户端正常通信的情况。  
在这之前，让我们看看TCP的三次握手与四次挥手的过程。

首先是三次握手过程。  
![三次握手][SouthEast]

下来是四次挥手过程。  
![这里写图片描述][SouthEast 1]

--------------------

下面我们结合着套接字编程，来看看TCP的这些过程（代码请点击上面的github连接）.  
![这里写图片描述][SouthEast 2]  
当我们只打开服务端时，此时由于客户端没有向服务端发出连接请求，所以服务端此时处在**LISTEN**状态，这个状态称为监听状态，表示服务端在等待客户端的连接请求报文。

![这里写图片描述][SouthEast 3]  
这次我们打开客户端，并且通过客户端向服务端发送数据，服务端页正常接收到了数据，此时服务端和客户端都处于**ESTABLISHED**状态，表示连接已经建立完成，即此时三次握手这个过程已经完毕，但是大家应该清楚，中间还有两次状态的切换**客户端的SYN-SENT** 以及 **服务端的SYN-RCV**.由于我们是手动监视，所以我们不能显示的看到这两个状态。

![这里写图片描述][SouthEast 4]  
上图中，客户端在数据通信完成后想要结束掉与服务端的连接状态，我们直接通过按**Ctrl + C** 键向客户端发送了信号将客户端终止,此时，服务端应该也会向客户端发送**ACK 字段的报文** 相当于我们完成了四次挥手过程中的前两次挥手，通过指令的查看，我们发现结果确实也是那样，随后我们在**Ctrl + C** 掉服务端，完成了后两次挥手，整个通信过程也就完成了。

--------------------

## 连接异常终止的情况 ##

上面的正常过程中，我们是让客户端比服务端先退出，这样满足了四次挥手过程的要求；现在我们让服务器在客户端前面退出，我们来看看这个过程发生了什么。  
由于我们研究的情况是连接的异常终止情况，所以三次握手状态我们就不关心了，这里我们这研究连接的异常终止情况。  
![这里写图片描述][SouthEast 5]  
上图中，我们让服务端先退出，然后我们用**netstat**观察端口的状态，此时我们发现**四次挥手过程中服务器和客户端的状态颠倒了**， 也就是说，服务端和客户端的进程那个先向对方发送**FIN 字段**报文，那么哪个就先进入**FIN\_WAIT2**状态。

![这里写图片描述][SouthEast 6]

上图发生的原因是这样的，当服务器进程被终止时，会关闭其打开的所有文件描述符，此时就会向客户端发送一个**FIN** 的报文,客户端则响应一个**ACK** 报文,但是这样只完成了**“四次挥手”**的前两次挥手，也就是说这样只实现了半关闭，客户端仍然可以向服务器写入数据。  
但是当客户端向服务器写入数据时，由于服务器端的套接字进程已经终止，此时连接的状态已经异常了，所以服务端进程不会向客户端发送**ACK** 报文，而是发送了一个**RST** 报文请求将处于异常状态的连接复位； **如果客户端此时还要向服务端发送数据，将诱发服务端TCP向服务端发送SIGPIPE信号，因为向接收到RST的套接口写数据都会收到此信号.** 所以说，这就是为什么我们主动关闭服务端后，用客户端向服务端写数据，还必须是写两次后连接才会关闭的原因。

大家可以在自己的Linux系统实验一下，用tcpdump去抓包效果会更好。

[https_github.com_clearoff_Network-Code_tree_master_E6_9C_8D_E5_8A_A1_E5_99_A8_E5_92_8C_E5_AE_A2_E6_88_B7_E7_AB_AF_1V1]: https://github.com/clearoff/Network-Code/tree/master/%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%92%8C%E5%AE%A2%E6%88%B7%E7%AB%AF%281V1%29%20%E4%BB%A3%E7%A0%81%E8%BF%9E%E6%8E%A5
[http_blog.csdn.net_bit_clearoff_article_details_60478661]: http://blog.csdn.net/bit_clearoff/article/details/60478661%20TCP%E7%9A%84%E4%B8%89%E6%AC%A1%E6%8F%A1%E6%89%8B%E4%B8%8E%E5%9B%9B%E6%AC%A1%E6%8C%A5%E6%89%8B
[SouthEast]: /images/20220708/3101d6dfc38d440eb31398b752719c61.png
[SouthEast 1]: /images/20220708/6508378a21424e83bbedce48065ce3f4.png
[SouthEast 2]: /images/20220708/15b855cae6454dfb808f12e0d4f2d399.png
[SouthEast 3]: /images/20220708/9e7e8742308b452599f6f6b7bf4db6ce.png
[SouthEast 4]: /images/20220708/6bde2cda48cc48a4815664ccf969bb4e.png
[SouthEast 5]: /images/20220708/90da942783d94f0e83ce5d5393a5e6ef.png
[SouthEast 6]: /images/20220708/a5e6825aaad5417f8b1f2058d5b1f90b.png