粗暴的关闭 vs 优雅的关闭
时间:2021-09-03 10:13:02
手机看文章
扫描二维码
随时随地手机看文章
[导读]大家好,我是小林。前段时间,我在群里看到个小伙伴面字节时遇到的问题:关于close和shudown我在图解网络里也介绍了一下,但是还不是太详细。今天具体给大家分享下 close和 shudown的区别,大家掌握好来,下次就不怕被问啦!我们都知道,TCP是个面向连接的、可靠的、基于...
大家好,我是小林。
前段时间,我在群里看到个小伙伴面字节时遇到的问题:关于 close 和 shudown 我在图解网络里也介绍了一下,但是还不是太详细。
今天具体给大家分享下 close 和 shudown 的区别,大家掌握好来,下次就不怕被问啦!我们都知道,TCP是个面向连接的、可靠的、基于字节流的传输层通信协议。那这里面提到的"面向连接",意味着需要 建立连接,使用连接,释放连接。建立连接是指我们熟知的TCP三次握手。而使用连接,则是通过一发送、一确认的形式,进行数据传输。还有就是释放连接,也就是我们常见的TCP四次挥手。TCP四次挥手大家应该比较了解了,但大家见过三次挥手吗?还有两次挥手呢?都见过?那四次握手呢?今天这个话题,不想只是猎奇,也不想搞冷知识。我们从四次挥手开始说起,搞点实用的知识点。
总结一下,当被动关闭方
前段时间,我在群里看到个小伙伴面字节时遇到的问题:关于 close 和 shudown 我在图解网络里也介绍了一下,但是还不是太详细。
今天具体给大家分享下 close 和 shudown 的区别,大家掌握好来,下次就不怕被问啦!我们都知道,TCP是个面向连接的、可靠的、基于字节流的传输层通信协议。那这里面提到的"面向连接",意味着需要 建立连接,使用连接,释放连接。建立连接是指我们熟知的TCP三次握手。而使用连接,则是通过一发送、一确认的形式,进行数据传输。还有就是释放连接,也就是我们常见的TCP四次挥手。TCP四次挥手大家应该比较了解了,但大家见过三次挥手吗?还有两次挥手呢?都见过?那四次握手呢?今天这个话题,不想只是猎奇,也不想搞冷知识。我们从四次挥手开始说起,搞点实用的知识点。
TCP四次挥手
简单回顾下TCP四次挥手。正常情况下。只要数据传输完了,不管是客户端还是服务端,都可以主动发起四次挥手,释放连接。就跟上图画的一样,假设,这次四次挥手是由客户端主动发起的,那它就是主动方。服务器是被动接收客户端的挥手请求的,叫被动方。客户端和服务器,一开始,都是处于ESTABLISHED
状态。第一次挥手:一般情况下,主动方执行close()
或 shutdown()
方法,会发个FIN报文
出来,表示"我不再发送数据了"。第二次挥手:在收到主动方的FIN
报文后,被动方立马回应一个ACK
,意思是"我收到你的FIN了,也知道你不再发数据了"。上面提到的是主动方不再发送数据了。但如果这时候,被动方还有数据要发,那就继续发。注意,虽然第二次和第三次挥手之间,被动方是能发数据到主动方的,但主动方能不能正常收就不一定了,这个待会说。第三次挥手:在被动方在感知到第二次挥手之后,会做了一系列的收尾工作,最后也调用一个 close()
, 这时候就会发出第三次挥手的 FIN-ACK
。第四次挥手:主动方回一个ACK
,意思是收到了。其中第一次挥手和第三次挥手,都是我们在应用程序中主动触发的(比如调用close()
方法),也就是我们平时写代码需要关注的地方。第二和第四次挥手,都是内核协议栈自动帮我们完成的,我们写代码的时候碰不到这地方,因此也不需要太关心。另外不管是主动还是被动,每方发出了一个 FIN
和一个ACK
。也收到了一个 FIN
和一个ACK
。这一点大家关注下,待会还会提到。FIN一定要程序执行close()或shutdown()才能发出吗?
不一定。一般情况下,通过对socket
执行 close()
或 shutdown()
方法会发出FIN
。但实际上,只要应用程序退出,不管是主动退出,还是被动退出(因为一些莫名其妙的原因被kill
了), 都会发出 FIN
。FIN 是指"我不再发送数据",因此shutdown()
关闭读不会给对方发FIN, 关闭写才会发FIN。
如果机器上FIN-WAIT-2状态特别多,是为什么
根据上面的四次挥手图,可以看出,FIN-WAIT-2
是主动方那边的状态。处于这个状态的程序,一直在等第三次挥手的FIN
。而第三次挥手需要由被动方在代码里执行close()
发出。因此当机器上FIN-WAIT-2
状态特别多,那一般来说,另外一台机器上会有大量的 CLOSE_WAIT
。需要检查有大量的 CLOSE_WAIT
的那台机器,为什么迟迟不愿调用close()
关闭连接。所以,如果机器上FIN-WAIT-2
状态特别多,一般是因为对端一直不执行close()
方法发出第三次挥手。主动方在close之后收到的数据,会怎么处理
之前写的一篇文章《代码执行send成功后,数据就发出去了吗?》中,从源码的角度提到了,一般情况下,程序主动执行close()
的时候;- 如果当前连接对应的
socket
的接收缓冲区有数据,会发RST
。 - 如果发送缓冲区有数据,那会等待发送完,再发第一次挥手的
FIN
。
Close()
的含义是,此时要同时关闭发送和接收消息的功能。也就是说,虽然理论上,第二次和第三次挥手之间,被动方是可以传数据给主动方的。但如果 主动方的四次挥手是通过 close()
触发的,那主动方是不会去收这个消息的。而且还会回一个 RST
。直接结束掉这次连接。第二第三次挥手之间,不能传输数据吗?
也不是。前面提到Close()
的含义是,要同时关闭发送和接收消息的功能。那如果能做到只关闭发送消息,不关闭接收消息的功能,那就能继续收消息了。这种 half-close
的功能,通过调用shutdown()
方法就能做到。int shutdown(int sock, int howto);
其中 howto 为断开方式。有以下取值:
- SHUT_RD:关闭读。这时应用层不应该再尝试接收数据,内核协议栈中就算接收缓冲区收到数据也会被丢弃。
- SHUT_WR:关闭写。如果发送缓冲区中还有数据没发,会将将数据传递到目标主机。
- SHUT_RDWR:关闭读和写。相当于
close()
了。
怎么知道对端socket执行了close还是shutdown
不管主动关闭方调用的是close()
还是shutdown()
,对于被动方来说,收到的就只有一个FIN
。被动关闭方就懵了,"我怎么知道对方让不让我继续发数据?"其实,大可不必纠结,该发就发。第二次挥手和第三次挥手之间,如果被动关闭方想发数据,那么在代码层面上,就是执行了 send()
方法。int send( SOCKET s,const char* buf,int len,int flags);
send()
会把数据拷贝到本机的发送缓冲区。如果发送缓冲区没出问题,都能拷贝进去,所以正常情况下,send()
一般都会返回成功。![tcp_sendmsg 逻辑](https://cdn.jsdelivr.net/gh/xiaobaiTech/image/tcp_sendmsg 逻辑.png)然后被动方内核协议栈会把数据发给主动关闭方。- 如果上一次主动关闭方调用的是
shutdown(socket_fd, SHUT_WR)
。那此时,主动关闭方不再发送消息,但能接收被动方的消息,一切如常,皆大欢喜。 - 如果上一次主动关闭方调用的是
close()
。那主动方在收到被动方的数据后会直接丢弃,然后回一个RST
。
RST
,会把连接关闭。但内核连接关闭了,应用层也不知道(除非被通知)。此时被动方应用层接下来的操作,无非就是读或写。- 如果是读,则会返回
RST
的报错,也就是我们常见的Connection reset by peer
。 - 如果是写,那么程序会产生
SIGPIPE
信号,应用层代码可以捕获并处理信号,如果不处理,则默认情况下进程会终止,异常退出。
总结一下,当被动关闭方
recv()
返回EOF
时,说明主动方通过 close()
或 shutdown(fd, SHUT_WR)
发起了第一次挥手。如果此时被动方执行两次 send()
。- 第一次
send()
, 一般会成功返回。 - 第二次
send()
时。如果主动方是通过shutdown(fd, SHUT_WR)
发起的第一次挥手,那此时send()
还是会成功。如果主动方通过close()
发起的第一次挥手,那此时会产生SIGPIPE
信号,进程默认会终止,异常退出。不想异常退出的话,记得捕获处理这个信号。
如果被动方一直不发第三次挥手,会怎么样
第三次挥手,是由被动方主动触发的,比如调用close()
。如果由于代码错误或者其他一些原因,被动方就是不执行第三次挥手。这时候,主动方会根据自身第一次挥手的时候用的是 close()
还是 shutdown(fd, SHUT_WR)
,有不同的行为表现。- 如果是
shutdown(fd, SHUT_WR)
,说明主动方其实只关闭了写,但还可以读,此时会一直处于FIN-WAIT-2
, 死等被动方的第三次挥手。 - 如果是
close()
, 说明主动方读写都关闭了,这时候会处于FIN-WAIT-2
一段时间,这个时间由net.ipv4.tcp_fin_timeout
控制,一般是60s
,这个值正好跟2MSL
一样 。超过这段时间之后,状态不会变成 `TIME-WAIT`,而是直接变成`CLOSED`。
# cat /proc/sys/net/ipv4/tcp_fin_timeout
60
TCP三次挥手
四次挥手聊完了,那有没有可能出现三次挥手?是可能的。我们知道,TCP四次挥手里,第二次和第三次挥手之间,是有可能有数据传输的。第三次挥手的目的是为了告诉主动方,"被动方没有数据要发了"。所以,在第一次挥手之后,如果被动方没有数据要发给主动方。第二和第三次挥手是有可能合并传输的。这样就出现了三次挥手。如果有数据要发,就不能是三次挥手了吗
上面提到的是没有数据要发的情况,如果第二、第三次挥手之间有数据要发,就不可能变成三次挥手了吗?并不是。TCP中还有个特性叫延迟确认。可以简单理解为:接收方收到数据以后不需要立刻马上回复ACK确认包。在此基础上,不是每一次发送数据包都能对应收到一个ACK
确认包,因为接收方可以合并确认。而这个合并确认,放在四次挥手里,可以把第二次挥手、第三次挥手,以及他们之间的数据传输都合并在一起发送。因此也就出现了三次挥手。TCP两次挥手
前面在四次挥手中提到,关闭的时候双方都发出了一个FIN和收到了一个ACK。正常情况下TCP连接的两端,是不同IP 端口的进程。但如果TCP连接的两端,IP 端口是一样的情况下,那么在关闭连接的时候,也同样做到了一端发出了一个FIN,也收到了一个 ACK,只不过正好这两端其实是同一个socket
。而这种两端IP 端口都一样的连接,叫TCP自连接。是的,你没看错,我也没打错别字。同一个socket确实可以自己连自己,形成一个连接。一个socket能建立连接?
上面提到了,同一个客户端socket,自己对自己发起连接请求。是可以成功建立连接的。这样的连接,叫TCP自连接。下面我们尝试下复现。注意我是在以下系统进行的实验。在mac
上多半无法复现。# cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
通过nc
命令可以很简单的创建一个TCP自连接# nc -p 6666 127.0.0.1 6666
上面的 -p
可以指定源端口号。也就是指定了一个端口号为6666
的客户端去连接 127.0.0.1:6666
。# netstat -nt | grep 6666
tcp 0 0 127.0.0.1:6666 127.0.0.1:6666 ESTABLISHED
整个过程中,都没有服务端参与。可以抓个包看下。可以看到,相同的socket,自己连自己的时候,握手是三次的。挥手是两次的。上面这张图里,左右都是同一个客户端,把它画成两个是为了方便大家理解状态的迁移。我们可以拿自连接的握手状态对比下正常情况下的TCP三次握手。看了自连接的状态图,再看看下面几个问题。一端发出第一次握手后,如果又收到了第一次握手的SYN包,TCP连接状态会怎么变化?
第一次握手过后,连接状态就变成了SYN_SENT
状态。如果此时又收到了第一次握手的SYN包,那么连接状态就会从SYN_SENT
状态变成SYN_RCVD
。// net/ipv4/tcp_input.c
static int tcp_rcv_synsent_state_process()
{
// SYN_SENT状态下,收到SYN包
if (th->syn) {
// 状态置为 SYN_RCVD
tcp_set_state(sk, TCP_SYN_RECV);
}
}
一端发出第二次握手后,如果又收到第二次握手的SYN ACK包,TCP连接状态会怎么变化?
第二握手过后,连接状态就变为SYN_RCVD
了,此时如果再收到第二次握手的SYN ACK
包。连接状态会变为ESTABLISHED
。// net/ipv4/tcp_input.c
int tcp_rcv_state_process()
{
// 前面省略很多逻辑,能走到这就认为肯定有ACK
if (true) {
// 判断下这个ack是否合法
int acceptable = tcp_ack(sk, skb, FLAG_SLOWPATH | FLAG_UPDATE_TS_RECENT) > 0;
switch (sk->sk_state) {
case TCP_SYN_RECV:
if (acceptable) {
// 状态从 SYN_RCVD 转为 ESTABLISHED
tcp_set_state(sk, TCP_ESTABLISHED);
}
}
}
}
一端第一次挥手后,又收到第一次挥手的包,TCP连接状态会怎么变化?
第一次挥手过后,一端状态就会变成FIN-WAIT-1
。正常情况下,是要等待第二次挥手的ACK
。但实际上却等来了 一个第一次挥手的 FIN
包, 这时候连接状态就会变为CLOSING
。// net/
static void tcp_fin(struct sock *sk)
{
switch (sk->sk_state) {
case TCP_FIN_WAIT1:
tcp_send_ack(sk);
// FIN-WAIT-1状态下,收到了FIN,转为 CLOSING
tcp_set_state(sk, TCP_CLOSING);
break;
}
}
这可以说是隐藏剧情了。CLOSING
很少见,除了出现在自连接关闭外,一般还会出现在TCP两端同时关闭连接的情况下。处于CLOSING
状态下时,只要再收到一个ACK
,就能进入 TIME-WAIT
状态,然后等个2MSL
,连接就彻底断开了。这跟正常的四次挥手还是有些差别的。大家可以滑到文章开头的TCP四次挥手再对比下。代码复现自连接
可能大家会产生怀疑,这是不是nc
这个软件本身的bug
。那我们可以尝试下用strace
看看它内部都做了啥。# strace nc -p 6666 127.0.0.1 6666
// ...
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(6666), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(6666), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
// ...
无非就是以创建了一个客户端socket
句柄,然后对这个句柄执行 bind
, 绑定它的端口号是6666
,然后再向 127.0.0.1:6666
发起connect
方法。我们可以尝试用C语言
去复现一遍。下面的代码,只用于复现问题。直接跳过也完全不影响阅读。#include
#include
#include
#include
#include
#include
#include
#include
int main()
{
int lfd, cfd;
struct sockaddr_in serv_addr, clie_addr;
socklen_t clie_addr_len;
char buf[BUFSIZ];
int n = 0, i = 0, ret = 0 ;
printf("This is a client \n");
/*Step 1: 创建客户端端socket描述符cfd*/
cfd = socket(AF_INET, SOCK_STREAM, 0);
if(cfd == -1)
{
perror("socket error");
exit(1);
}
int flag=1,len=sizeof(int);
if( setsockopt(cfd, SOL_SOCKET, SO_REUSEADDR,