LINUX下解決netstat檢視TIME_WAIT狀态過多問題

# 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：等待所有分組死掉

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 狀态

     本文轉自yzy121403725 51CTO部落格，原文連結：http://blog.51cto.com/lookingdream/1902257，如需轉載請自行聯系原作者