雲端計算運維學習---Linux監控tcp連線數及狀態

一、檢視哪些IP連線本機

netstat -an

二、檢視TCP連線數

檢視tcp連線數狀態 
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 

統計8080埠上有多少個TCP連線，命令： 
netstat -ant |grep 80|wc -l 

TCP連線中有多少個連線狀態是ESTABLISHED，命令： 
netstat -ant |grep 80|grep ESTABLISHED|wc -l 

TCP連線中有多少個連線狀態是CLOSE_WAIT 
netstat -ant |grep 80|grep CLOSE_WAIT|wc -l 

TCP連線中有多少個連線狀態是TIME_WAIT 
netstat -ant |grep 80|grep TIME_WAIT|wc -l 

使用awk來完成統計資訊，命令如下 
netstat -ant |grep 80|awk '{++S[$NF]} END {for (a in S) print a, S[a]}'

TCP連線狀態詳解：

LISTEN：      偵聽來自遠方的TCP埠的連線請求
SYN-SENT：    再傳送連線請求後等待匹配的連線請求
SYN-RECEIVED：再收到和傳送一個連線請求後等待對方對連線請求的確認
ESTABLISHED： 代表一個開啟的連線
FIN-WAIT-1：  等待遠端TCP連線中斷請求，或先前的連線中斷請求的確認
FIN-WAIT-2：  從遠端TCP等待連線中斷請求
CLOSE-WAIT：  等待從本地使用者發來的連線中斷請求
CLOSING：     等待遠端TCP對連線中斷的確認
LAST-ACK：    等待原來的發向遠端TCP的連線中斷請求的確認
TIME-WAIT：   等待足夠的時間以確保遠端TCP接收到連線中斷請求的確認
CLOSED：      沒有任何連線狀態
SYN_RECV：    表示正在等待處理的請求數；
ESTABLISHED： 表示正常資料傳輸狀態；
TIME_WAIT：   表示處理完畢，等待超時結束的請求數。

三、如發現系統存在大量TIME_WAIT狀態的連線，通過調整核心引數解決

vim /etc/sysctl.conf
編輯檔案，加入以下內容：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30

然後執行
/sbin/sysctl -p 
讓引數生效。

附上TIME_WAIT狀態的意義：
net.ipv4.tcp_syncookies = 1 表示開啟SYN cookies。當出現SYN等待佇列溢位時，啟用cookies來處理，可防範少量SYN攻擊，預設為0，表示關閉；
net.ipv4.tcp_tw_reuse = 1 表示開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連線，預設為0，表示關閉；
net.ipv4.tcp_tw_recycle = 1 表示開啟TCP連線中TIME-WAIT sockets的快速回收，預設為0，表示關閉。
net.ipv4.tcp_fin_timeout 修改系統預設的TIMEOUT時間

四、客戶端與伺服器端建立TCP/IP連線後關閉SOCKET後，伺服器端連線的埠狀態為TIME_WAIT是不是所有執行主動關閉的socket都會進入TIME_WAIT狀態呢？有沒有什麼情況使主動關閉的socket直接進入CLOSED狀態呢？

主動關閉的一方在傳送最後一個ack後，就會進入TIME_WAIT狀態停留2MSL（max segment lifetime）時間，這個是TCP/IP必不可少的，也就是“解決”不了的。也就是TCP/IP設計者本來是這麼設計的。
主要有兩個原因：

• 1、防止上一次連線中的包，迷路後重新出現，影響新連線（經過2MSL，上一次連線中所有的重複包都會消失）
• 2、可靠的關閉TCP連線在主動關閉方傳送的最後一個 ack(fin) ，有可能丟失，這時被動方會重新發fin, 如果這時主動方處於CLOSED狀態 ，就會響應rst而不是ack。所以主動方要處於TIME_WAIT狀態，而不能是CLOSED 。TIME_WAIT並不會佔用很大資源的，除非受到攻擊。還有，如果一方 send 或 recv 超時，就會直接進入 CLOSED 狀態。

原文地址：https://www.cnblogs.com/augusite/p/11151751.html