客戶端與服務器端建立TCP/IP連接后關閉SOCKET后，服務器端連接的端口狀態為TIME_WAIT.主動關閉的一方在發送最后一個 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 狀態
netstat -an
查看下，發現系統中有很多time_wait的連接。因此直接用一下命令查看詳細情況
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
具體的解決方式
vim /etc/sysctl.conf
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 = 30
//修改系統默認的 TIMEOUT 時間
/sbin/sysctl -p //保存后生效
目前看來最好的辦法是讓每個TIME_WAIT早點過期。
在linux上可以這么配置：
#讓TIME_WAIT狀態可以重用，這樣即使TIME_WAIT占滿了所有端口，也不會拒絕新的請求造成障礙
echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse
#讓TIME_WAIT盡快回收，我也不知是多久，觀察大概是一秒鍾
echo "1" > /proc/sys/net/ipv4/tcp_tw_recycle
很多文檔都會建議兩個參數都配置上，但是我發現只用修改tcp_tw_recycle就可以解決問題的了，TIME_WAIT重用TCP協議本身就是不建議打開的。
不能重用端口可能會造成系統的某些服務無法啟動，比如要重啟一個系統監控的軟件，它用了40000端口，而這個端口在軟件重啟過程中剛好被使用了，就可能會重啟失敗的。linux默認考慮到了這個問題，有這么個設定：
#查看系統本地可用端口極限值
cat /proc/sys/net/ipv4/ip_local_port_range
用 這條命令會返回兩個數字，默認是：32768 61000，說明這台機器本地能向外連接61000-32768=28232個連接，注意是本地向外連接， 不是這台機器的所有連接，不會影響這台機器的80端口的對外連接數。但這個數字會影響到代理服務器（nginx）對app服務器的最大連接數，因為 nginx對app是用的異步傳輸，所以這個環節的連接速度很快，所以堆積的連接就很少。假如nginx對app服務器之間的帶寬出了問題或是app服務 器有問題，那么可能使連接堆積起來，這時可以通過設定nginx的代理超時時間，來使連接盡快釋放掉，一般來說極少能用到28232個連接
————————————————分界線————————————————
1、 time_wait的作用：
TIME_WAIT狀態存在的理由： 1）可靠地實現TCP全雙工連接的終止 在進行關閉連接四次揮手協議時，最后的ACK是由主動關閉端發出的，如果這個最終的ACK丟失，服務器將重發最終的FIN， 因此客戶端必須維護狀態信息允許它重發最終的ACK。如果不維持這個狀態信息，那么客戶端將響應RST分節，服務器將此分節解釋成一個錯誤（在java中會拋出connection reset的SocketException)。 因而，要實現TCP全雙工連接的正常終止，必須處理終止序列四個分節中任何一個分節的丟失情況，主動關閉的客戶端必須維持狀態信息進入TIME_WAIT狀態。 2）允許老的重復分節在網絡中消逝 TCP分節可能由於路由器異常而“迷途”，在迷途期間，TCP發送端可能因確認超時而重發這個分節，迷途的分節在路由器修復后也會被送到最終目的地，這個原來的迷途分節就稱為lost duplicate。 在關閉一個TCP連接后，馬上又重新建立起一個相同的IP地址和端口之間的TCP連接，后一個連接被稱為前一個連接的化身（incarnation)，那么有可能出現這種情況，前一個連接的迷途重復分組在前一個連接終止后出現，從而被誤解成從屬於新的化身。 為了避免這個情況，TCP不允許處於TIME_WAIT狀態的連接啟動一個新的化身，因為TIME_WAIT狀態持續2MSL，就可以保證當成功建立一個TCP連接的時候，來自連接先前化身的重復分組已經在網絡中消逝。
2、大量TIME_WAIT造成的影響：
在高並發短連接的TCP服務器上，當服務器處理完請求后立刻主動正常關閉連接。這個場景下會出現大量socket處於TIME_WAIT狀態。如果客戶端的並發量持續很高，此時部分客戶端就會顯示連接不上。
我來解釋下這個場景。主動正常關閉TCP連接，都會出現TIMEWAIT。
為什么我們要關注這個高並發短連接呢？有兩個方面需要注意：
1. 高並發可以讓服務器在短時間范圍內同時占用大量端口，而端口有個0~65535的范圍，並不是很多，刨除系統和其他服務要用的，剩下的就更少了。
2. 在這個場景中，短連接表示“業務處理+傳輸數據的時間 遠遠小於 TIMEWAIT超時的時間”的連接。
這里有個相對長短的概念，比如取一個web頁面，1秒鍾的http短連接處理完業務，在關閉連接之后，這個業務用過的端口會停留在TIMEWAIT狀態幾分鍾，而這幾分鍾，其他HTTP請求來臨的時候是無法占用此端口的(占着茅坑不拉翔)。
單用這個業務計算服務器的利用率會發現，服務器干正經事的時間和端口（資源）被掛着無法被使用的時間的比例是 1：幾百，服務器資源嚴重浪費。（說個題外話，從這個意義出發來考慮服務器性能調優的話，長連接業務的服務就不需要考慮TIMEWAIT狀態。同時，假如你對服務器業務場景非常熟悉，你會發現，在實際業務場景中，一般長連接對應的業務的並發量並不會很高。
綜合這兩個方面，持續的到達一定量的高並發短連接，會使服務器因端口資源不足而拒絕為一部分客戶服務。同時，這些端口都是服務器臨時分配，無法用SO_REUSEADDR選項解決這個問題。
關於time_wait的反思：
存在即是合理的，既然TCP協議能盛行四十多年，就證明他的設計合理性。所以我們盡可能的使用其原本功能。 依靠TIME_WAIT狀態來保證我的服務器程序健壯，服務功能正常。 那是不是就不要性能了呢？並不是。如果服務器上跑的短連接業務量到了我真的必須處理這個TIMEWAIT狀態過多的問題的時候，我的原則是盡量處理，而不是跟TIMEWAIT干上，非先除之而后快。 如果盡量處理了，還是解決不了問題，仍然拒絕服務部分請求，那我會采取負載均衡來抗這些高並發的短請求。持續十萬並發的短連接請求，兩台機器，每台5萬個，應該夠用了吧。一般的業務量以及國內大部分網站其實並不需要關注這個問題，一句話，達不到時才需要關注這個問題的訪問量。
小知識點：
TCP協議發表：1974年12月，卡恩、瑟夫的第一份TCP協議詳細說明正式發表。當時美國國防部與三個科學家小組簽定了完成TCP/IP的協議，結果由瑟夫領銜的小組捷足先登，首先制定出了通過詳細定義的TCP/IP協議標准。當時作了一個試驗，將信息包通過點對點的衛星網絡，再通過陸地電纜
，再通過衛星網絡，再由地面傳輸，貫串歐洲和美國，經過各種電腦系統，全程9.4萬公里竟然沒有丟失一個數據位，遠距離的可靠數據傳輸證明了TCP/IP協議的成功。
3、案列分析：
首先，根據一個查詢TCP連接數，來說明這個問題。
netstat -ant|awk '/^tcp/ {++S[$NF]} END {for(a in S) print (a,S[a])}'
LAST_ACK 14
SYN_RECV 348
ESTABLISHED 70
FIN_WAIT1 229
FIN_WAIT2 30
CLOSING 33
TIME_WAIT 18122
狀態描述：
CLOSED：無連接是活動的或正在進行 LISTEN：服務器在等待進入呼叫 SYN_RECV：一個連接請求已經到達，等待確認 SYN_SENT：應用已經開始，打開一個連接 ESTABLISHED：正常數據傳輸狀態 FIN_WAIT1：應用說它已經完成 FIN_WAIT2：另一邊已同意釋放 ITMED_WAIT：等待所有分組死掉 CLOSING：兩邊同時嘗試關閉 TIME_WAIT：另一邊已初始化一個釋放 LAST_ACK：等待所有分組死掉
命令解釋：
先來看看netstat： netstat -n Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 123.123.123.123:80 234.234.234.234:12345 TIME_WAIT 你實際執行這條命令的時候，可能會得到成千上萬條類似上面的記錄，不過我們就拿其中的一條就足夠了。 再來看看awk： /^tcp/ 濾出tcp開頭的記錄，屏蔽udp, socket等無關記錄。 state[]相當於定義了一個名叫state的數組 NF 表示記錄的字段數，如上所示的記錄，NF等於6 $NF 表示某個字段的值，如上所示的記錄，$NF也就是$6，表示第6個字段的值，也就是TIME_WAIT state[$NF]表示數組元素的值，如上所示的記錄，就是state[TIME_WAIT]狀態的連接數 ++state[$NF]表示把某個數加一，如上所示的記錄，就是把state[TIME_WAIT]狀態的連接數加一 END 表示在最后階段要執行的命令 for(key in state) 遍歷數組
如何盡量處理TIMEWAIT過多?
編輯內核文件/etc/sysctl.conf，加入以下內容：
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 時間
然后執行 /sbin/sysctl -p 讓參數生效.
/etc/sysctl.conf是一個允許改變正在運行中的Linux系統的接口，它包含一些TCP/IP堆棧和虛擬內存系統的高級選項，修改內核參數永久生效。
簡單來說，就是打開系統的TIMEWAIT重用和快速回收。
如果以上配置調優后性能還不理想，可繼續修改一下配置：
vi /etc/sysctl.conf net.ipv4.tcp_keepalive_time = 1200 #表示當keepalive起用的時候，TCP發送keepalive消息的頻度。缺省是2小時，改為20分鍾。 net.ipv4.ip_local_port_range = 1024 65000 #表示用於向外連接的端口范圍。缺省情況下很小：32768到61000，改為1024到65000。 net.ipv4.tcp_max_syn_backlog = 8192 #表示SYN隊列的長度，默認為1024，加大隊列長度為8192，可以容納更多等待連接的網絡連接數。 net.ipv4.tcp_max_tw_buckets = 5000 #表示系統同時保持TIME_WAIT套接字的最大數量，如果超過這個數字，TIME_WAIT套接字將立刻被清除並打印警告信息。 默認為180000，改為5000。對於Apache、Nginx等服務器，上幾行的參數可以很好地減少TIME_WAIT套接字數量，但是對於 Squid，效果卻不大。此項參數可以控制TIME_WAIT套接字的最大數量，避免Squid服務器被大量的TIME_WAIT套接字拖死。