天天看點
傳回

close和shutdown差別

原文：http://lib.csdn.net/article/computernetworks/17264

TCP連接配接的關閉有兩個方法close和shutdown，這篇文章将盡量精簡的說明它們分别做了些什麼。

為友善閱讀，我們可以帶着以下5個問題來閱讀本文：

1、當socket被多程序或者多線程共享時，關閉連接配接時有何差別？

2、關連接配接時，若連接配接上有來自對端的還未處理的消息，會怎麼處理？

3、關連接配接時，若連接配接上有本程序待發送卻未來得及發送出的消息，又會怎麼處理？

4、so_linger這個功能的用處在哪？

5、對于監聽socket執行關閉，和對處于ESTABLISH這種通訊的socket執行關閉，有何差別？

下面分三部分進行：首先說說多線程多程序關閉連接配接的差別；再用一幅流程圖談談close；最後用一幅流程圖說說shutdown。

先不提其原理和實作，從多程序、多線程下 close和shutdown方法調用時的差別說起。

看看close與shutdown這兩個系統調用對應的核心函數：（參見unistd.h檔案）

  1. <span style="font-size:18px;">#define __NR_close 3

  2. __SYSCALL(__NR_close, sys_close)

  3. #define __NR_shutdown 48

  4. __SYSCALL(__NR_shutdown, sys_shutdown)</span>

但sys_close和sys_shutdown這兩個系統調用最終是由tcp_close和tcp_shutdown方法來實作的，調用過程如下圖所示：

close和shutdown差別

sys_shutdown與多線程和多程序都沒有任何關系，而sys_close則不然，上圖中可以看到，層層封裝調用中有一個方法叫fput，它有一個引用計數，記錄這個socket被引用了多少次。在說明多線程或者多程序調用close的差別前，先在代碼上簡單看下close是怎麼調用的，對核心代碼沒興趣的同學可以僅看fput方法：

  1. <span style="font-size:18px;">void fastcall fput(struct file *file)

  2. {

  3. if (atomic_dec_and_test(&file->f_count))//檢查引用計數，直到為0才會真正去關閉socket

  4. __fput(file);

  5. }

  6. </span>

當這個socket的引用計數f_count不為0時，是不會觸發到真正關閉TCP連接配接的tcp_close方法的。

那麼，這個引用計數的意義何在呢？為了說明它，先要說道下程序與線程的差別。

大家知道，所謂線程其實就是“輕量級”的程序。建立程序隻能是一個程序（父程序）建立另一個程序（子程序），子程序會複制父程序的資源，這裡的”複制“針對不同的資源其意義是不同的，例如對記憶體、檔案、TCP連接配接等。建立程序是由clone系統調用實作的，而建立線程時同樣也是clone實作的，隻不過clone的參數不同，其行為也很不同。這個話題是很大的，這裡我們僅讨論下TCP連接配接。

在clone系統調用中，會調用方法copy_files來拷貝檔案描述符（包括socket）。建立線程時，傳入的flag參數中包含标志位CLONE_FILES，此時，線程将會共享父程序中的檔案描述符。而建立程序時沒有這個标志位，這時，會把程序打開的所有檔案描述符的引用計數加1，即把file資料結構的f_count成員加1，如下：

  1. <span style="font-size:18px;">static int copy_files(unsigned long clone_flags, struct task_struct * tsk)

  2. {

  3. if (clone_flags & CLONE_FILES) {

  4. goto out;//建立線程

  5. }

  6. newf = dup_fd(oldf, &error);

  7. out:

  8. return error;

  9. }</span>

再看看dup_fd方法：

  1. <span style="font-size:18px;">static struct files_struct *dup_fd(struct files_struct *oldf, int *errorp)

  2. {

  3. for (i = open_files; i != 0; i--) {

  4. struct file *f = *old_fds++;

  5. if (f) {

  6. get_file(f);//建立程序

  7. }

  8. }

  9. }</span>

get_file宏就會加引用計數。

<span style="font-size:18px;">#define get_file(x)	atomic_inc(&(x)->f_count)</span>

是以，子程序會将父程序中已經建立的socket加上引用計數。當程序中close一個socket時，隻會減少引用計數，僅當引用計數為0時才會觸發tcp_close。

到這裡，對于第一個問題的close調用自然有了結論：單線程（程序）中使用close與多線程中是一緻的，但這兩者與多程序的行為并不一緻，多程序中共享的同一個socket必須都調用了close才會真正的關閉連接配接。

而shutdown則不然，這裡是沒有引用計數什麼事的，隻要調用了就會去試圖按需關閉連接配接。是以，調用shutdown與多線程、多程序無關。

下面我們首先深入探讨下close的行為，因為close比較shutdown來說要複雜許多。順便回答其餘四個問題。

TCP連接配接是一種雙工的連接配接，何謂雙工？即連接配接雙方可以并行的發送或者接收消息，而無須顧及對方此時到底在發還是收消息。這樣，關閉連接配接時，就存在3種情形：完全關閉連接配接；關閉發送消息的功能；關閉接收消息的功能。其中，後兩者就叫做半關閉，由shutdown實作（是以 shutdown多出一個參數正是控制關閉發送或者關閉接收），前者由close實作。

TCP連接配接是一種可靠的連接配接，在這裡可以這麼了解：既要确認本機發出的包得到确認，又要确認收到的任何消息都已告知連接配接的對端。

以下主要從雙工、可靠性這兩點上了解連接配接的關閉。

TCP雙工的這個特性使得連接配接的正常關閉需要四次握手，其含義為：主動端關閉了發送的功能；被動端認可；被動端也關閉了發送的功能；主動端認可。

但還存在程式異常的情形，此時，則通過異常的那端發送RST複位封包通知另一端關閉連接配接。

下圖是close的主要流程：

close和shutdown差別

這個圖稍複雜，這是因為它覆寫了關閉監聽句柄、關閉普通連接配接、關閉設定了SO_LINGER的連接配接這三種主要場景。

1）關閉監聽句柄

先從最右邊的分支說說關閉監聽socket的那些事。用于listen的監聽句柄也是使用close關閉，關閉這樣的句柄含義當然很不同，它本身并不對應着某個TCP連接配接，但是，附着在它之上的卻可能有半成品連接配接。什麼意思呢？之前說過TCP是雙工的，它的打開需要三次握手，三次握手也就是3個步驟，其含義為：用戶端打開接收、發送的功能；伺服器端認可并也打開接收、發送的功能；用戶端認可。當第1、2步驟完成、第3步步驟未完成時，就會在伺服器上有許多半連接配接，close這個操作主要是清理這些連接配接。

參照上圖，close首先會移除keepalive定時器。keepalive功能常用于伺服器上，防止僵死、異常退出的用戶端占用伺服器連接配接資源。移除此定時器後，若ESTABLISH狀态的TCP連接配接在tcp_keepalive_time時間（如伺服器上常配置為2小時）内沒有通訊，伺服器就會主動關閉連接配接。

接下來，關閉每一個半連接配接。如何關閉半連接配接？這時當然不能發FIN包，即正常的四次握手關閉連接配接，而是會發送RST複位标志去關閉請求。處理完所有半打開的連接配接close的任務就基本完成了。

2）關閉普通ESTABLISH狀态的連接配接（未設定so_linger）

首先檢查是否有接收到卻未處理的消息。

如果close調用時存在收到遠端的、沒有處理的消息，這時根據close這一行為的意義，是要丢棄這些消息的。但丢棄消息後，意味着連接配接遠端誤以為發出的消息已經被本機收到處理了（因為ACK包确認過了），但實際上确是收到未處理，此時也不能使用正常的四次握手關閉，而是會向遠端發送一個RST非正常複位關閉連接配接。這個做法的依據請參考draft-ietf-tcpimpl-prob-03.txt文檔3.10節，Failure to RST on close with data pending。是以，這也要求我們程式員在關閉連接配接時，要確定已經接收、處理了連接配接上的消息。

如果此時沒有未處理的消息，那麼進入發送FIN來關閉連接配接的階段。

這時，先看看是否有待發送的消息。前一篇已經說過，發消息時要計算滑動視窗、擁塞視窗、angle算法等，這些因素可能導緻消息會延遲發送的。如果有待發送的消息，那麼要盡力保證這些消息都發出去的。是以，會在最後一個封包中加入FIN标志，同時，關閉用于減少網絡中小封包的angle算法，向連接配接對端發送消息。如果沒有待發送的消息，則構造一個封包，僅含有FIN标志位，發送出去關閉連接配接。

3）使用了so_linger的連接配接

首先要澄清，為何要有so_linger這個功能？因為我們可能有強可靠性的需求，也就是說，必須確定發出的消息、FIN都被對方收到。例如，有些響應發出後調用close關閉連接配接，接下來就會關閉程序。如果close時發出的消息其實丢失在網絡中了，那麼，程序突然退出時連接配接上發出的RST就可能被對方收到，而且，之前丢失的消息不會有重發來保障可靠性了。

so_linger用來保證對方收到了close時發出的消息，即，至少需要對方通過發送ACK且到達本機。

怎麼保證呢？等待！close會阻塞住程序，直到确認對方收到了消息再傳回。然而，網絡環境又得複雜的，如果對方總是不響應怎麼辦？是以還需要l_linger這個逾時時間，控制close阻塞程序的最長時間。注意，務必慎用so_linger，它會在不經意間降低你程式中代碼的執行速度（close的阻塞）。

是以，當這個程序設定了so_linger後，前半段依然沒變化。檢查是否有未讀消息，若有則發RST關連接配接，不會觸發等待。接下來檢查是否有未發送的消息時與第2種情形一緻，設好FIN後關閉angle算法發出。接下來，則會設定最大等待時間l_linger，然後開始将程序睡眠，直到确認對方收到後才會醒來，将控制權交還給使用者程序。

這裡需要注意，so_linger不是確定連接配接被四次握手關閉再使close傳回，而隻是保證我方發出的消息都已被對方收到。例如，若對方程式寫的有問題，當它收到FIN進入CLOSE_WAIT狀态，卻一直不調用close發出FIN，此時，對方仍然會通過ACK确認，我方收到了ACK進入FIN_WAIT2狀态，但沒收到對方的FIN，我方的close調用卻不會再阻塞，close直接傳回，控制權交還使用者程序。

從上圖可知，so_linger還有個偏門的用法，若l_linger逾時時間竟被設為0，則不會觸發FIN包的發送，而是直接RST複位關閉連接配接。我個人認為，這種玩法确沒多大用處。

最後做個總結。調用close時，可能導緻發送RST複位關閉連接配接，例如有未讀消息、打開so_linger但l_linger卻為0、關閉監聽句柄時半打開的連接配接。更多時會導緻發FIN來四次握手關閉連接配接，但打開so_linger可能導緻close阻塞住等待着對方的ACK表明收到了消息。

最後來看看較為簡單的shutdown。

close和shutdown差別

解釋下上圖：

1）shutdown可攜帶一個參數，取值有3個，分别意味着：隻關閉讀、隻關閉寫、同時關閉讀寫。

對于監聽句柄，如果參數為關閉寫，顯然沒有任何意義。但關閉讀從某方面來說是有意義的，例如不再接受新的連接配接。看看最右邊藍色分支，針對監聽句柄，若參數為關閉寫，則不做任何事；若為關閉讀，則把端口上的半打開連接配接使用RST關閉，與close如出一轍。

2）若shutdown的是半打開的連接配接，則發出RST來關閉連接配接。

3）若shutdown的是正常連接配接，那麼關閉讀其實與對端是沒有關系的。隻要本機把接收掉的消息丢掉，其實就等價于關閉讀了，并不一定非要對端關閉寫的。實際上，shutdown正是這麼幹的。若參數中的标志位含有關閉讀，隻是辨別下，當我們調用read等方法時這個辨別就起作用了，會使程序讀不到任何資料。

4）若參數中有标志位為關閉寫，那麼下面做的事與close是一緻的：發出FIN包，告訴對方，本機不會再發消息了。

以上，就是close與shutdown的主要行為，同時也回答了本文最初的5個問題。下一篇，我們開始讨論多路複用中常見的epoll。

Linux close shutdown
上一篇: java close_Java PushbackReader close()方法
下一篇: socket 程式設計 ： shutdown vs close

繼續閱讀