很多資料講了關(guān)于TCP的CLOSING和CLOSE_WAIT狀態(tài)以及所謂的優(yōu)雅關(guān)閉的細(xì)節(jié)，多數(shù)側(cè)重與Linux的內(nèi)核實(shí)現(xiàn)(除了《UNIX網(wǎng)絡(luò)編程》)。本文不注重代碼細(xì)節(jié)，只關(guān)注邏輯。所使用的工具，tcpdump，packetdrill以及ss。

關(guān)于ss可以先多說(shuō)幾句，它展示的信息跟netstat差不多，只不過(guò)更加詳細(xì)。netstat的信息是通過(guò)procfs獲取的，本質(zhì)上來(lái)講就是遍歷/proc/net/netstat文件的內(nèi)容，然后將其組織成可讀的形式展示出來(lái)，然而ss則可以針對(duì)特定的五元組信息提供更加詳細(xì)的內(nèi)容，它不再通過(guò)procfs，而是用過(guò)Netlink來(lái)提取特定socket的信息，對(duì)于TCP而言，它可以提取到甚至tcp_info這種詳細(xì)的信息，它包括cwnd，ssthresh，rtt，rto等。

本文展示的邏輯使用了以下三樣工具：

1).packetdrill

使用packetdrill構(gòu)造出一系列的包序列，使得TCP進(jìn)入CLOSING狀態(tài)或者CLOSE_WAIT狀態(tài)。

2).tcpdump/tshark

抓取packetdrill注入的數(shù)據(jù)包以及協(xié)議棧反饋的包，以確認(rèn)數(shù)據(jù)包序列確實(shí)如TCP標(biāo)準(zhǔn)所述的那樣。

3).ss/netstat

通過(guò)ss抓取packetdrill相關(guān)套接字的tcp_info，再次確認(rèn)細(xì)節(jié)。

我想，我使用上述的三件套解析了CLOSING狀態(tài)之后，接下來(lái)的CLOSE_WAIT狀態(tài)就可以當(dāng)作練習(xí)了。

我來(lái)一個(gè)一個(gè)說(shuō)。

1.關(guān)于CLOSING狀態(tài)

首先我來(lái)描述一下而不是細(xì)說(shuō)概念。

什么是CLOSING狀態(tài)呢？我們來(lái)看一下下面的局部狀態(tài)圖：

也就是說(shuō)，當(dāng)兩端都主動(dòng)發(fā)送FIN的時(shí)候，并且在收到對(duì)方對(duì)自己發(fā)送的FIN之前收到了對(duì)方發(fā)送的FIN的時(shí)候，兩邊就都進(jìn)入了CLOSING狀態(tài)，這個(gè)在狀態(tài)圖上顯示的很清楚。這個(gè)用俗話說(shuō)就是”同時(shí)關(guān)閉“。時(shí)序圖我就不給出了，請(qǐng)自行搜索或者自己畫(huà)。

有很多人都說(shuō)，這種狀態(tài)的TCP連接在系統(tǒng)中存在了好長(zhǎng)時(shí)間并百思不得其解。這到底是為什么呢？通過(guò)狀態(tài)圖和時(shí)序圖，我們知道，在進(jìn)入CLOSING狀態(tài)后，只要收到了對(duì)方對(duì)自己的FIN的ACK，就可以雙雙進(jìn)入TIME_WAIT狀態(tài)，因此，如果RTT處在一個(gè)可接受的范圍內(nèi)，發(fā)出的FIN會(huì)很快被ACK從而進(jìn)入到TIME_WAIT狀態(tài)，CLOSING狀態(tài)應(yīng)該持續(xù)的時(shí)間特別短。

以下是packetdrill腳本，很簡(jiǎn)單的一個(gè)腳本：

0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
0.000 bind(3, ..., ...) = 0
0.000 listen(3, 1) = 0

0.100 < S 0:0(0) win 32792 < mss 1460,sackOK,nop,nop,nop,wscale 7 >
0.100 > S. 0:0(0) ack 1 win 5840 < mss 1460,nop,nop,sackOK,nop,wscale 7 >
0.200 < . 1:1(0) ack 1 win 257
0.200 accept(3, ..., ...) = 4

// 象征性寫(xiě)入一些數(shù)據(jù)，裝的像一點(diǎn)一個(gè)正常的TCP連接：握手-傳輸-揮手
0.250 write(4, ..., 1000) = 1000

0.300 < . 1:1(0) ack 1001 win 257

// 主動(dòng)斷開(kāi)，發(fā)送FIN
0.400 close(4) = 0
// 在未對(duì)上述close的FIN進(jìn)行ACK前，先FIN
0.500 < F. 1:1(0) ack 1001 win 260
// 至此，成功進(jìn)入同時(shí)關(guān)閉的CLOSING狀態(tài)。

// 由于packetdrill不能用dup調(diào)用，也好用多線程，為了維持進(jìn)程不退出，只能等待
10000.000 close(4) = 0

同時(shí)，我啟用tcpdump抓包，確認(rèn)了TCP狀態(tài)圖的細(xì)節(jié)，即，還沒(méi)有收到對(duì)方對(duì)FIN的ACK時(shí)，收到了對(duì)方的FIN：

有個(gè)異常，沒(méi)有收到FIN的ACK(packetdrill沒(méi)有回復(fù)，這正常，因?yàn)槟_本里本來(lái)就沒(méi)有這個(gè)語(yǔ)句)，然而也沒(méi)有看到重傳，此時(shí)該連接應(yīng)該是處于CLOSING狀態(tài)了，用ss來(lái)確認(rèn)：

CLOSING 1 1 192.168.0.1:webcache 192.0.2.1:54442

cubic wscale:7,7 rto:2000 rtt:50/25 ssthresh:2 send 467.2Kbps rcv_space:5840

果然，進(jìn)入了CLOSING狀態(tài)且沒(méi)有消失，時(shí)不我待，當(dāng)過(guò)了2秒以后，ss的結(jié)果變成了：

CLOSING 1 1 192.168.0.1:webcache 192.0.2.1:54442

cubic wscale:7,7 rto:4000 rtt:50/25 ssthresh:2 send 467.2Kbps rcv_space:5840

明顯在退避！如果繼續(xù)觀察，你會(huì)發(fā)現(xiàn)rto退避到了64秒之多。在我的場(chǎng)景中，CLOSING狀態(tài)的套接字維持了兩分鐘之久。

然而，為什么呢？為什么CLOSING狀態(tài)會(huì)維持這么久？為什么它沒(méi)有繼續(xù)維持下去直到永久呢？

很明顯，一端的FIN發(fā)出去后，沒(méi)有收到ACK，因此會(huì)退避重發(fā)，知道4次退避，即22222*2秒之久?，F(xiàn)在的問(wèn)題是，為什么重發(fā)FIN始終不成功呢？要是成功了的話，估計(jì)ACK瞬間也就回來(lái)了，那么CLOSING狀態(tài)也就可以進(jìn)入TIME_WAIT了，但是沒(méi)有成功重傳FIN！

到此為止，我們知道，進(jìn)入CLOSING狀態(tài)之后，兩邊都會(huì)等待接收自己FIN的ACK，一旦收到ACK，就會(huì)進(jìn)入TIME_WAIT，如此反復(fù)，如果收不到ACK，則會(huì)不斷重傳FIN，直到忍無(wú)可忍，將socket銷毀。現(xiàn)在，我們集中于解釋為什么重傳沒(méi)有成功，但是請(qǐng)記住，并不是每次都這樣，只是在我這個(gè)packetdrill構(gòu)造的場(chǎng)景中會(huì)有重傳不成功，不然如果大概率不成功的話。豈不是每個(gè)CLOSING狀態(tài)都要維持很長(zhǎng)時(shí)間？？??！

在我的場(chǎng)景下，通過(guò)hook重傳函數(shù)以及抓包確認(rèn)，發(fā)現(xiàn)所有的重傳雖然退避了，但是都沒(méi)有真正將數(shù)據(jù)包發(fā)送出去，究其原因，最終確認(rèn)問(wèn)題出在以下代碼上：

if (atomic_read(&sk- >sk_wmem_alloc) >
    min(sk- >sk_wmem_queued + (sk- >sk_wmem_queued > > 2), sk- >sk_sndbuf))
    return -EAGAIN;

在Linux協(xié)議棧的實(shí)現(xiàn)中，tcp_retransmit_skb由tcp_retransmit_timer調(diào)用，即便是這里出了些問(wèn)題沒(méi)有重傳成功，也還是會(huì)退避的，退避超時(shí)到期后，繼續(xù)在這里出錯(cuò)，直到”不可容忍“銷毀socket。

我們可以得知，不管如何CLOSING狀態(tài)的TCP連接即便沒(méi)有收到對(duì)自己FIN的ACK，也不會(huì)永久保持下去，保持多久取決于自己發(fā)送FIN時(shí)刻的RTT，然后RTT計(jì)算出的RTO按照最大的退避次數(shù)來(lái)退避，直到最終執(zhí)行了固定次數(shù)的退避后，算出來(lái)的那個(gè)比較大的超時(shí)時(shí)間到期，然后TCP socket就銷毀了。

因此，CLOSING狀態(tài)并不可怕，起碼，不管怎樣，它有一個(gè)可控的銷毀時(shí)限。

...

現(xiàn)在我來(lái)解釋重傳不成功的細(xì)節(jié)。

我們知道，根據(jù)上述的代碼段，sk_wmem_alloc要足夠大，大到它比sk_wmem_queued+sk_wmem_queued/4更大的時(shí)候，才會(huì)返回錯(cuò)誤造成重傳不成功，然而我們的packetdrill腳本中構(gòu)造的TCP連接的生命周期中僅僅傳輸了1000個(gè)字節(jié)的數(shù)據(jù)，并且這1000個(gè)字節(jié)的數(shù)據(jù)得到了ACK，然后就結(jié)束了連接。一個(gè)socket保有一個(gè)sk_wmem_alloc字段，在skb交給這個(gè)socket的時(shí)候，該字段會(huì)增加skb長(zhǎng)度的大小(skb本身大小包括skb數(shù)據(jù)大小)，然而當(dāng)skb不再由該socket持有的時(shí)候，也就是其被更底層的邏輯接管之后，socket的sk_wmem_alloc字段自然會(huì)減去skb長(zhǎng)度的大小，這一切的過(guò)程由以下的函數(shù)決定，即skb_set_owner_w和skb_orphan。我們來(lái)看一下這兩個(gè)函數(shù)：

static inline void skb_set_owner_w(struct sk_buff *skb, struct sock *sk)
{
    skb_orphan(skb);
    skb- >sk = sk;
    // sock_wfree回調(diào)中會(huì)遞減sk_wmem_alloc相應(yīng)的大小，其大小就是skb- >truesize
    skb- >destructor = sock_wfree;
    /*
     * We used to take a refcount on sk, but following operation
     * is enough to guarantee sk_free() wont free this sock until
     * all in-flight packets are completed
     */
    atomic_add(skb- >truesize, &sk- >sk_wmem_alloc);
}
static inline void skb_orphan(struct sk_buff *skb)
{
    // 調(diào)用回調(diào)函數(shù)，遞減sk_wmem_alloc
    if (skb- >destructor)
        skb- >destructor(skb);
    skb- >destructor = NULL;
    skb- >sk        = NULL;
}

也就是說(shuō)，只要skb_orphan在skb通向網(wǎng)卡的路徑上被正確調(diào)用，就會(huì)保證sk_wmem_alloc的值隨著skb進(jìn)入socket的管轄時(shí)而增加，而被實(shí)際發(fā)出后而減少。但是根據(jù)我的場(chǎng)景，事實(shí)好像不是這樣，sk_wmem_alloc的值只要發(fā)送一個(gè)skb就會(huì)增加，絲毫沒(méi)有減少的跡象...這是為什么呢？

有的時(shí)候，當(dāng)你對(duì)某個(gè)邏輯理解足夠深入后，一定要相信自己的判斷，內(nèi)核存在BUG！內(nèi)核并不完美。我使用的是2.6.32老內(nèi)核，這個(gè)內(nèi)核我已經(jīng)使用了6年多，這是我在這個(gè)內(nèi)核上發(fā)現(xiàn)的第4個(gè)BUG了。

請(qǐng)注意，我的這個(gè)場(chǎng)景中，我使用了packetdrill來(lái)構(gòu)造數(shù)據(jù)包，而packetdrill使用了tun網(wǎng)卡。為什么使用真實(shí)網(wǎng)卡甚至使用loopback網(wǎng)卡就不會(huì)有問(wèn)題呢？這進(jìn)一步引導(dǎo)我去調(diào)查tun的代碼，果不其然，在其hard_xmit回調(diào)中沒(méi)有調(diào)用skb_orphan！也就說(shuō)說(shuō)，但凡使用2.6.32內(nèi)核版本tun驅(qū)動(dòng)的，都會(huì)遇到這個(gè)問(wèn)題呢。在tun的xmit中加入skb_orphan之后，問(wèn)題消失，抓包你會(huì)發(fā)現(xiàn)大量的FIN重傳包，這些重傳隨著退避而間隔加大(注意，用ss命令比對(duì)一下rto字段的值和tcpdump抓取的實(shí)際值)：

(為了驗(yàn)證這個(gè)，我修改了packetdrill腳本，中間增加了很多的數(shù)據(jù)傳輸，以便盡快重現(xiàn)sk_wmem_alloc在使用tun時(shí)不遞減的問(wèn)題)于是，我聯(lián)系了前公司的同事，讓他們修改OpenVPN使用的tun驅(qū)動(dòng)代碼，因?yàn)楫?dāng)時(shí)確實(shí)出現(xiàn)過(guò)關(guān)于TCP使用OpenVPN隧道的重傳問(wèn)題，然而，得到的答復(fù)卻是，xmit函數(shù)中已經(jīng)有skb_orphan了...然后我看了下代碼，發(fā)現(xiàn)，公司的代碼已經(jīng)不存在問(wèn)題了，因?yàn)槲以谇澳旮鉻un多隊(duì)列的時(shí)候，已經(jīng)移植了3.9.6的tun驅(qū)動(dòng)，這個(gè)問(wèn)題已經(jīng)被修復(fù)。

自己曾經(jīng)做的事情，已然不再憶起...

2.關(guān)于CLOSE_WAIT狀態(tài)

和CLOSING狀態(tài)不同，CLOSE_WAIT狀態(tài)可能會(huì)持續(xù)更久更久的時(shí)間，導(dǎo)致無(wú)用的socket無(wú)法釋放，這個(gè)時(shí)間可能與應(yīng)用進(jìn)程的生命周期一樣久！

我們先看一下CLOSE_WAIT的局部狀態(tài)圖。

然后我來(lái)構(gòu)造一個(gè)packetdrill腳本：

0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
0.000 bind(3, ..., ...) = 0
0.000 listen(3, 1) = 0

0.100 < S 0:0(0) win 32792 < mss 1460,sackOK,nop,nop,nop,wscale 7 >
0.100 > S. 0:0(0) ack 1 win 14600 < mss 1460,nop,nop,sackOK,nop,wscale 7 >
0.200 < . 1:1(0) ack 1 win 257
0.200 accept(3, ..., ...) = 4
// 什么也不發(fā)了，直接斷開(kāi)
0.350 < F. 1:1(0) ack 1 win 260
// 協(xié)議棧會(huì)對(duì)這個(gè)FIN進(jìn)行ACK，然則應(yīng)用程序不關(guān)閉連接的話...
//0.450 close(4) = 0
// 該連接就會(huì)變成CLOSE_WAIT，并且只要其socket引用計(jì)數(shù)不為0，就一直僵死在那里
2000.000 close(4) = 0

同樣的，我來(lái)展示抓包結(jié)果：

最后，和描述CLOSING狀態(tài)不同的是，隔了N個(gè)小時(shí)之后，我來(lái)看ss -ip的結(jié)果：

CLOSE-WAIT 1 0 192.168.0.1:webcache 192.0.2.1:53753 users:(("ppp",2399,8))

cubic wscale:7,7 rto:300 rtt:100/50 ato:40 cwnd:10 send 1.2Mbps rcv_space:14600

這個(gè)CLOSE_WAIT還在！這是為什么呢？

很遺憾，上述的packetdrill腳本并不能直觀地展示這個(gè)現(xiàn)象，還得靠我說(shuō)一說(shuō)。

CLOSE_WAIT是一端在收到FIN之后，發(fā)送自己的FIN之前所處的狀態(tài)，那么很顯然，如果一個(gè)進(jìn)程/線程始終不發(fā)送FIN，那么在該連接所隸屬的socket的生命周期內(nèi)，這個(gè)socket就會(huì)一直存在，我們知道，在UNIX/Linux/WinSock中，socket作為一個(gè)描述符出現(xiàn)，只要進(jìn)程/線程繼續(xù)持有它，它就會(huì)一直存在，因此大多數(shù)情況下進(jìn)程/線程的生命周期內(nèi)，此TCP套接字就會(huì)始終處在CLOSE_WAIT狀態(tài)。進(jìn)程/線程長(zhǎng)時(shí)間持有不需要的socket描述符，更多的并不是有意的，而是在進(jìn)行諸如fork/clone之類的系統(tǒng)調(diào)用后，dup了父親的文件描述符，然后在孩子那里又沒(méi)有及時(shí)關(guān)閉，另外的原因就是編程者對(duì)socket描述符的close接口以及shutdown接口不是很理解了。

現(xiàn)在，我們用一個(gè)問(wèn)題來(lái)繼續(xù)我們的討論。

什么時(shí)候進(jìn)程在超長(zhǎng)的生命周期內(nèi)不會(huì)如愿關(guān)閉TCP從而發(fā)送FIN呢？

我的答案比較直接：不能指望close會(huì)發(fā)送FIN！

相信很多人在想斷開(kāi)一個(gè)TCP連接的時(shí)候，都會(huì)調(diào)用close吧。并且這種做法幾乎都是正確的，以至于很多人都把這作為一種標(biāo)準(zhǔn)的做法。但是這是不對(duì)的！Why？！在《UNIX網(wǎng)絡(luò)編程》中，曾經(jīng)提到了所謂的”優(yōu)雅關(guān)閉TCP連接“，何謂優(yōu)雅？？！如果你充分理解close，shutdown，應(yīng)該就會(huì)知道，CLOSE_WAIT出現(xiàn)，你應(yīng)該可以給出一些解釋。

close調(diào)用

close的參數(shù)只是一個(gè)文件描述符號(hào)，它不理解這個(gè)文件真正的細(xì)節(jié)，它只是一個(gè)文件系統(tǒng)內(nèi)范疇的一個(gè)調(diào)用，它只是關(guān)閉文件描述符，保證此進(jìn)程不會(huì)在讀取它而已。如果你關(guān)閉了文件描述符4，即close(4)，你知道4代表的文件會(huì)作何反應(yīng)嗎？？文件系統(tǒng)并不知道4號(hào)描述符代表的文件到底是什么，更不知道有多少進(jìn)程共享這個(gè)底層的”實(shí)體“，所以一個(gè)進(jìn)程層面上邏輯根本沒(méi)有權(quán)力去徹底關(guān)閉一個(gè)socket。如果你想了解close的細(xì)節(jié)，更應(yīng)該去看看UNIX文件抽象或者文件系統(tǒng)的細(xì)節(jié)，而不是socket。請(qǐng)參見(jiàn)位于fs/open.c中的：

SYSCALL_DEFINE1(close, unsigned int, fd)
{
    ...
    fdt = files_fdtable(files);
    ...
    filp = fdt- >fd[fd];
    ...
    retval = filp_close(filp, files);
    ...
    return retval;
    ...
}
EXPORT_SYMBOL(sys_close);

在filp_close中會(huì)有fput調(diào)用：

void fput(struct file *file)
{
    if (atomic_long_dec_and_test(&file- >f_count))
        __fput(file);
}

看到那個(gè)引用計(jì)數(shù)了嗎？只有當(dāng)這個(gè)文件的引用計(jì)數(shù)變成0的時(shí)候，才會(huì)調(diào)用底層的關(guān)閉邏輯，對(duì)于socket而言，如果仍然還有一個(gè)進(jìn)程或者線程持有這個(gè)socket對(duì)應(yīng)的文件系統(tǒng)的描述符，那么即便你調(diào)用了close，也不會(huì)進(jìn)入了socket的close邏輯，它在文件系統(tǒng)層面就返回了！

shutdown調(diào)用

這個(gè)才是真正關(guān)閉一個(gè)TCP連接的調(diào)用！shutdown并沒(méi)有文件系統(tǒng)的語(yǔ)義，它專門(mén)針對(duì)內(nèi)核層的TCP socket。因此，調(diào)用shutdown的邏輯，才是真正關(guān)閉了與之共享信道的tcp socket。

所謂的優(yōu)雅關(guān)閉，就是在調(diào)用close之前， 首先自己調(diào)用shutdown(RD or WD)。這樣的時(shí)序才是關(guān)閉TCP的必由之路！

如果你想優(yōu)雅關(guān)閉一個(gè)TCP連接，請(qǐng)先用shutdown，然后后面跟一個(gè)close。不過(guò)有點(diǎn)詭異的是，Linux的shutdown(SHUT_RD)貌似沒(méi)有任何效果，不過(guò)這無(wú)所謂了，本來(lái)對(duì)于讀不讀的，就不屬于TCP的范疇，只有SHUT_WR才會(huì)實(shí)際發(fā)送一個(gè)FIN給對(duì)方。