LINUX下解決netstat查看TIME_WAIT狀態過多問題

標籤：linux

# netstat -an|awk ‘/tcp/ {print $6}‘|sort|uniq -c

     16 CLOSING

    130 ESTABLISHED

    298 FIN_WAIT1

     13 FIN_WAIT2

      9 LAST_ACK

      7 LISTEN

    103 SYN_RECV

   5204 TIME_WAIT

狀態：描述

CLOSED：無串連是活動的或進行中

LISTEN：伺服器在等待進入呼叫

SYN_RECV：一個串連請求已經到達，等待確認

SYN_SENT：應用已經開始，開啟一個串連

ESTABLISHED：正常資料轉送狀態

FIN_WAIT1：應用說它已經完成

FIN_WAIT2：另一邊已同意釋放

ITMED_WAIT：等待所有分組死掉

CLOSING：兩邊同時嘗試關閉

TIME_WAIT：另一邊已初始化一個釋放

LAST_ACK：等待所有分組死掉

 

 

如發現系統存在大量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 讓參數生效。

 

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 時間

 

下面附上TIME_WAIT狀態的意義：

 

用戶端與伺服器端建立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 狀態

本文出自 “夢想照進現實” 部落格，請務必保留此出處http://lookingdream.blog.51cto.com/5177800/1902257

LINUX下解決netstat查看TIME_WAIT狀態過多問題