在Linux后端服务网络通信开发中，可能会遇到CLOSE_WAIT的状况。引起TCP CLOSE_WAIT状态的情况很多，归根结底还是由于被动关闭的一方没有关闭socket链路导致的。这篇文章主要是通过用一个简单的例子通过TCPDUMP和Wireshark这两个工具来模拟产生CLOSE_WAIT的情况，下一篇主要是对这个问题的原理解释。
1 CentOS服务端建立监听端口
如上图所示，在虚拟机CentOS7服务器（192.168.1.178）中打开一个终端界面，然后使用下面这个简单的服务端程序，建立8000端口的监听服务（PID:5325）。
/**
* @FileName server_socket.c
* @Describe A simple example for creating a listen as a server in linux system.
* @Author vfhky 2016-02-26 18:45 https://typecodes.com/cseries/tcpdumpwiresharkclosewait1.html
* @Compile gcc server_socket.c -o server_socket
*/
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <errno.h>
int main( int argc, char **argv )
{
int server_sockfd;
int client_sockfd;
int len;
int llOpt = 1;
struct sockaddr_in my_addr;
struct sockaddr_in remote_addr;
int sin_size;
char buf[BUFSIZ];
memset( &my_addr, 0, sizeof(my_addr) );
my_addr.sin_family = AF_INET;
my_addr.sin_addr.s_addr = INADDR_ANY;
my_addr.sin_port = htons(8000);
if( ( server_sockfd = socket( AF_INET, SOCK_STREAM, 0 ) ) < 0 )
{
perror("socket");
return 1;
}
if( setsockopt( server_sockfd, SOL_SOCKET, SO_REUSEADDR, &llOpt, sizeof(llOpt) ) )
{
close(server_sockfd);
return errno;
}
if( bind( server_sockfd, (struct sockaddr *)&my_addr, sizeof(struct sockaddr) ) < 0 )
{
perror( "bind" );
return 1;
}
listen( server_sockfd, 5 );
sin_size = sizeof( struct sockaddr_in );
printf( "Socket server begin to recieve connectiong from client.\n" );
while(1)
{
if( ( client_sockfd = accept( server_sockfd, (struct sockaddr *)&remote_addr, &sin_size ) ) < 0 )
{
perror( "accept" );
return 1;
}
//Print the ip address and port of client.
printf( "Accept client[%s:%u].\n", inet_ntoa(remote_addr.sin_addr), ntohs(remote_addr.sin_port) );
memset( buf, 0x00, BUFSIZ );
while( ( len = recv( client_sockfd ,buf, BUFSIZ, 0) ) > 0 )
{
buf[len]='\0';
printf( "Message from client=[%s]\n", buf );
}
close( client_sockfd );
}
close( server_sockfd );
return 0;
}
新建一个shell脚本netstat.sh，里面只包含一条有效命令netstat -nap|head -n 2;netstat -nap|grep 8000。执行该脚本可以看到服务端的监听效果：
3 在Linux中利用telnet命令创建一个客户端
再打开一个Linux终端界面，然后输入命令telnet 192.168.1.177 8000作为客户端建立与服务端的TCP连接。这时执行脚本./netstat.sh可以看到Linux客户端（PID:5331）和服务端（PID:5325）的TCP通信已经变成ESTABLISHED状态，效果如下图所示：
4 在Windows中利用telnet命令创建一个客户端
在Windows中打开一个PowerShell终端界面，然后输入命令telnet 192.168.1.177 8000作为客户端建立与Linux服务端的TCP连接。
这时执行脚本./netstat.sh可以看到Windows客户端（端口:52552）和服务端（PID:5325）的TCP通信已经变成ESTABLISHED状态，效果如下图所示：
5 在Linux中使用tcpdump工具抓包
再打开一个Linux终端界面，然后输入命令tcpdump -n port 8000进行抓包（目的是获取Windows客户端telnet建立的tcp连接的数据包）。当前面第4小节中Windows客户端发起“三次握手”时得到如下数据：
[root@typecodes ~]# tcpdump -n port 8000
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
######Windows中的telnet命令作为客户端向Linux服务器发起第一次握手，请求建立连接(SYN)
17:10:43.150463 IP 192.168.1.110.52552 > 192.168.1.177.irdmi: Flags [S], seq 4020000773, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
######Linux服务端向Windows客户端发送握手确认包(SYN+ACK)
17:10:43.150518 IP 192.168.1.177.irdmi > 192.168.1.110.52552: Flags [S.], seq 2818288395, ack 4020000774, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
######Windows客户端向Linux服务端发送确认包(ACK)，三次握手完毕
17:10:43.150652 IP 192.168.1.110.52552 > 192.168.1.177.irdmi: Flags [.], ack 1, win 256, length 0
效果如下图所示：
6 在Windows中使用Wireshark抓包
在Windows中使用telnet 192.168.1.177 8000命令建立与Linux服务端的TCP链路后（即前面小节4的操作），通过Windows客户端的TCP端口号52552开始准备使用Wireshark进行抓包。
手动直接关闭小节4中创建的Windows telnet终端界面，然后Wireshark抓包情况如下图所示：
同时，通过Linux中的netstat.sh脚本发现刚才建立的TCP通信出现了CLOSE_WAIT的状态。
同样，使用第4小节中的tcpdump抓包情况如下：
######Windows客户端被“意外”关闭，向Linux服务端发送FIN+ACK报文
17:11:35.668512 IP 192.168.1.110.52552 > 192.168.1.177.irdmi: Flags [F.], seq 1, ack 1, win 256, length 0
######Linux服务端向Windows客户端发送ACK确认报文
17:11:35.668851 IP 192.168.1.177.irdmi > 192.168.1.110.52552: Flags [.], ack 2, win 229, length 0
######2分钟后，Windows系统自动向Linux服务端发送一个RST+ACK报文，告知对方自己已关闭之前的TCP连接，同时要求对方也关闭链路
17:13:35.670464 IP 192.168.1.110.52552 > 192.168.1.177.irdmi: Flags [R.], seq 2, ack 1, win 0, length 0
效果如下图所示：
7 原因分析
通过TCPDUMP和Wireshark在利用CentOS7作为服务端、Windows10作为客户端，模拟演示了一个TCP通信的CLOSE_WAIT状态，这篇文章主要利用前文的数据尝试解释Linux服务端产生CLOSE_WAIT状态的原因。
1 原因分析：从客户端和服务端TCP通信的流程出发
从前文中的tcpdump和Wireshark抓包都可看到当Windows客户端关闭后，会主动发送带有FIN+ACK标志的报文给Linux服务端。那么从上图TCP客户端和服务端的通信流程图开始分析：客户端先进入FIN_WAIT_1状态，在收到服务端应答的ACK标志的报文后进入FIN_WAIT_2状态（在Windows中重新打开一个PowerShell窗口，然后输入命令netstat -na|findstr 8000查看）。
同时，服务端的TCP状态也就变成了CLOSE_WAIT。但是后面由于Linux服务端没有调用close()函数关闭socket链路，也即没有发送FIN标志的报文给主动关闭TCP链路的客户端，所以造成这个问题。
2 原因分析：从服务端程序出发
在服务端程序的第69行可以看到：一旦客户端关闭socket后，服务端也会调用close( client_sockfd );来关闭链路。那为什么还是会出现CLOSE_WAIT现象呢？答案是因为服务端在与客户端三次握手完后，只有一个进程（PID:5325）在处理客户端的TCP数据交互，而这个进程正在处理在Linux中使用telnet命令建立起来的这个客户端（PID:5331）的请求。
因此，在Windows中使用telnet命令作为客户端与Linux服务端完成三次握手后，没有相关进程来处理。这点也可以通过前文小节4中的截图看出，虽然TCP状态为ESTABLISHED，但是对应的进程PID/Program name为空，这点也可以通过lsof -i:8000命令验证（没有因为Windows客户端的连接出现进程打开的文件）。
当Windows客户端关闭telnet界面后，Linux服务端虽然收到了客户端的FIN+ACK标志的报文，但是没有相关进程调用close()函数通知内核发送FIN报文给客户端。这样就造成了Linux服务端的TCP状态出现了CLOSE_WAIT，同时Windows客户端的TCP状态变成了对应的FIN_WAIT_2。
3 问题延伸：从服务端程序出发
这里可能会存在疑问了，明明Windows客户端与Linux服务端建立了ESTABLISHED状态，也就是server_socket进程对它进行了处理，这不是与小节2中的原因分析相矛盾了吗？其实，这是由于对服务端的一些认识有偏差造成的，BZ之前也错误地认为以下命题是成立的：
listen()函数会使进程阻塞等待客户端的连接，也就是等待与客户端完成三次握手；
accept()函数就是服务端进程在完成三次握手后，接收客户端发送报文数据的请求，然后调用recv()函数来接收；
close()函数就是服务端进程直接向客户端发送FIN报文给客户端。
其实不然，在查阅了相关资料后，个人觉得正确的理解如下：
listen()函数不会使进程阻塞，UNP第3版84页有一句话：listen函数把一个未连接的套接字转换成一个被动套接字，指示内核应接受指向该该套接字的连接请求。
内核为任何一个给定的监听套接字维护两个队列：未完成连接队列和已完成连接队列。
因此，三次握手是由内核自动完成的，无需服务器进程插手。
accept()函数功能是从由内核维护的处于established状态的已完成连接队列列头部取出下一个已经完成的连接。
如果这个队列为空，accept()函数就会阻塞让进程进入睡眠状态。
close()函数是把一个TCP套接字标记成已关闭，然后立即返回调用进程。
TCP尝试发送已排队等待发送到对端的任何数据，发送完毕后发生的是正常的TCP连接终止序列，于是有了著名的四次挥手。
到这里问题其实已经很简单明了了，Linux内核完成“三次握手”跟服务端进程无关，当然这点也可以由程序没有打印第51、60行的数据证实。
4 总结
socket被动关闭的服务端产生CLOSE_WAIT的根本原因是没有调用close()函数关闭socket链路，也即没有发送FIN标志的报文给主动关闭TCP链路的客户端。