netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
FIN_WAIT_1 286
FIN_WAIT_2 960
SYN_SENT 3
LAST_ACK 32
CLOSING 1
CLOSED 36
SYN_RCVD 144
TIME_WAIT 2520
ESTABLISHED 352
www.2cto.com
返回參數的說明如下：
CLOSED：無連接是活動的或正在進行
LISTEN：服務器在等待進入呼叫
SYN_RECV：一個連接請求已經到達，等待確認
SYN_SENT：應用已經開始，打開一個連接
ESTABLISHED：正常數據傳輸狀態
FIN_WAIT1：應用說它已經完成
FIN_WAIT2：另一邊已同意釋放
TIME_WAIT：等待所有分組死掉
CLOSING：兩邊同時嘗試關閉
TIME_WAIT：另一邊已初始化一個釋放
LAST_ACK：等待所有分組死掉
TCP變遷圖：
pache服務器的fin_wait1過多time_wait過多問題解決
1、fin_wait1狀態過多。fin_wait1狀態是在server端主動要求關閉tcp連接，並且主動發送fin以後，等待client端回復ack時候的狀態。fin_wait1的產生原因有很多，需要結合netstat的狀態來分析。
netstat -nat|awk '{print awk $NF}'|sort|uniq -c|sort -n
上面的命令可以幫助分析哪種tcp狀態數量異常
netstat -nat|grep ":80"|awk '{print $5}' |awk -F: '{print $1}' | sort| uniq -c|sort -n
則可以幫助你將請求80服務的client ip按照連接數排序。
2、time_wait狀態過多。 www.2cto.com
通常表現為apache服務器負載高，w命令顯示load average可能上百，但是web服務基本沒有問題。同時ssh能夠登陸，但是反應非常遲鈍。
原因：最可能的原因是httpd.conf裡面keepalive沒有開，導致每次請求都要建立新的tcp連接，請求完成以後關閉，增加了很多time_wait的狀態。另，keepalive可能會增加一部分內存的開銷，但是問題不大。
分析：如果發現fin_wait1狀態很多，並且client ip分布正常，那可能是有人用肉雞進行ddos攻擊、又或者最近的程序改動引起了問題。一般說來後者可能性更大，應該主動聯系程序員解決。
但是如果有某個ip連接數非常多，就值得注意了，可以考慮用iptables直接封了他。
查IP的關於80端口的連接數可以用：
netstat -nat|grep ":80"|awk '{print $5}' |awk -F: '{print $1}' | sort| uniq -c|sort -n
可以看到目前IP的連接數。太多的，就要注意了。
此外再分享一個實時查看apache並發數的：
watch -n 1 -d "pgrep httpd|wc -l"，冒號裡的語句可以自己調啦~
