說到tcp協議，凡是稍微看過的人都能順口說出三次握手和四次斷連，再牛逼的一點的就能夠把每個狀態（SYNC_SENT、CLOSE_WAIT。。。。。。等）都能背出來，

而說道socket程式設計，基本上寫過網路程式設計的人都會熟悉那幾個標準的API：socket、connect、listen、accept。。。。。。等

但是，我敢打賭很少有人明白tcp狀態和socket程式設計API之間的關係。不信？ 看看如下幾個問題你是否知道吧：

1）什麼時候客戶端才能夠連線上server端， 是server端呼叫bind後還是listen後還是accept後 ？

2）什麼情況下會出現FIN_WAIT_2狀態

。。。。。。。。。。。。。。。。。。。。。

本週打破砂鍋問到底的精神以及實事求是的精神，我用python指令碼寫了一些指令碼測試這些情況，看完後你一定會大呼過癮，對tcp的協議和socket程式設計的理解又更上層樓。

注：以下測試是在Linux（2.6.18）平臺上用python（2.7）指令碼測試，其它平臺沒有測試，有興趣可以自己測試一下。

【連線過程測試和驗證】

第1種情況：client呼叫connect，server只是呼叫了socket + bind，沒有呼叫listen

tcpdump抓包如下：

抓包結果顯示：server端直接回復了RST包

此時使用netstat或者ss命令去檢視，無論是client還是server，都查不到連線

第2種情況：client呼叫connect，server呼叫了socket + bind + listen

tcpdump抓包如下：

抓包結果顯示：三次握手完成

使用ss工具去檢視，client和server都顯示ESTAB

[[email protected] ~]$ ss  -t -n | grep 50000
ESTAB      0      0                10.1.73.45:55354           10.1.73.76:50000 

tcpdump抓包如下：

抓包結果顯示：三次握手完成，並且雙方都可以傳送和接受資料了

使用ss工具去檢視，client和server都顯示ESTAB

[[email protected] ~]$ ss  -t -n | grep 50000
ESTAB      0      0                10.1.73.45:41363           10.1.73.76:50000 

1）可以看到，只有當server端listen之後，client端呼叫connect才能成功，否則就會返回RST響應拒絕連線

2）只有當accept後，client和server才能呼叫recv和send等io操作

3）socket API呼叫錯誤不會導致client出現SYN_SENT狀態，那麼只能是網路裝置丟包（路由器、防火牆）才會導致SYNC_SENT狀態

【斷連過程測試和總結】

第1種情況：client呼叫close，但server沒有呼叫close

tcpdump抓包如下：

抓包結果顯示：client傳送了fin包，server端應答了ack包

使用ss工具去檢視，client顯示FIN_WAIT_2狀態：

[[email protected] ~]$ ss  -t -n | grep "10.1.73.76:50000"
FIN-WAIT-2 0      0                10.1.73.45:47630           10.1.73.76:50000

[[email protected]_test ~]$ ss  -t -n | grep 50000
CLOSE-WAIT 1      0                10.1.73.76:50000           10.1.73.45:47630 

原因在於Linux系統核心中有一個引數可以控制FIN_WAIT_2的時間：tcp_fin_timeout

第2種情況：client呼叫close，server呼叫close

tcpdump抓包如下：

抓包結果顯示：熟悉的四次斷連來啦

使用ss工具去檢視，client顯示TIME-WAIT狀態

[[email protected] ipv4]$ ss -a -n | grep 50000
TIME-WAIT  0      0                10.1.73.45:39751           10.1.73.76:50000 

第3種情況：server端被kill了

tcpdump抓包如下：

抓包結果顯示：熟悉的四次斷連來啦

咦，怎麼會和正常的server close一樣呢？答案就在於作業系統的實現：

close函式其實本身不會導致tcp協議棧立刻傳送fin包，而只是將socket檔案的引用計數減1，當socket檔案的引用計數變為0的時候，作業系統會自動關閉tcp連線，此時才會傳送fin包。

這也是多程序程式設計需要特別注意的一點，父程序中一定要將socket檔案描述符close，否則執行一段時間後就可能會出現作業系統提示too many open files

第4種情況：client端呼叫shutdown操作

shutdown操作有三種關閉方式：SHUT_RD、SHUT_WR、SHUT_RDWR，分別測試後發現有趣的現象。

1）如果是SHUT_RD，則tcpdump抓包發現沒有傳送任何包；

2）如果是SHUT_WR或者SHUT_RDWR，則client會發送FIN包給server，

    若server收到後執行close操作，則server傳送FIN給client，最終連線被關閉。

SHUT_WR或者SHUT_RDWR抓包顯示如下：

使用ss命令檢視，client顯示如下：

[[email protected] ~]$ ss -a | grep 50000
TIME-WAIT  0      0              10.1.73.45:45641           10.1.73.76:50000 

關於shutdown的詳細解釋可以參考：http://www.gnu.org/software/libc/manual/html_node/Closing-a-Socket.html

歸納一下SHUT_RD的處理：

1）client端不再接收資料，如果有新的資料到來，直接丟棄(reject)

2）沒有傳送任何tcp包，所以server端並不知道這個狀態，server端可以繼續傳送資料，但由於1）的原因，發了也白髮

歸納一下SHUT_WR或者SHUT_RDWR的處理：

1）停止傳送資料（不能再呼叫write操作），丟棄緩衝區中未傳送的資料（已呼叫write但底層tcp協議棧還沒傳送的）

2）停止等待已傳送資料的確認訊息，已傳送未確認的資料不再重發

【斷連過程總結】

1）close只是減少socket檔案的引用計數，當計數減為0後，作業系統執行tcp的斷連操作

2）client端close後server端不close，會導致client端連線狀態為FIN_WAIT_2，server端連線狀態為CLOSE_WAIT

     正常程式設計肯定不會這樣處理，一般都是在異常處理跳轉（C++/JAVA等）導致沒有close，或者整個系統異常導致沒有close（例      如JVM記憶體出現out of memory錯誤）

3）shutdown的處理邏輯比較複雜，非特殊情況不要亂用，很容易出問題

4）程序退出後作業系統會自動回收socket，發起tcp關閉流程操作