粗暴的關(guān)閉?vs?優(yōu)雅的關(guān)閉
前段時(shí)間,我在群里看到個(gè)小伙伴面字節(jié)時(shí)遇到的問(wèn)題:關(guān)于 close 和 shudown 我在圖解網(wǎng)絡(luò)里也介紹了一下,但是還不是太詳細(xì)。
今天具體給大家分享下?close 和?shudown 的區(qū)別,大家掌握好來(lái),下次就不怕被問(wèn)啦!我們都知道,TCP是個(gè)面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。那這里面提到的"面向連接",意味著需要 建立連接,使用連接,釋放連接。建立連接是指我們熟知的TCP三次握手。而使用連接,則是通過(guò)一發(fā)送、一確認(rèn)的形式,進(jìn)行數(shù)據(jù)傳輸。還有就是釋放連接,也就是我們常見(jiàn)的TCP四次揮手。TCP四次揮手大家應(yīng)該比較了解了,但大家見(jiàn)過(guò)三次揮手嗎?還有兩次揮手呢?都見(jiàn)過(guò)?那四次握手呢?今天這個(gè)話(huà)題,不想只是獵奇,也不想搞冷知識(shí)。我們從四次揮手開(kāi)始說(shuō)起,搞點(diǎn)實(shí)用的知識(shí)點(diǎn)。
TCP四次揮手
簡(jiǎn)單回顧下TCP四次揮手。正常情況下。只要數(shù)據(jù)傳輸完了,不管是客戶(hù)端還是服務(wù)端,都可以主動(dòng)發(fā)起四次揮手,釋放連接。就跟上圖畫(huà)的一樣,假設(shè),這次四次揮手是由客戶(hù)端主動(dòng)發(fā)起的,那它就是主動(dòng)方。服務(wù)器是被動(dòng)接收客戶(hù)端的揮手請(qǐng)求的,叫被動(dòng)方。客戶(hù)端和服務(wù)器,一開(kāi)始,都是處于ESTABLISHED
狀態(tài)。第一次揮手:一般情況下,主動(dòng)方執(zhí)行close()
或 shutdown()
方法,會(huì)發(fā)個(gè)FIN報(bào)文
出來(lái),表示"我不再發(fā)送數(shù)據(jù)了"。第二次揮手:在收到主動(dòng)方的FIN
報(bào)文后,被動(dòng)方立馬回應(yīng)一個(gè)ACK
,意思是"我收到你的FIN了,也知道你不再發(fā)數(shù)據(jù)了"。上面提到的是主動(dòng)方不再發(fā)送數(shù)據(jù)了。但如果這時(shí)候,被動(dòng)方還有數(shù)據(jù)要發(fā),那就繼續(xù)發(fā)。注意,雖然第二次和第三次揮手之間,被動(dòng)方是能發(fā)數(shù)據(jù)到主動(dòng)方的,但主動(dòng)方能不能正常收就不一定了,這個(gè)待會(huì)說(shuō)。第三次揮手:在被動(dòng)方在感知到第二次揮手之后,會(huì)做了一系列的收尾工作,最后也調(diào)用一個(gè) close()
, 這時(shí)候就會(huì)發(fā)出第三次揮手的 FIN-ACK
。第四次揮手:主動(dòng)方回一個(gè)ACK
,意思是收到了。其中第一次揮手和第三次揮手,都是我們?cè)趹?yīng)用程序中主動(dòng)觸發(fā)的(比如調(diào)用close()
方法),也就是我們平時(shí)寫(xiě)代碼需要關(guān)注的地方。第二和第四次揮手,都是內(nèi)核協(xié)議棧自動(dòng)幫我們完成的,我們寫(xiě)代碼的時(shí)候碰不到這地方,因此也不需要太關(guān)心。另外不管是主動(dòng)還是被動(dòng),每方發(fā)出了一個(gè) FIN
和一個(gè)ACK
。也收到了一個(gè) FIN
和一個(gè)ACK
。這一點(diǎn)大家關(guān)注下,待會(huì)還會(huì)提到。FIN一定要程序執(zhí)行close()或shutdown()才能發(fā)出嗎?
不一定。一般情況下,通過(guò)對(duì)socket
執(zhí)行 close()
或 shutdown()
方法會(huì)發(fā)出FIN
。但實(shí)際上,只要應(yīng)用程序退出,不管是主動(dòng)退出,還是被動(dòng)退出(因?yàn)橐恍┠涿畹脑虮?code style="font-size: inherit;line-height: inherit;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(255, 82, 82);background: rgb(248, 248, 248);">kill了), 都會(huì)發(fā)出 FIN
。FIN 是指"我不再發(fā)送數(shù)據(jù)",因此shutdown()
關(guān)閉讀不會(huì)給對(duì)方發(fā)FIN, 關(guān)閉寫(xiě)才會(huì)發(fā)FIN。
如果機(jī)器上FIN-WAIT-2狀態(tài)特別多,是為什么
根據(jù)上面的四次揮手圖,可以看出,FIN-WAIT-2
是主動(dòng)方那邊的狀態(tài)。處于這個(gè)狀態(tài)的程序,一直在等第三次揮手的FIN
。而第三次揮手需要由被動(dòng)方在代碼里執(zhí)行close()
發(fā)出。因此當(dāng)機(jī)器上FIN-WAIT-2
狀態(tài)特別多,那一般來(lái)說(shuō),另外一臺(tái)機(jī)器上會(huì)有大量的 CLOSE_WAIT
。需要檢查有大量的 CLOSE_WAIT
的那臺(tái)機(jī)器,為什么遲遲不愿調(diào)用close()
關(guān)閉連接。所以,如果機(jī)器上FIN-WAIT-2
狀態(tài)特別多,一般是因?yàn)閷?duì)端一直不執(zhí)行close()
方法發(fā)出第三次揮手。主動(dòng)方在close之后收到的數(shù)據(jù),會(huì)怎么處理
之前寫(xiě)的一篇文章《代碼執(zhí)行send成功后,數(shù)據(jù)就發(fā)出去了嗎?》中,從源碼的角度提到了,一般情況下,程序主動(dòng)執(zhí)行close()
的時(shí)候;- 如果當(dāng)前連接對(duì)應(yīng)的
socket
的接收緩沖區(qū)有數(shù)據(jù),會(huì)發(fā)RST
。 - 如果發(fā)送緩沖區(qū)有數(shù)據(jù),那會(huì)等待發(fā)送完,再發(fā)第一次揮手的
FIN
。
Close()
的含義是,此時(shí)要同時(shí)關(guān)閉發(fā)送和接收消息的功能。也就是說(shuō),雖然理論上,第二次和第三次揮手之間,被動(dòng)方是可以傳數(shù)據(jù)給主動(dòng)方的。但如果 主動(dòng)方的四次揮手是通過(guò) close()
觸發(fā)的,那主動(dòng)方是不會(huì)去收這個(gè)消息的。而且還會(huì)回一個(gè) RST
。直接結(jié)束掉這次連接。第二第三次揮手之間,不能傳輸數(shù)據(jù)嗎?
也不是。前面提到Close()
的含義是,要同時(shí)關(guān)閉發(fā)送和接收消息的功能。那如果能做到只關(guān)閉發(fā)送消息,不關(guān)閉接收消息的功能,那就能繼續(xù)收消息了。這種 half-close
的功能,通過(guò)調(diào)用shutdown()
方法就能做到。int?shutdown(int?sock,?int?howto);
其中 howto 為斷開(kāi)方式。有以下取值:
- SHUT_RD:關(guān)閉讀。這時(shí)應(yīng)用層不應(yīng)該再?lài)L試接收數(shù)據(jù),內(nèi)核協(xié)議棧中就算接收緩沖區(qū)收到數(shù)據(jù)也會(huì)被丟棄。
- SHUT_WR:關(guān)閉寫(xiě)。如果發(fā)送緩沖區(qū)中還有數(shù)據(jù)沒(méi)發(fā),會(huì)將將數(shù)據(jù)傳遞到目標(biāo)主機(jī)。
- SHUT_RDWR:關(guān)閉讀和寫(xiě)。相當(dāng)于
close()
了。
怎么知道對(duì)端socket執(zhí)行了close還是shutdown
不管主動(dòng)關(guān)閉方調(diào)用的是close()
還是shutdown()
,對(duì)于被動(dòng)方來(lái)說(shuō),收到的就只有一個(gè)FIN
。被動(dòng)關(guān)閉方就懵了,"我怎么知道對(duì)方讓不讓我繼續(xù)發(fā)數(shù)據(jù)?"其實(shí),大可不必糾結(jié),該發(fā)就發(fā)。第二次揮手和第三次揮手之間,如果被動(dòng)關(guān)閉方想發(fā)數(shù)據(jù),那么在代碼層面上,就是執(zhí)行了 send()
方法。int?send(?SOCKET?s,const?char*?buf,int?len,int?flags);
send()
會(huì)把數(shù)據(jù)拷貝到本機(jī)的發(fā)送緩沖區(qū)。如果發(fā)送緩沖區(qū)沒(méi)出問(wèn)題,都能拷貝進(jìn)去,所以正常情況下,send()
一般都會(huì)返回成功。![tcp_sendmsg 邏輯](https://cdn.jsdelivr.net/gh/xiaobaiTech/image/tcp_sendmsg 邏輯.png)然后被動(dòng)方內(nèi)核協(xié)議棧會(huì)把數(shù)據(jù)發(fā)給主動(dòng)關(guān)閉方。- 如果上一次主動(dòng)關(guān)閉方調(diào)用的是
shutdown(socket_fd, SHUT_WR)
。那此時(shí),主動(dòng)關(guān)閉方不再發(fā)送消息,但能接收被動(dòng)方的消息,一切如常,皆大歡喜。 - 如果上一次主動(dòng)關(guān)閉方調(diào)用的是
close()
。那主動(dòng)方在收到被動(dòng)方的數(shù)據(jù)后會(huì)直接丟棄,然后回一個(gè)RST
。
RST
,會(huì)把連接關(guān)閉。但內(nèi)核連接關(guān)閉了,應(yīng)用層也不知道(除非被通知)。此時(shí)被動(dòng)方應(yīng)用層接下來(lái)的操作,無(wú)非就是讀或?qū)?/strong>。- 如果是讀,則會(huì)返回
RST
的報(bào)錯(cuò),也就是我們常見(jiàn)的Connection reset by peer
。 - 如果是寫(xiě),那么程序會(huì)產(chǎn)生
SIGPIPE
信號(hào),應(yīng)用層代碼可以捕獲并處理信號(hào),如果不處理,則默認(rèn)情況下進(jìn)程會(huì)終止,異常退出。
總結(jié)一下,當(dāng)被動(dòng)關(guān)閉方
recv()
返回EOF
時(shí),說(shuō)明主動(dòng)方通過(guò) close()
或 shutdown(fd, SHUT_WR)
發(fā)起了第一次揮手。如果此時(shí)被動(dòng)方執(zhí)行兩次 send()
。- 第一次
send()
, 一般會(huì)成功返回。 - 第二次
send()
時(shí)。如果主動(dòng)方是通過(guò)shutdown(fd, SHUT_WR)
發(fā)起的第一次揮手,那此時(shí)send()
還是會(huì)成功。如果主動(dòng)方通過(guò)close()
發(fā)起的第一次揮手,那此時(shí)會(huì)產(chǎn)生SIGPIPE
信號(hào),進(jìn)程默認(rèn)會(huì)終止,異常退出。不想異常退出的話(huà),記得捕獲處理這個(gè)信號(hào)。
如果被動(dòng)方一直不發(fā)第三次揮手,會(huì)怎么樣
第三次揮手,是由被動(dòng)方主動(dòng)觸發(fā)的,比如調(diào)用close()
。如果由于代碼錯(cuò)誤或者其他一些原因,被動(dòng)方就是不執(zhí)行第三次揮手。這時(shí)候,主動(dòng)方會(huì)根據(jù)自身第一次揮手的時(shí)候用的是 close()
還是 shutdown(fd, SHUT_WR)
,有不同的行為表現(xiàn)。- 如果是
shutdown(fd, SHUT_WR)
,說(shuō)明主動(dòng)方其實(shí)只關(guān)閉了寫(xiě),但還可以讀,此時(shí)會(huì)一直處于FIN-WAIT-2
, 死等被動(dòng)方的第三次揮手。 - 如果是
close()
, 說(shuō)明主動(dòng)方讀寫(xiě)都關(guān)閉了,這時(shí)候會(huì)處于FIN-WAIT-2
一段時(shí)間,這個(gè)時(shí)間由net.ipv4.tcp_fin_timeout
控制,一般是60s
,這個(gè)值正好跟2MSL
一樣 。超過(guò)這段時(shí)間之后,狀態(tài)不會(huì)變成 `TIME-WAIT`,而是直接變成`CLOSED`。
#?cat?/proc/sys/net/ipv4/tcp_fin_timeout
60
TCP三次揮手
四次揮手聊完了,那有沒(méi)有可能出現(xiàn)三次揮手?是可能的。我們知道,TCP四次揮手里,第二次和第三次揮手之間,是有可能有數(shù)據(jù)傳輸?shù)?。第三次揮手的目的是為了告訴主動(dòng)方,"被動(dòng)方?jīng)]有數(shù)據(jù)要發(fā)了"。所以,在第一次揮手之后,如果被動(dòng)方?jīng)]有數(shù)據(jù)要發(fā)給主動(dòng)方。第二和第三次揮手是有可能合并傳輸?shù)?。這樣就出現(xiàn)了三次揮手。如果有數(shù)據(jù)要發(fā),就不能是三次揮手了嗎
上面提到的是沒(méi)有數(shù)據(jù)要發(fā)的情況,如果第二、第三次揮手之間有數(shù)據(jù)要發(fā),就不可能變成三次揮手了嗎?并不是。TCP中還有個(gè)特性叫延遲確認(rèn)??梢院?jiǎn)單理解為:接收方收到數(shù)據(jù)以后不需要立刻馬上回復(fù)ACK確認(rèn)包。在此基礎(chǔ)上,不是每一次發(fā)送數(shù)據(jù)包都能對(duì)應(yīng)收到一個(gè)ACK
確認(rèn)包,因?yàn)榻邮辗娇梢院喜⒋_認(rèn)。而這個(gè)合并確認(rèn),放在四次揮手里,可以把第二次揮手、第三次揮手,以及他們之間的數(shù)據(jù)傳輸都合并在一起發(fā)送。因此也就出現(xiàn)了三次揮手。TCP兩次揮手
前面在四次揮手中提到,關(guān)閉的時(shí)候雙方都發(fā)出了一個(gè)FIN和收到了一個(gè)ACK。正常情況下TCP連接的兩端,是不同IP 端口的進(jìn)程。但如果TCP連接的兩端,IP 端口是一樣的情況下,那么在關(guān)閉連接的時(shí)候,也同樣做到了一端發(fā)出了一個(gè)FIN,也收到了一個(gè) ACK,只不過(guò)正好這兩端其實(shí)是同一個(gè)socket
。而這種兩端IP 端口都一樣的連接,叫TCP自連接。是的,你沒(méi)看錯(cuò),我也沒(méi)打錯(cuò)別字。同一個(gè)socket確實(shí)可以自己連自己,形成一個(gè)連接。一個(gè)socket能建立連接?
上面提到了,同一個(gè)客戶(hù)端socket,自己對(duì)自己發(fā)起連接請(qǐng)求。是可以成功建立連接的。這樣的連接,叫TCP自連接。下面我們嘗試下復(fù)現(xiàn)。注意我是在以下系統(tǒng)進(jìn)行的實(shí)驗(yàn)。在mac
上多半無(wú)法復(fù)現(xiàn)。#??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)"
通過(guò)nc
命令可以很簡(jiǎn)單的創(chuàng)建一個(gè)TCP自連接#?nc?-p?6666?127.0.0.1?6666
上面的 -p
可以指定源端口號(hào)。也就是指定了一個(gè)端口號(hào)為6666
的客戶(hù)端去連接 127.0.0.1:6666
。#?netstat?-nt?|?grep?6666
tcp????????0??????0?127.0.0.1:6666??????????127.0.0.1:6666??????????ESTABLISHED
整個(gè)過(guò)程中,都沒(méi)有服務(wù)端參與??梢宰€(gè)包看下。可以看到,相同的socket,自己連自己的時(shí)候,握手是三次的。揮手是兩次的。上面這張圖里,左右都是同一個(gè)客戶(hù)端,把它畫(huà)成兩個(gè)是為了方便大家理解狀態(tài)的遷移。我們可以拿自連接的握手狀態(tài)對(duì)比下正常情況下的TCP三次握手。看了自連接的狀態(tài)圖,再看看下面幾個(gè)問(wèn)題。一端發(fā)出第一次握手后,如果又收到了第一次握手的SYN包,TCP連接狀態(tài)會(huì)怎么變化?
第一次握手過(guò)后,連接狀態(tài)就變成了SYN_SENT
狀態(tài)。如果此時(shí)又收到了第一次握手的SYN包,那么連接狀態(tài)就會(huì)從SYN_SENT
狀態(tài)變成SYN_RCVD
。//?net/ipv4/tcp_input.c
static?int?tcp_rcv_synsent_state_process()
{
????//?SYN_SENT狀態(tài)下,收到SYN包
????if?(th->syn)?{
????????//?狀態(tài)置為?SYN_RCVD
????????tcp_set_state(sk,?TCP_SYN_RECV);
????}
}
一端發(fā)出第二次握手后,如果又收到第二次握手的SYN ACK包,TCP連接狀態(tài)會(huì)怎么變化?
第二握手過(guò)后,連接狀態(tài)就變?yōu)?code style="font-size: inherit;line-height: inherit;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(255, 82, 82);background: rgb(248, 248, 248);">SYN_RCVD了,此時(shí)如果再收到第二次握手的SYN ACK
包。連接狀態(tài)會(huì)變?yōu)?code style="font-size: inherit;line-height: inherit;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(255, 82, 82);background: rgb(248, 248, 248);">ESTABLISHED。//?net/ipv4/tcp_input.c
int?tcp_rcv_state_process()
{
????//?前面省略很多邏輯,能走到這就認(rèn)為肯定有ACK
????if?(true)?{
????????//?判斷下這個(gè)ack是否合法
????????int?acceptable?=?tcp_ack(sk,?skb,?FLAG_SLOWPATH?|?FLAG_UPDATE_TS_RECENT)?>?0;
????????switch?(sk->sk_state)?{
????????case?TCP_SYN_RECV:
????????????if?(acceptable)?{
????????//?狀態(tài)從?SYN_RCVD?轉(zhuǎn)為?ESTABLISHED
????????????????tcp_set_state(sk,?TCP_ESTABLISHED);
????????????}?
????????}
????}
}
一端第一次揮手后,又收到第一次揮手的包,TCP連接狀態(tài)會(huì)怎么變化?
第一次揮手過(guò)后,一端狀態(tài)就會(huì)變成FIN-WAIT-1
。正常情況下,是要等待第二次揮手的ACK
。但實(shí)際上卻等來(lái)了 一個(gè)第一次揮手的 FIN
包, 這時(shí)候連接狀態(tài)就會(huì)變?yōu)?code style="font-size: inherit;line-height: inherit;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(255, 82, 82);background: rgb(248, 248, 248);">CLOSING。//?net/
static?void?tcp_fin(struct?sock?*sk)
{
????switch?(sk->sk_state)?{
????case?TCP_FIN_WAIT1:
????????tcp_send_ack(sk);
????//?FIN-WAIT-1狀態(tài)下,收到了FIN,轉(zhuǎn)為?CLOSING
????????tcp_set_state(sk,?TCP_CLOSING);
????????break;
????}
}
這可以說(shuō)是隱藏劇情了。CLOSING
很少見(jiàn),除了出現(xiàn)在自連接關(guān)閉外,一般還會(huì)出現(xiàn)在TCP兩端同時(shí)關(guān)閉連接的情況下。處于CLOSING
狀態(tài)下時(shí),只要再收到一個(gè)ACK
,就能進(jìn)入 TIME-WAIT
狀態(tài),然后等個(gè)2MSL
,連接就徹底斷開(kāi)了。這跟正常的四次揮手還是有些差別的。大家可以滑到文章開(kāi)頭的TCP四次揮手再對(duì)比下。代碼復(fù)現(xiàn)自連接
可能大家會(huì)產(chǎn)生懷疑,這是不是nc
這個(gè)軟件本身的bug
。那我們可以嘗試下用strace
看看它內(nèi)部都做了啥。#?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)
//?...
無(wú)非就是以創(chuàng)建了一個(gè)客戶(hù)端socket
句柄,然后對(duì)這個(gè)句柄執(zhí)行 bind
, 綁定它的端口號(hào)是6666
,然后再向 127.0.0.1:6666
發(fā)起connect
方法。我們可以嘗試用C語(yǔ)言
去復(fù)現(xiàn)一遍。下面的代碼,只用于復(fù)現(xiàn)問(wèn)題。直接跳過(guò)也完全不影響閱讀。#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:?創(chuàng)建客戶(hù)端端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,?