LINUX netstat連線狀態解析及TCP狀態轉換

LINUX netstat連線狀態解析及TCP狀態轉換
水平有限如果有誤請指出。

我們經常在netstat -anlp 中能夠看到埠連線狀態一項
gaopeng@bogon:~$ netstat -anlp|grep 10050
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:10050           0.0.0.0:*               LISTEN      2502/server     
tcp        0      0 192.168.190.81:48008    192.168.190.81:10050    ESTABLISHED 2510/client     
tcp        0      0 192.168.190.81:10050    192.168.190.81:48008    ESTABLISHED 2502/server   
又比如
gaopeng@bogon:~$ netstat -anlp|grep 10050
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        1      0 192.168.190.81:48008    192.168.190.81:10050    CLOSE_WAIT  2510/client     
tcp        0      0 192.168.190.81:10050    192.168.190.81:48008    FIN_WAIT2   -           


比如這裡的LISTEN,ESTABLISHED,CLOSE_WAIT,FIN_WAIT2 那麼這些真正的含義是什麼？
下面是一個TCP狀態轉換圖(非常重要的一張圖)：
圖中實線為主動方,虛線為被動方，比如SERVER-CLIENT端,CLIENT端請求斷開連線那麼他就是主動方




下面是各種狀態的說明(擷取自刑文鵬LINUX系統程式設計講義)
CLOSED: 這個沒什麼好說的了，表示初始狀態。
LISTEN: 這個也是非常容易理解的一個狀態，表示伺服器端的某個SOCKET處於監聽狀態，可以接受連線了。
SYN_RCVD: 這個狀態表示接受到了SYN報文，在正常情況下，這個狀態是伺服器端的SOCKET在建立TCP連線時的三次
握手會話過程中的一箇中間狀態，很短暫，基本 上用netstat你是很難看到這種狀態的，除非你特意寫了一個客戶
端測試程式，故意將三次TCP握手過程中最後一個ACK報文不予傳送。因此這種狀態 時，當收到客戶端的ACK報文
後，它會進入到ESTABLISHED狀態。
SYN_SENT: 這個狀態與SYN_RCVD遙想呼應，當客戶端SOCKET執行CONNECT連線時，它首先傳送SYN報文，因此也隨即
它會進入到了SYN_SENT狀 態，並等待服務端的傳送三次握手中的第2個報文。SYN_SENT狀態表示客戶端已傳送SYN
報文。
ESTABLISHED：這個容易理解了，表示連線已經建立了。
FIN_WAIT_1: 這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報
文。而這兩種狀態的區別 是：FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時，它想主動關閉連線，向
對方傳送了FIN報文，此時該SOCKET即 進入到FIN_WAIT_1狀態。而當對方回應ACK報文後，則進入到FIN_WAIT_2狀
態，當然在實際的正常情況下，無論對方何種情況下，都應該馬 上回應ACK報文，所以FIN_WAIT_1狀態一般是比較
難見到的，而FIN_WAIT_2狀態還有時常常可以用netstat看到。
FIN_WAIT_2：上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半連線，也即有一方要求
close連線，但另外還告訴對方，我暫時還有點資料需要傳送給你，稍後再關閉連線。
TIME_WAIT: 表示收到了對方的FIN報文，併傳送出了ACK報文，就等2MSL後即可回到CLOSED可用狀態了。如果
FIN_WAIT_1狀態下，收到了對方同時帶 FIN標誌和ACK標誌的報文時，可以直接進入到TIME_WAIT狀態，而無須經過
FIN_WAIT_2狀態。
CLOSING: 這種狀態比較特殊，實際情況中應該是很少見，屬於一種比較罕見的例外狀態。正常情況下，當你傳送
FIN報文後，按理來說是應該先收到（或同時收到）對方的 ACK報文，再收到對方的FIN報文。但是CLOSING狀態表
示你傳送FIN報文後，並沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什 麼情況下會出現此種情況
呢？其實細想一下，也不難得出結論：那就是如果雙方几乎在同時close一個SOCKET的話，那麼就出現了雙方同時
傳送FIN報 文的情況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET連線。


我寫了一個socket 簡單的server和client 小程式什麼也不做，只是為了測試連線狀態，繫結埠10050，測試都是在一臺機器190.81上做的
繫結網路卡為本機全部網路卡 INADDR_ANY 巨集


我們現在來分析一下
1、正常連線情況
gaopeng@bogon:~$ netstat -anlp|grep 10050
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:10050           0.0.0.0:*               LISTEN      2502/server     
tcp        0      0 192.168.190.81:48008    192.168.190.81:10050    ESTABLISHED 2510/client     


tcp        0      0 192.168.190.81:10050    192.168.190.81:48008    ESTABLISHED 2502/server   
2、服務端ctrl+c SIGNT訊號預設處置方式
gaopeng@bogon:~$ netstat -anlp|grep 10050
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        1      0 192.168.190.81:48008    192.168.190.81:10050    CLOSE_WAIT  2510/client     
tcp        0      0 192.168.190.81:10050    192.168.190.81:48008    FIN_WAIT2   -


服務端ctrl+c SIGNT訊號預設處置方式
主動方 server端
被動方 client端


很明顯這個時候處於主動方傳送了FIN報文給被動方請求關閉連線,
被動方受到FIN報文返回一個ACK報文給被動方，同時被動方給主動方傳送一個FIN報文請求關閉連線，但是主動方
由於SIGINT已經進城終止，已經不能接收到這個FIN報文，所以這個時候主動方SERVER連線處於FIN_WAIT2狀態
已經不能相應被動方過來的FIN報文，同時被動方CLIENT端由於服務端不能接受FIN報文處於CLOSE_WAIT狀態。


3、
gaopeng@bogon:~$ netstat -anlp|grep 10050
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:10050           0.0.0.0:*               LISTEN      2568/server     
tcp        1      0 192.168.190.81:10050    192.168.190.81:48010    CLOSE_WAIT  2568/server     
tcp        0      0 192.168.190.81:48010    192.168.190.81:10050    FIN_WAIT2   -    


客戶端ctrl+c SIGNT訊號預設處置方式
被動方 server端
主動方 client端

這個情況和上面相反，不在描述。

下面是連線3次握手和斷開連線4次握手截圖：

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7728585/viewspace-2138360/，如需轉載，請註明出處，否則將追究法律責任。