起因
今天登陸服務器想查看一個端口的占用情況，發現好多TIME_WAIT的情況，嚇我一跳。
如下是TCP 建立連接的示意圖
緣由
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連接的時候，來自連接先前化身的重復分組已經在網絡中消逝。
大量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協議的成功。
解決方案
使用命令：netstat -an | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 查看連接狀態統計
使用命令：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 數量在下降
參考資料
原文地址： linux服務器出現大量TIME_WAIT的解決方法
標簽： linux time wait time_wait