大家好，我是小林。

前段時(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è)話題，不想只是獵奇，也不想搞冷知識(shí)。

我們從四次揮手開(kāi)始說(shuō)起，搞點(diǎn)實(shí)用的知識(shí)點(diǎn)。

TCP四次揮手

簡(jiǎn)單回顧下TCP四次揮手。

正常情況下。只要數(shù)據(jù)傳輸完了，不管是客戶端還是服務(wù)端，都可以主動(dòng)發(fā)起四次揮手，釋放連接。

就跟上圖畫(huà)的一樣，假設(shè)，這次四次揮手是由客戶端主動(dòng)發(fā)起的，那它就是主動(dòng)方。服務(wù)器是被動(dòng)接收客戶端的揮手請(qǐng)求的，叫被動(dòng)方。

客戶端和服務(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。

大家知道，TCP是全雙工通信，意思是發(fā)送數(shù)據(jù)的同時(shí)，還可以接收數(shù)據(jù)。

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)該再嘗試接收數(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ì)返回成功。


然后被動(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。

針對(duì)第二種情況。

被動(dòng)方內(nèi)核協(xié)議棧收到了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ì)終止，異常退出。不想異常退出的話，記得捕獲處理這個(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è)客戶端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的客戶端去連接 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è)客戶端，把它畫(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è)客戶端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)建客戶端端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,?