[導(dǎo)讀]大家好，我是小林。前段時間，我在群里看到個小伙伴面字節(jié)時遇到的問題：關(guān)于close和shudown我在圖解網(wǎng)絡(luò)里也介紹了一下，但是還不是太詳細(xì)。今天具體給大家分享下?close和?shudown的區(qū)別，大家掌握好來，下次就不怕被問啦！我們都知道，TCP是個面向連接的、可靠的、基于...
大家好，我是小林。
前段時間，我在群里看到個小伙伴面字節(jié)時遇到的問題：關(guān)于 close 和 shudown 我在圖解網(wǎng)絡(luò)里也介紹了一下，但是還不是太詳細(xì)。
今天具體給大家分享下?close 和?shudown 的區(qū)別，大家掌握好來，下次就不怕被問啦！我們都知道，TCP是個面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。TCP是什么
TCP四次揮手
FIN-WAIT-2特別多的原因
close()觸發(fā)TCP四次揮手
shutdown觸發(fā)的TCP四次揮手
總結(jié)一下，當(dāng)被動關(guān)閉方
一直不發(fā)第三次揮手的情況
TCP三次揮手
TCP三次揮手延遲確認(rèn)
TCP兩次揮手
image-20210810093309117 TCP自連接 正常情況下的TCP三次握手
前段時間，我在群里看到個小伙伴面字節(jié)時遇到的問題：關(guān)于 close 和 shudown 我在圖解網(wǎng)絡(luò)里也介紹了一下，但是還不是太詳細(xì)。
今天具體給大家分享下?close 和?shudown 的區(qū)別，大家掌握好來，下次就不怕被問啦！我們都知道，TCP是個面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。
TCP四次揮手
簡單回顧下TCP四次揮手。ESTABLISHED狀態(tài)。第一次揮手：一般情況下，主動方執(zhí)行close()或 shutdown()方法，會發(fā)個FIN報文出來，表示"我不再發(fā)送數(shù)據(jù)了"。第二次揮手：在收到主動方的FIN報文后，被動方立馬回應(yīng)一個ACK，意思是"我收到你的FIN了，也知道你不再發(fā)數(shù)據(jù)了"。上面提到的是主動方不再發(fā)送數(shù)據(jù)了。但如果這時候，被動方還有數(shù)據(jù)要發(fā)，那就繼續(xù)發(fā)。注意，雖然第二次和第三次揮手之間，被動方是能發(fā)數(shù)據(jù)到主動方的，但主動方能不能正常收就不一定了，這個待會說。第三次揮手：在被動方在感知到第二次揮手之后，會做了一系列的收尾工作，最后也調(diào)用一個 close(), 這時候就會發(fā)出第三次揮手的 FIN-ACK。第四次揮手：主動方回一個ACK，意思是收到了。其中第一次揮手和第三次揮手，都是我們在應(yīng)用程序中主動觸發(fā)的（比如調(diào)用close()方法），也就是我們平時寫代碼需要關(guān)注的地方。第二和第四次揮手，都是內(nèi)核協(xié)議棧自動幫我們完成的，我們寫代碼的時候碰不到這地方，因此也不需要太關(guān)心。另外不管是主動還是被動，每方發(fā)出了一個 FIN 和一個ACK 。也收到了一個 FIN 和一個ACK 。這一點大家關(guān)注下，待會還會提到。FIN一定要程序執(zhí)行close()或shutdown()才能發(fā)出嗎？
不一定。一般情況下，通過對socket執(zhí)行 close() 或 shutdown() 方法會發(fā)出FIN。但實際上，只要應(yīng)用程序退出，不管是主動退出，還是被動退出（因為一些莫名其妙的原因被kill了）, 都會發(fā)出 FIN。FIN 是指"我不再發(fā)送數(shù)據(jù)"，因此shutdown() 關(guān)閉讀不會給對方發(fā)FIN, 關(guān)閉寫才會發(fā)FIN。如果機器上FIN-WAIT-2狀態(tài)特別多，是為什么
根據(jù)上面的四次揮手圖，可以看出，FIN-WAIT-2是主動方那邊的狀態(tài)。處于這個狀態(tài)的程序，一直在等第三次揮手的FIN。而第三次揮手需要由被動方在代碼里執(zhí)行close() 發(fā)出。因此當(dāng)機器上FIN-WAIT-2狀態(tài)特別多，那一般來說，另外一臺機器上會有大量的 CLOSE_WAIT。需要檢查有大量的 CLOSE_WAIT的那臺機器，為什么遲遲不愿調(diào)用close()關(guān)閉連接。所以，如果機器上FIN-WAIT-2狀態(tài)特別多，一般是因為對端一直不執(zhí)行close()方法發(fā)出第三次揮手。主動方在close之后收到的數(shù)據(jù)，會怎么處理
之前寫的一篇文章《代碼執(zhí)行send成功后，數(shù)據(jù)就發(fā)出去了嗎？》中，從源碼的角度提到了，一般情況下，程序主動執(zhí)行close()的時候；- 如果當(dāng)前連接對應(yīng)的
socket的接收緩沖區(qū)有數(shù)據(jù)，會發(fā)RST。 - 如果發(fā)送緩沖區(qū)有數(shù)據(jù)，那會等待發(fā)送完，再發(fā)第一次揮手的
FIN。
Close()的含義是，此時要同時關(guān)閉發(fā)送和接收消息的功能。也就是說，雖然理論上，第二次和第三次揮手之間，被動方是可以傳數(shù)據(jù)給主動方的。但如果 主動方的四次揮手是通過 close() 觸發(fā)的，那主動方是不會去收這個消息的。而且還會回一個 RST。直接結(jié)束掉這次連接。第二第三次揮手之間，不能傳輸數(shù)據(jù)嗎？
也不是。前面提到Close()的含義是，要同時關(guān)閉發(fā)送和接收消息的功能。那如果能做到只關(guān)閉發(fā)送消息，不關(guān)閉接收消息的功能，那就能繼續(xù)收消息了。這種 half-close 的功能，通過調(diào)用shutdown() 方法就能做到。int?shutdown(int?sock,?int?howto);
其中 howto 為斷開方式。有以下取值：
- SHUT_RD：關(guān)閉讀。這時應(yīng)用層不應(yīng)該再嘗試接收數(shù)據(jù)，內(nèi)核協(xié)議棧中就算接收緩沖區(qū)收到數(shù)據(jù)也會被丟棄。
- SHUT_WR：關(guān)閉寫。如果發(fā)送緩沖區(qū)中還有數(shù)據(jù)沒發(fā)，會將將數(shù)據(jù)傳遞到目標(biāo)主機。
- SHUT_RDWR：關(guān)閉讀和寫。相當(dāng)于
close()了。
怎么知道對端socket執(zhí)行了close還是shutdown
不管主動關(guān)閉方調(diào)用的是close()還是shutdown()，對于被動方來說，收到的就只有一個FIN。被動關(guān)閉方就懵了，"我怎么知道對方讓不讓我繼續(xù)發(fā)數(shù)據(jù)？"send() 方法。int?send(?SOCKET?s,const?char*?buf,int?len,int?flags);
send() 會把數(shù)據(jù)拷貝到本機的發(fā)送緩沖區(qū)。如果發(fā)送緩沖區(qū)沒出問題，都能拷貝進(jìn)去，所以正常情況下，send()一般都會返回成功。然后被動方內(nèi)核協(xié)議棧會把數(shù)據(jù)發(fā)給主動關(guān)閉方。- 如果上一次主動關(guān)閉方調(diào)用的是
shutdown(socket_fd, SHUT_WR)。那此時，主動關(guān)閉方不再發(fā)送消息，但能接收被動方的消息，一切如常，皆大歡喜。 - 如果上一次主動關(guān)閉方調(diào)用的是
close()。那主動方在收到被動方的數(shù)據(jù)后會直接丟棄，然后回一個RST。
RST，會把連接關(guān)閉。但內(nèi)核連接關(guān)閉了，應(yīng)用層也不知道（除非被通知）。此時被動方應(yīng)用層接下來的操作，無非就是讀或?qū)?/strong>。- 如果是讀，則會返回
RST的報錯，也就是我們常見的Connection reset by peer。 - 如果是寫，那么程序會產(chǎn)生
SIGPIPE信號，應(yīng)用層代碼可以捕獲并處理信號，如果不處理，則默認(rèn)情況下進(jìn)程會終止，異常退出。
總結(jié)一下，當(dāng)被動關(guān)閉方
recv() 返回EOF時，說明主動方通過 close()或 shutdown(fd, SHUT_WR) 發(fā)起了第一次揮手。如果此時被動方執(zhí)行兩次 send()。- 第一次
send(), 一般會成功返回。 - 第二次
send()時。如果主動方是通過shutdown(fd, SHUT_WR)發(fā)起的第一次揮手，那此時send()還是會成功。如果主動方通過close()發(fā)起的第一次揮手，那此時會產(chǎn)生SIGPIPE信號，進(jìn)程默認(rèn)會終止，異常退出。不想異常退出的話，記得捕獲處理這個信號。
如果被動方一直不發(fā)第三次揮手，會怎么樣
第三次揮手，是由被動方主動觸發(fā)的，比如調(diào)用close()。如果由于代碼錯誤或者其他一些原因，被動方就是不執(zhí)行第三次揮手。這時候，主動方會根據(jù)自身第一次揮手的時候用的是 close() 還是 shutdown(fd, SHUT_WR) ，有不同的行為表現(xiàn)。- 如果是
shutdown(fd, SHUT_WR)，說明主動方其實只關(guān)閉了寫，但還可以讀，此時會一直處于FIN-WAIT-2， 死等被動方的第三次揮手。 - 如果是
close()， 說明主動方讀寫都關(guān)閉了，這時候會處于FIN-WAIT-2一段時間，這個時間由net.ipv4.tcp_fin_timeout控制，一般是60s，這個值正好跟2MSL一樣 。超過這段時間之后，狀態(tài)不會變成 `TIME-WAIT`，而是直接變成`CLOSED`。
#?cat?/proc/sys/net/ipv4/tcp_fin_timeout
60
TCP三次揮手
四次揮手聊完了，那有沒有可能出現(xiàn)三次揮手？是可能的。我們知道，TCP四次揮手里，第二次和第三次揮手之間，是有可能有數(shù)據(jù)傳輸?shù)?。第三次揮手的目的是為了告訴主動方，"被動方?jīng)]有數(shù)據(jù)要發(fā)了"。所以，在第一次揮手之后，如果被動方?jīng)]有數(shù)據(jù)要發(fā)給主動方。第二和第三次揮手是有可能合并傳輸?shù)?。這樣就出現(xiàn)了三次揮手。如果有數(shù)據(jù)要發(fā)，就不能是三次揮手了嗎
上面提到的是沒有數(shù)據(jù)要發(fā)的情況，如果第二、第三次揮手之間有數(shù)據(jù)要發(fā)，就不可能變成三次揮手了嗎？并不是。TCP中還有個特性叫延遲確認(rèn)?？梢院唵卫斫鉃椋?strong>接收方收到數(shù)據(jù)以后不需要立刻馬上回復(fù)ACK確認(rèn)包。在此基礎(chǔ)上，不是每一次發(fā)送數(shù)據(jù)包都能對應(yīng)收到一個ACK 確認(rèn)包，因為接收方可以合并確認(rèn)。而這個合并確認(rèn)，放在四次揮手里，可以把第二次揮手、第三次揮手，以及他們之間的數(shù)據(jù)傳輸都合并在一起發(fā)送。因此也就出現(xiàn)了三次揮手。TCP兩次揮手
前面在四次揮手中提到，關(guān)閉的時候雙方都發(fā)出了一個FIN和收到了一個ACK。正常情況下TCP連接的兩端，是不同IP 端口的進(jìn)程。但如果TCP連接的兩端，IP 端口是一樣的情況下，那么在關(guān)閉連接的時候，也同樣做到了一端發(fā)出了一個FIN，也收到了一個 ACK，只不過正好這兩端其實是同一個socket 。一個socket能建立連接？
上面提到了，同一個客戶端socket，自己對自己發(fā)起連接請求。是可以成功建立連接的。這樣的連接，叫TCP自連接。下面我們嘗試下復(fù)現(xiàn)。注意我是在以下系統(tǒng)進(jìn)行的實驗。在mac上多半無法復(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)"
通過nc命令可以很簡單的創(chuàng)建一個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
整個過程中，都沒有服務(wù)端參與?？梢宰€包看下。一端發(fā)出第一次握手后，如果又收到了第一次握手的SYN包，TCP連接狀態(tài)會怎么變化？
第一次握手過后，連接狀態(tài)就變成了SYN_SENT狀態(tài)。如果此時又收到了第一次握手的SYN包，那么連接狀態(tài)就會從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)會怎么變化？
第二握手過后，連接狀態(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了，此時如果再收到第二次握手的SYN ACK包。連接狀態(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);">ESTABLISHED。//?net/ipv4/tcp_input.c
int?tcp_rcv_state_process()
{
????//?前面省略很多邏輯，能走到這就認(rèn)為肯定有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)?{
????????//?狀態(tài)從?SYN_RCVD?轉(zhuǎn)為?ESTABLISHED
????????????????tcp_set_state(sk,?TCP_ESTABLISHED);
????????????}?
????????}
????}
}
一端第一次揮手后，又收到第一次揮手的包，TCP連接狀態(tài)會怎么變化？
第一次揮手過后，一端狀態(tài)就會變成FIN-WAIT-1。正常情況下，是要等待第二次揮手的ACK。但實際上卻等來了 一個第一次揮手的 FIN包， 這時候連接狀態(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);">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;
????}
}
這可以說是隱藏劇情了。CLOSING 很少見，除了出現(xiàn)在自連接關(guān)閉外，一般還會出現(xiàn)在TCP兩端同時關(guān)閉連接的情況下。處于CLOSING狀態(tài)下時，只要再收到一個ACK，就能進(jìn)入 TIME-WAIT 狀態(tài)，然后等個2MSL，連接就徹底斷開了。這跟正常的四次揮手還是有些差別的。大家可以滑到文章開頭的TCP四次揮手再對比下。代碼復(fù)現(xiàn)自連接
可能大家會產(chǎn)生懷疑，這是不是nc這個軟件本身的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)
//?...
無非就是以創(chuàng)建了一個客戶端socket句柄，然后對這個句柄執(zhí)行 bind, 綁定它的端口號是6666，然后再向 127.0.0.1:6666發(fā)起connect方法。我們可以嘗試用C語言去復(fù)現(xiàn)一遍。下面的代碼，只用于復(fù)現(xiàn)問題。直接跳過也完全不影響閱讀。#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,? 
下載文檔
