在前文中讲述了Linux服务端TCP的某个链路变成CLOSE_WAIT
状态,然后由于客户端已经关闭了(发送了RST
标志的报文),那么服务端如果继续向这个链路中写入数据的话就会收到SIGPIPE
信号而终止,这篇文章主要通过客户端进入CLOSE_WAIT
后由于收到服务端产生的RST
标志报文进入死循环的情况。注:RST
表示复位,用来关闭异常的连接。
如上图所示,在虚拟机CentOS7服务器(192.168.1.177)中打开一个终端界面,执行程序linux_epoll_server_2
建立8000端口的监听服务(PID:2791)。进程的大体执行过程是通过epoll_wait
等待客户端的接入,当可读描述符就绪时打印接收的报文并回复应答报文,最后调用close
函数关闭这个描述符并将其从监听事件中删除。
新建一个Linux会话终端并执行客户端程序linux_epoll_simple_sndmsg_netstat(具体代码见文末附录部分)。在过三次握手建立TCP连接后进程进入循环模式:每次发送完报文休眠5秒(sleep(5)
)接着再次向服务端发送报文。
新建一个Linux会话终端并创建一个shell脚本linux_epoll_simple_sndmsg_netstat.sh ,里面包含关键命令sudo netstat -npt|head -n 2;sudo netstat -npa|grep 8006
。这个脚本用于监控TCP的通信状态。从下图中可以看到,最终服务端进程(PID:2791)在监听8006端口,然后和客户端进程(PID:2804)建立了TCP连接。
新建一个Linux会话终端并输入命令sudo tcpdump -i lo -n port 8006
抓取客户端和服务端的TCP通信报文。
根据前面步骤1服务端、步骤2客户端、步骤3netstat的监控以及步骤4中的TCPDUMP抓包做出具体的分析:
1、tcpdump抓包分析:
[vfhky@typecodes ~]$ sudo tcpdump -i lo -n port 8006
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
######三次握手
11:55:35.724646 IP 127.0.0.1.56710 > 127.0.0.1.8006: Flags [S], seq 1652959375, win 43690, options [mss 65495,sackOK,TS val 8433172 ecr 0,nop,wscale 7], length 0
13:09:58.084191 IP 127.0.0.1.8006 > 127.0.0.1.56710: Flags [S.], seq 2881349854, ack 1652959376, win 43690, options [mss 65495,sackOK,TS val 8433172 ecr 8433172,nop,wscale 7], length 0
11:55:35.724660 IP 127.0.0.1.56710 > 127.0.0.1.8006: Flags [.], ack 1, win 342, options [nop,nop,TS val 8433172 ecr 8433172], length 0
######客户端发送58字节的报文( seq 1:59中的59=seq(1)+length(58) )
11:55:35.724966 IP 127.0.0.1.56710 > 127.0.0.1.8006: Flags [P.], seq 1:59, ack 1, win 342, options [nop,nop,TS val 8433173 ecr 8433172], length 58
######服务端回复ACK确认报文(ACK=对方SEQ+报文长度=1+58=59)
11:55:35.724970 IP 127.0.0.1.8006 > 127.0.0.1.56710: Flags [.], ack 59, win 342, options [nop,nop,TS val 8433173 ecr 8433173], length 0
######服务端主动发送58字节的报文( seq 1:59中的59=seq(1)+length(58) )
11:55:35.725006 IP 127.0.0.1.8006 > 127.0.0.1.56710: Flags [P.], seq 1:59, ack 59, win 342, options [nop,nop,TS val 8433173 ecr 8433173], length 58
######客户端回复ACK确认报文(ACK=对方SEQ+报文长度=1+58=59)
11:55:35.725008 IP 127.0.0.1.56710 > 127.0.0.1.8006: Flags [.], ack 59, win 342, options [nop,nop,TS val 8433173 ecr 8433173], length 0
######服务端调用close函数关闭连接(发送FIN标志的报文后进入FIN_WAIT_1状态)
11:55:35.725018 IP 127.0.0.1.8006 > 127.0.0.1.56710: Flags [F.], seq 59, ack 59, win 342, options [nop,nop,TS val 8433173 ecr 8433173], length 0
######客户端回复ACK确认报文(客户端进入CLOSE_WAIT状态,服务端进入FIN_WAIT_2状态)
######ACK=对方SEQ+1=59+1=60
11:55:35.766501 IP 127.0.0.1.56710 > 127.0.0.1.8006: Flags [.], ack 60, win 342, options [nop,nop,TS val 8433215 ecr 8433173], length 0
######客户端5秒后再次发送58字节的报文(CLOSE_WAIT状态还是可以向对端发送报文的)
11:55:40.736161 IP 127.0.0.1.56710 > 127.0.0.1.8006: Flags [P.], seq 59:117, ack 60, win 342, options [nop,nop,TS val 8438184 ecr 8433173], length 58
######服务端发送RST链路重置标志的报文(客户端关闭)
11:55:40.736190 IP 127.0.0.1.8006 > 127.0.0.1.56710: Flags [R], seq 2881349914, win 0, length 0
2、netstat命令监控:由于脚本中做了sleep 1
的操作,所以监控不是很及时,对小节4的图中关键的4个部分进行分析。其中Recv-Q
对应的值为59,它不同于前文中LISTEN
状态下Recv-Q
对应的值(表示由内核完成的已就绪队列中的连接数),这里表示客户端接收缓存中有59字节的数据等待客户端进程去读取。另外为什么是59字节而不是服务端发送的58字节数据?LZ这里也不是很确定。
[vfhky@typecodes epoll]$ ./linux_epoll_simple_sndmsg_netstat.sh
######服务端建立监听
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:8006 0.0.0.0:* LISTEN 2791/linux_epoll_se
######由于服务端接收并回复报文后主动调用close函数关闭了链路,服务端进入FIN_WAIT1状态,客户端进入CLOSE_WAIT状态。
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:8006 0.0.0.0:* LISTEN 2791/linux_epoll_se
tcp 59 0 127.0.0.1:56710 127.0.0.1:8006 CLOSE_WAIT 2804/linux_epoll_si
tcp 0 1 127.0.0.1:8006 127.0.0.1:56710 FIN_WAIT1 -
######客户端回复了ACK确认报文后,服务端进入FIN_WAIT2状态
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:8006 0.0.0.0:* LISTEN 2791/linux_epoll_se
tcp 59 0 127.0.0.1:56710 127.0.0.1:8006 CLOSE_WAIT 2804/linux_epoll_si
tcp 0 0 127.0.0.1:8006 127.0.0.1:56710 FIN_WAIT2 -
######由于服务端回复了RST标志的报文导致链路重置
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:8006 0.0.0.0:* LISTEN 2791/linux_epoll_se
3、客户端进程执行过程分析:
1 2 3 4 5 | 客户端执行过程 vfhky@typecodes epoll$ linux_epoll_simple_sndmsg i_send_len=58. //第1次发送报文(正常) i_send_len=58. //5秒后再次发送报文,那么会收到RST标志的应答报文 vfhky@typecodes epoll$ |
---|
通过小节5中的具体分析可以看到在服务端调用close函数
关闭了客户端的连接后进入FIN_WAIT_1
状态,那么客户端立马进入了CLOSE_WAIT
状态。而服务端在收到客户端回复的ACK
报文后进入FIN_WAIT_2
状态。
因为处于CLOSE_WAIT
状态的一方仍然可以向对端发送报文,所以客户端在休眠5秒后再次向服务端发送了58字节的报文。但是此时的服务端已经关闭了链路(FIN_WAIT_2状态),所以Linux内核自动发送了一个RST
复位标志的报文给客户端。
但是为什么客户端进程在收到RST
报文后会关闭呢?原因和《Linux TCP通信出现CLOSE_WAIT后导致服务端进程挂掉》是一样的,就是Linux内核产生软中断,发送SIGPIPE
信号给客户端进程,导致其默认终止了。这点可以通过设置客户端程序中#define SIGNAL_HANDLE 0
为1来验证,执行的效果如下图所示:
那么问题又来了,由于捕捉了SIGPIPE
信号(对应值为13)后,客户端进程不会终止,所以进入了while死循环
。同时由于捕捉了SIGINT
信号(对应值为2),导致在客户端所在的Linux会话终端上无法使用Ctrl+C
来终止进程,最后只能使用kill
信号来终止客户端!
以上就是Linux TCP通信中客户端出现CLOSE_WAIT后进入死循环的一个实例以及分析过程,下面是客户端程序linux_epoll_simple_sndmsg_netstat.c,工作流程很简单。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 | /** * @FileName linux_epoll_simple_sndmsg.c * @Describe A simple example for creating a listen as a server and simulate generate a sigpipe signal in linux. * @Author vfhky 2017-03-10 12:49 https://typecodes.com/cseries/tcpclosewaitfinwaitrst1.html * @Compile gcc linux_epoll_simple_sndmsg.c -o linux_epoll_simple_sndmsg */ #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <errno.h> #include <string.h> #include <sys/types.h> #include <netinet/in.h> #include <sys/socket.h> #include <arpa/inet.h> #include <signal.h> #define IPADDR "127.0.0.1" #define SERVPORT 8006 #define MAXLINE 1024 #define SIGNAL_HANDLE 0 void sig_handle( int signal ) { printf( "Receive a signal=%d.\n", signal ); return; } int main( int argc, char **argv ) { #if SIGNAL_HANDLE struct sigaction new_act, old_act; new_act.sa_handler = sig_handle; new_act.sa_flags = 0; sigemptyset( &new_act.sa_mask ); sigaction( SIGPIPE, &new_act, &old_act ); sigaction( SIGINT, &new_act, &old_act ); #endif //发送缓存区 char bufMAXLINE = {0x00}; //成功发送的字节数 unsigned int i_send_len = 0; int sockfd; struct sockaddr_in serv_addr; //创建1个socket描述符 if((sockfd = socket(AF_INET,SOCK_STREAM,0)) == -1) { perror("socket error \n"); exit(1); } bzero( &serv_addr, sizeof(serv_addr) ); serv_addr.sin_family = AF_INET; serv_addr.sin_port = htons(SERVPORT); inet_pton( AF_INET, IPADDR, &serv_addr.sin_addr ); if( connect( sockfd, (struct sockaddr *)&serv_addr, sizeof(struct sockaddr) ) ==-1 ) { perror("connect \n"); exit(1); } printf( "sockfd=%d.\n", sockfd ); while( 1 ) { sprintf( buf, "HTTP/1.0 200 OK\r\nContent-type: text/plain\r\n\r\n%s", "Hello world!\n" ); if( ( i_send_len = write( sockfd, buf, strlen(buf) ) ) > 0 ) { printf( "i_send_len=%d.\n", i_send_len ); } sleep(5); } return 0; } |
---|