socket中close和shutdown的區(qū)別

seufy88

這兩個(gè)的區(qū)別在網(wǎng)上都有好多文章.
只是我還是有不明點(diǎn).所以想請教一下大家.

這里不考慮多進(jìn)程共享socket id這種情況.
單純的討論.

close (socket id): 馬上發(fā)送FIN信號，所有的未完成發(fā)送或者接受的數(shù)據(jù)都將被丟失
close成功后,對這個(gè)socket id進(jìn)行read/write都將失敗.
但是從TCP層面將,close只是能控制本方發(fā)送FIN到對方,并不能控制對方何時(shí)發(fā)送FIN過來.
請問在這種情況下,如果對方還發(fā)data過來,本方的TCP層還會發(fā)送ack of data給對方嗎?
      本方                  對方
       |                        |
close|-------FIN----->|
       |<--- ack of FIN -|
       |                        |
       |<----data ------ |
       |---ack of data -->|?????

在這種情況下,如果對方還發(fā)送data(而不是FIN)過來,本方是否直接返回RST?

shutdown (socket id):如果關(guān)閉寫，如果輸出緩沖區(qū)內(nèi)有數(shù)據(jù)，則所有的數(shù)據(jù)將發(fā)送出去后將發(fā)送一個(gè)FIN信號
如果關(guān)閉寫,則對這個(gè)socket的后續(xù)write會失敗,但是允許后續(xù)對這個(gè)socket進(jìn)行read.

本方                  對方
|                        |
|-------FIN----->|
|<--- ack of FIN -|
|                        |
|<----data ------ |
|---ack of data -->|


========
close,shutdown都會在TCP層面主動(dòng)發(fā)送FIN
但是這些都只是local側(cè)的,并不能掌控對方側(cè)的行為(是繼續(xù)發(fā)data還是發(fā)送FIN)
在這種情況下,我們local側(cè)分別在使用close,shutdown后,如果對方側(cè)仍有data發(fā)送過來,是否會有不同的操作?
已知的是shutdown之后,如果對方側(cè)仍有data到達(dá),則local側(cè)可以發(fā)送回ack of data
但是close的情況又是怎么樣的呢?

timespace

一言難盡，也不用網(wǎng)上怎么搜，找到UNPv1（UNIX網(wǎng)絡(luò)編程第一卷），專門有講這個(gè)問題的章節(jié)，看完就沒疑問了。

seufy88

回復(fù) 2# timespace
小弟有空會去看.
本人并不是究結(jié)于close ,shutdown這樣的API
而是對下面的TCP實(shí)現(xiàn)有點(diǎn)疑問.


   

gaojl0728

close和shutdown的行為取決于內(nèi)核的實(shí)現(xiàn)。
1. close調(diào)用之后如果在local TCP buffer內(nèi)如果還有數(shù)據(jù)沒有讀取會給對方直接回RST, 否則發(fā)送FIN,這取決于調(diào)用close時(shí)刻local TCP buffer的狀態(tài)， 跟對端是不是繼續(xù)發(fā)送數(shù)據(jù)無關(guān)。
2. shutdown關(guān)閉讀不會給對方發(fā)FIN, 只有關(guān)閉寫才會發(fā)FIN, 而且跟local TCP buffer狀態(tài)沒關(guān)系，只發(fā)送FIN包，從不發(fā)送RST

seufy88

gaojl0728 發(fā)表于 2014-04-02 10:12
close和shutdown的行為取決于內(nèi)核的實(shí)現(xiàn)。
1. close調(diào)用之后如果在local TCP buffer內(nèi)如果還有數(shù)據(jù)沒有讀取 ...

恩，我之前沒說明白，這里的shutdown特指W，會發(fā)送FIN。這個(gè)本人能夠理解。

1. close調(diào)用之后如果在local TCP buffer內(nèi)如果還有數(shù)據(jù)沒有讀取會給對方直接回RST, 否則發(fā)送FIN,這取決于調(diào)用close時(shí)刻local TCP buffer的狀態(tài)， 跟對端是不是繼續(xù)發(fā)送數(shù)據(jù)無關(guān)
=》如果close造成的是發(fā)送FIN，在這之后，對方繼續(xù)發(fā)送data 過來的話呢？
按照底層TCP協(xié)議，local側(cè)是否繼續(xù)發(fā)送ack of data給對方，直到local側(cè)buffer滿了
因?yàn)門CP兩方的通信通道，local側(cè)永遠(yuǎn)只能掌控local側(cè)出去的方向，不能控制對方側(cè)繼續(xù)發(fā)送數(shù)據(jù)。即在FIN_WAIT2狀態(tài)時(shí)，local側(cè)依然可以接收對方的data

調(diào)用close,shutdown，內(nèi)核側(cè)做了不同的guard工作：
對socket繼續(xù)read的話，
close之后不允許讀取對方來的數(shù)據(jù)，shutdown之后還是允許繼續(xù)讀取。

之前提到調(diào)用clsoe會關(guān)閉bidirection,這里所謂的關(guān)閉bidirection其實(shí)是否是內(nèi)核自己提供的guard動(dòng)作，和TCP協(xié)議本身“不一致”
因?yàn)閺腡CP層面看，一方發(fā)送FIN到對方后，并不能真正關(guān)閉bidirection，需要對方也發(fā)送FIN之后，TCP connection才算真正關(guān)閉bidirection

不知道我的想法是否有誤？

timespace

回復(fù) 3# seufy88
如果是看API，我肯定推薦man shutdown或man close，既然是看書，那就不全是API的事情，網(wǎng)絡(luò)API才有幾個(gè)，值得UNPv1用近千頁的篇幅來論述？UNPv1講解API的同時(shí)，會有大量TCP/IP方面的解釋，以助于理解本質(zhì)問題，作者寫TCP/IP詳解三卷的功力也體現(xiàn)在UNPv1中。
你的問題不外乎就是shutdown/close/SO_LINGER三者的功能與區(qū)別，看完SO_LINGER就解釋你剩下的疑問了。



   

timespace

不過多數(shù)來論壇提問的人是沒耐心看書的，簡單說下我的理解：

首先，close對TCP協(xié)議棧的影響可以由setsockopt(SOL_SOCKET, SO_LINGER, struct linger *optval; socklen_t optlen)控制。
struct linger {
    int onoff; /* 0=off, nonzero=on */
    int l_linger; /* linger time, POSIX specifies units as seconds */
};

但是從TCP層面將,close只是能控制本方發(fā)送FIN到對方,并不能控制對方何時(shí)發(fā)送FIN過來.
請問在這種情況下,如果對方還發(fā)data過來,本方的TCP層還會發(fā)送ack of data給對方嗎?

1. close后，默認(rèn)情況與使用l_onoff=0效果一致，本方繼續(xù)接收數(shù)據(jù)并ACK，但會丟棄這些數(shù)據(jù)，直到對方FIN過來，完成連接終止過程；
2. close后，l_onoff非0且l_linger=0，立即丟棄發(fā)送緩存區(qū)數(shù)據(jù)并給對方發(fā)送一個(gè)RST，也就是不會有正常的四分組終止過程，也沒有TIME_WAIT，對方收到RST后，肯定不能繼續(xù)發(fā)數(shù)據(jù)了；
3. close后，l_onoff非0且l_linger>0，close會等待l_linger（阻塞情況下），如果數(shù)據(jù)發(fā)完，執(zhí)行#1，否則執(zhí)行#2；
靈活運(yùn)用上面三種方式，本地socket足以應(yīng)付不知進(jìn)退的對方socket，排除共享fd和關(guān)閉fd問題外，close相當(dāng)于shutdown(fd, SHUT_RDWR)。

gaojl0728

回復(fù) 5# seufy88


看了下linux-3.12.6的實(shí)現(xiàn)，內(nèi)核的實(shí)現(xiàn)還是有點(diǎn)小復(fù)雜的。

1. close調(diào)用因?yàn)闀�關(guān)閉文件句柄， 因此close之后既不能讀也不能繼續(xù)寫，shutdown_write之后句柄還在，還能繼續(xù)讀
2. 調(diào)用close和shutdown_write效果是一樣的，都會給對方發(fā)送FIN， local端進(jìn)入FIN_WAIT1， 之后能和等待對端回復(fù)ACK,
    (1)如果此后收到的是不帶ACK純數(shù)據(jù)包， 內(nèi)核會暴力回復(fù)RST, 所以一種可能的情況就是雖然我調(diào)的是shutdown_write, 但最終雙向都關(guān)閉了，因?yàn)榫W(wǎng)絡(luò)中的包很難說什么時(shí)候到達(dá)。
    (2)如果此后收到的是帶ACK的純數(shù)據(jù)包，會有所不同,
        a. 如果前面是close調(diào)用， local端進(jìn)入FIN_WAIT2， 同時(shí)啟動(dòng)time wait定期器，最終會關(guān)閉local端的TCP鏈接.
        b. 如果前面是shutdown_write, 數(shù)據(jù)會進(jìn)入local TCP buffer， 上層應(yīng)用可以繼續(xù)收數(shù)據(jù)。
3. close對于local端來說是bidirection， 但對于對端來說是unidirection的， 對端根本就不知道你本端是close還是shutdown_write， 對端可以選擇不close socket, 繼續(xù)發(fā)送數(shù)據(jù)，這就會觸發(fā)上面的第2條的邏輯，對端會收到RST， 對端的內(nèi)核會關(guān)閉TCP鏈接。
4. 以上討論忽略了linger選項(xiàng)，如果加上他就更復(fù)雜了。

gaojl0728

回復(fù) 7# timespace


    我給你糾正一下， 第2條，
close后，l_onoff非0且l_linger=0， 只有在此時(shí)TCP的讀隊(duì)列沒有數(shù)據(jù)的情況下， 才會暴力發(fā)送RST， 否則內(nèi)核還是會四次握手的。

timespace

回復(fù) 9# gaojl0728
多謝糾正。沒研究過內(nèi)核源碼，不過有個(gè)疑問，close后，l_onoff非0且l_linger=0，如果本地TCP讀取隊(duì)列有數(shù)據(jù)且內(nèi)核不RST，內(nèi)核會逐步丟掉這些數(shù)據(jù)，一旦對方不發(fā)FIN，怎么終止連接？FIN_WAIT_2有超時(shí)？