您好,登錄后才能下訂單哦!
本篇文章給大家分享的是有關如何解析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次握手截圖:
以上就是如何解析LINUX netstat連接狀態及進行TCP狀態轉換,小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。