最近項目中發現用screen啟動socket老出錯，在調試腳本中看出是screen 啟動后，但是並沒有將socket拉起；起初一直在查是不是由於screen啟動機制導致的，后來和同事溝通發現是由於服務器端socket有大量的客戶端連接時，當服務器主動kill掉socket的tcp端口時，再次立即重啟，socket端口並不會成功啟動，原因是服務器端口的連接處於time_wait狀態。
解決方法：
我們可以通過調整內核參數來調整：
vi /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連接數netstat -ant |grep “TIME_WAIT” |wc –l
在沒有nat情況下還需要設置net.ipv4.tcp_timestamps = 1才能生效。
關於內核參數的詳細介紹，可以參考官方文檔。我們這里簡要說明一下tcp_tw_recycle參數。它用來快速回收TIME_WAIT連接，不過如果在NAT環境下會引發問題。
RFC1323中有如下一段描述：
An additional mechanism could be added to the TCP, a per-host cache of the last timestamp received from any connection. This value could then be used in the PAWS mechanism to reject old duplicate segments from earlier incarnations of the connection, if the timestamp clock can be guaranteed to have ticked at least once since the old connection was open. This would require that the TIME-WAIT delay plus the RTT together must be at least one tick of the sender’s timestamp clock. Such an extension is not part of the proposal of this RFC.
大概意思是說TCP有一種行為，可以緩存每個連接最新的時間戳，后續請求中如果時間戳小於緩存的時間戳，即視為無效，相應的數據包會被丟棄。
Linux是否啟用這種行為取決於tcp_timestamps和tcp_tw_recycle，因為tcp_timestamps缺省就是開啟的，所以當tcp_tw_recycle被開啟后，實際上這種行為就被激活了。在nat環境中會出現時間戳錯亂的情況，后面的數據包就被丟棄了，具體的 表現通常是是客戶端明明發送的SYN，但服務端就是不響應ACK。
============================================================================================
tcp參數詳解之tcp_fin_timeout
============================================================================================
tcp_fin_timeout ：INTEGER
默認值是 60
對於本端斷開的socket連接，TCP保持在FIN_WAIT_2狀態的時間。對方可能會斷開連接或一直不結束連接或不可預料的進程死亡。默認值為 60 秒。過去在2.2版本的內核中是 180 秒。您可以設置該值﹐但需要注意﹐如果您的機器為負載很重的web服務器﹐您可能要冒內存被大量無效數據報填滿的風險﹐FIN-WAIT-2 sockets 的危險性低於 FIN-WAIT-1 ﹐因為它們最多只吃 1.5K 的內存﹐但是它們存在時間更長。另外參考 tcp_max_orphans。
CLOSE_WAIT狀態的生成原因
如果服務器程序APACHE處於CLOSE_WAIT狀態的話，說明套接字是被動關閉的！
假設CLIENT端主動斷掉當前連接，那么雙方關閉這個TCP連接共需要四個packet：
Client ---> FIN ---> Server
Client <--- ACK <--- Server
這時候Client端處於FIN_WAIT_2狀態；而Server 程序處於CLOSE_WAIT狀態。
Client <--- FIN <--- Server
這時Server 發送FIN給Client，Server 就置為LAST_ACK狀態。
Client ---> ACK ---> Server
Client回應了ACK，那么Server 的套接字才會真正置為CLOSED狀態。
Server 程序處於CLOSE_WAIT狀態，而不是LAST_ACK狀態，說明還沒有發FIN給Client，那么可能是在關閉連接之前還有許多數據要發送或者其他事要做，導致沒有發這個FIN packet。
通常來說，一個CLOSE_WAIT會維持至少2個小時的時間。如果有個流氓特地寫了個程序，給你造成一堆的CLOSE_WAIT，消耗資源，那么通常是等不到釋放那一刻，系統就已經解決崩潰了。
============================================================================================
TCP連接狀態詳解及TIME_WAIT過多的解決方法
============================================================================================
TIME_WAIT狀態原理
----------------------------
通信雙方建立TCP連接后，主動關閉連接的一方就會進入TIME_WAIT狀態。
客戶端主動關閉連接時，會發送最后一個ack后，然后會進入TIME_WAIT狀態，再停留2個MSL時間(后有MSL的解釋)，進入CLOSED狀態。
下圖是以客戶端主動關閉連接為例，說明這一過程的。
TIME_WAIT狀態存在的理由
----------------------------
TCP/IP協議就是這樣設計的，是不可避免的。主要有兩個原因:
1）可靠地實現TCP全雙工連接的終止
TCP協議在關閉連接的四次握手過程中，最終的ACK是由主動關閉連接的一端（后面統稱A端）發出的，如果這個ACK丟失，對方（后面統稱B端）將重發出最終的FIN，因此A端必須維護狀態信息（TIME_WAIT）允許它重發最終的ACK。如果A端不維持TIME_WAIT狀態，而是處於CLOSED 狀態，那么A端將響應RST分節，B端收到后將此分節解釋成一個錯誤（在java中會拋出connection reset的SocketException)。
因而，要實現TCP全雙工連接的正常終止，必須處理終止過程中四個分節任何一個分節的丟失情況，主動關閉連接的A端必須維持TIME_WAIT狀態 。
2）允許老的重復分節在網絡中消逝
TCP分節可能由於路由器異常而“迷途”，在迷途期間，TCP發送端可能因確認超時而重發這個分節，迷途的分節在路由器修復后也會被送到最終目的地，這個遲到的迷途分節到達時可能會引起問題。在關閉“前一個連接”之后，馬上又重新建立起一個相同的IP和端口之間的“新連接”，“前一個連接”的迷途重復分組在“前一個連接”終止后到達，而被“新連接”收到了。為了避免這個情況，TCP協議不允許處於TIME_WAIT狀態的連接啟動一個新的可用連接，因為TIME_WAIT狀態持續2MSL，就可以保證當成功建立一個新TCP連接的時候，來自舊連接重復分組已經在網絡中消逝。
MSL時間
----------------------------
MSL就是maximum segment lifetime(最大分節生命期），這是一個IP數據包能在互聯網上生存的最長時間，超過這個時間IP數據包將在網絡中消失 。MSL在RFC 1122上建議是2分鍾，而源自berkeley的TCP實現傳統上使用30秒。
TIME_WAIT狀態維持時間
----------------------------
TIME_WAIT狀態維持時間是兩個MSL時間長度，也就是在1-4分鍾。Windows操作系統就是4分鍾。
http://www.cnblogs.com/itcomputer/p/7150954.html
上圖對排除和定位網絡或系統故障時大有幫助，但是怎樣牢牢地將這張圖刻在腦中呢？那么你就一定要對這張圖的每一個狀態，及轉換的過程有深刻地認識，不能只停留在一知半解之中。下面對這張圖的11種狀態詳細解釋一下，以便加強記憶！不過在這之前，先回顧一下TCP建立連接的三次握手過程，以及關閉連接的四次握手過程。
1、建立連接協議（三次握手）
（1）客戶端發送一個帶SYN標志的TCP報文到服務器。這是三次握手過程中的報文1。
（2） 服務器端回應客戶端的，這是三次握手中的第2個報文，這個報文同時帶ACK標志和SYN標志。因此它表示對剛才客戶端SYN報文的回應；同時又標志SYN給客戶端，詢問客戶端是否准備好進行數據通訊。
（3） 客戶必須再次回應服務段一個ACK報文，這是報文段3。
2、連接終止協議（四次握手）
由於TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務后就能發送一個FIN來終止這個方向的連接。收到一個 FIN只意味着這一方向上沒有數據流動，一個TCP連接在收到一個FIN后仍能發送數據。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
（1） TCP客戶端發送一個FIN，用來關閉客戶到服務器的數據傳送（報文段4）。
（2） 服務器收到這個FIN，它發回一個ACK，確認序號為收到的序號加1（報文段5）。和SYN一樣，一個FIN將占用一個序號。
（3） 服務器關閉客戶端的連接，發送一個FIN給客戶端（報文段6）。
（4） 客戶段發回ACK報文確認，並將確認序號設置為收到序號加1（報文段7）。
CLOSED: 這個沒什么好說的了，表示初始狀態。
LISTEN: 這個也是非常容易理解的一個狀態，表示服務器端的某個SOCKET處於監聽狀態，可以接受連接了。
SYN_RCVD: 這個狀態表示接受到了SYN報文，在正常情況下，這個狀態是服務器端的SOCKET在建立TCP連接時的三次握手會話過程中的一個中間狀態，很短暫，基本上用netstat你是很難看到這種狀態的，除非你特意寫了一個客戶端測試程序，故意將三次TCP握手過程中最后一個ACK報文不予發送。因此這種狀態時，當收到客戶端的ACK報文后，它會進入到ESTABLISHED狀態。
SYN_SENT: 這個狀態與SYN_RCVD遙想呼應，當客戶端SOCKET執行CONNECT連接時，它首先發送SYN報文，因此也隨即它會進入到了SYN_SENT狀態，並等待服務端的發送三次握手中的第2個報文。SYN_SENT狀態表示客戶端已發送SYN報文。
ESTABLISHED：這個容易理解了，表示連接已經建立了。
FIN_WAIT_1: 這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別是：FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時，它想主動關閉連接，向對方發送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1狀態。而當對方回應ACK報文后，則進入到FIN_WAIT_2狀態，當然在實際的正常情況下，無論對方何種情況下，都應該馬上回應ACK報文，所以FIN_WAIT_1狀態一般是比較難見到的，而FIN_WAIT_2狀態還有時常常可以用netstat看到。
FIN_WAIT_2：上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半連接，也即有一方要求close連接，但另外還告訴對方，我暫時還有點數據需要傳送給你，稍后再關閉連接。
TIME_WAIT: 表示收到了對方的FIN報文，並發送出了ACK報文，就等2MSL后即可回到CLOSED可用狀態了。如果FIN_WAIT_1狀態下，收到了對方同時帶FIN標志和ACK標志的報文時，可以直接進入到TIME_WAIT狀態，而無須經過FIN_WAIT_2狀態。
注:MSL(最大分段生存期)指明TCP報文在Internet上最長生存時間,每個具體的TCP實現都必須選擇一個確定的MSL值.RFC 1122建議是2分鍾,但BSD傳統實現采用了30秒.TIME_WAIT 狀態最大保持時間是2 * MSL,也就是1-4分鍾.
CLOSING: 這種狀態比較特殊，實際情況中應該是很少見，屬於一種比較罕見的例外狀態。正常情況下，當你發送FIN報文后，按理來說是應該先收到（或同時收到）對方的ACK報文，再收到對方的FIN報文。但是CLOSING狀態表示你發送FIN報文后，並沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什么情況下會出現此種情況呢？其實細想一下，也不難得出結論：那就是如果雙方幾乎在同時close一個SOCKET的話，那么就出現了雙方同時發送FIN報文的情況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET連接。
CLOSE_WAIT: 這種狀態的含義其實是表示在等待關閉。怎么理解呢？當對方close一個SOCKET后發送FIN報文給自己，你系統毫無疑問地會回應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正需要考慮的事情是察看你是否還有數據發送給對方，如果沒有的話，那么你也就可以close這個SOCKET，發送FIN報文給對方，也即關閉連接。所以你在CLOSE_WAIT狀態下，需要完成的事情是等待你去關閉連接。
LAST_ACK: 這個狀態還是比較容易好理解的，它是被動關閉一方在發送FIN報文后，最后等待對方的ACK報文。當收到ACK報文后，也即可以進入到CLOSED可用狀態了。
最后有2個問題的回答，我自己分析后的結論（不一定保證100%正確）
1、 為什么建立連接協議是三次握手，而關閉連接卻是四次握手呢？
這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求后，它可以把ACK和SYN（ACK起應答作用，而SYN起同步作用）放在一個報文里來發送。但關閉連接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；但未必你所有的數據都全部發送給對方了，所以你可以未必會馬上會關閉SOCKET,也即你可能還需要發送一些數據給對方之后，再發送FIN報文給對方來表示你同意現在可以關閉連接了，所以它這里的ACK報文和FIN報文多數情況下都是分開發送的。
2、 為什么TIME_WAIT狀態還需要等2MSL后才能返回到CLOSED狀態？
這是因為：雖然雙方都同意關閉連接了，而且握手的4個報文也都協調和發送完畢，按理可以直接回到CLOSED狀態（就好比從SYN_SEND狀態到ESTABLISH狀態那樣）；但是因為我們必須要假想網絡是不可靠的，你無法保證你最后發送的ACK報文會一定被對方收到，因此對方處於LAST_ACK狀態下的SOCKET可能會因為超時未收到ACK報文，而重發FIN報文，所以這個TIME_WAIT狀態的作用就是用來重發可能丟失的ACK報文，並保證於此。
查看當前系統下所有連接狀態的數：
[root@vps ~]#netstat -n|awk '/^tcp/{++S[$NF]}END{for (key in S) print key,S[key]}'
TIME_WAIT 286
FIN_WAIT1 5
FIN_WAIT2 6
ESTABLISHED 269
SYN_RECV 5
CLOSING 1
如發現系統存在大量TIME_WAIT狀態的連接，通過調整內核參數解決：
編輯文件/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 時間
其它參數說明：
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 表示如果套接字由本端要求關閉，這個參數決定了它保持在FIN-WAIT-2狀態的時間。
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套接字拖死。
注:
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
設置這兩個參數： reuse是表示是否允許重新應用處於TIME-WAIT狀態的socket用於新的TCP連接； recyse是加速TIME-WAIT sockets回收
http://blog.sina.com.cn/s/blog_8e5d24890102w9yi.html
========================================================================
TCP關閉問題詳細介紹
========================================================================
摘要: 三次握手，四次揮手
意思是tcp建立連接時需要三次交互來完成，A發起連接
|
1
2
3
|
A --- SYN --> B
A <-- SYN + ACK --- B (1)
A --- ACK --> B
|
而關閉tcp連接需要四次交互，A發起關閉
|
1
2
3
4
|
A --- FIN --> B
A <-- ACK --- B (1)
A <-- FIN --- B
A --- ACK --> B (2)
|
這里在（1）時B開始處於CLOSE_WAIT狀態，一直到收到ACK后B才轉為CLOSED ，而A就處於TIME_WAIT狀態，一直到2MSL（Max Segament Lifetime）才轉為CLOSED
為什么需要2MSL才真正轉為CLOSED？是因為需要緩沖時間萬一B丟失ACK重發FIN的話還可以回復ACK，還有就是2MSL后“迷失”在網絡上的包全部失效
大量的 TIME_WAIT 和 CLOSE_WAIT 會造成服務器的連接資源被浪費甚至占滿后導致服務器服務拒絕，怎么解決？
解決TIME_WAIT
|
1
2
3
4
5
|
net.ipv4.tcp_tw_recycle = 1 #開啟快速回收，默認0
net.ipv4.tcp_tw_reuse = 1 ＃開啟重用，默認0
net.ipv4.tcp_fin_timeout = 30 # 減小fin_timeout，默認60，單位s
|
系統參數的配置可以解決time_wait，但是close_wait就沒那么簡單了
解決CLOSE_WAIT
一般都是服務端的代碼問題。
絕大多數都是客戶端發起關閉，這樣可知HTTP服務器應該會有很多TIME_WAIT，不過當http使用keep-alive后服務端會主動斷連。