原文
http://huoding.com/2013/12/31/316
再敘TIME_WAIT
之所以起這樣一個題目是因爲很久以前我曾經寫過一篇介紹TIME_WAIT的文章，不過當時基本屬於淺嘗輒止，並沒深入說明問題的來龍去脈，碰巧這段時間反覆被別人問到相關的問題，讓我覺得有必要全面總結一下，以備不時之需。
討論前大家可以拿手頭的服務器摸摸底，記住「ss」比「netstat」快：
shell> ss -ant | awk '
NR>1 {++s[$1]} END {for(k in s) print k,s[k]}
'
如果你只是想單獨查詢一下TIME_WAIT的數量，那麼還可以更簡單一些：
shell> cat /proc/net/sockstat
我猜你一定被巨大無比的TIME_WAIT網絡連接總數嚇到了！以我個人的經驗，對於一臺繁忙的Web服務器來說，如果主要以短連接爲主，那麼其TIME_WAIT網絡連接總數很可能會達到幾萬，甚至十幾萬。雖然一個TIME_WAIT網絡連接耗費的資源無非就是一個端口、一點內存，但是架不住基數大，所以這始終是一個需要面對的問題。
爲什麼會存在TIME_WAIT？
TCP在建立連接的時候需要握手，同理，在關閉連接的時候也需要握手。爲了更直觀的說明關閉連接時握手的過程，我們引用「The TCP/IP Guide」中的例子：
TCP Close
因爲TCP連接是雙向的，所以在關閉連接的時候，兩個方向各自都需要關閉。先發FIN包的一方執行的是主動關閉；後發FIN包的一方執行的是被動關閉。主動關閉的一方會進入TIME_WAIT狀態，並且在此狀態停留兩倍的MSL時長。
穿插一點MSL的知識：MSL指的是報文段的最大生存時間，如果報文段在網絡活動了MSL時間，還沒有被接收，那麼會被丟棄。關於MSL的大小，RFC 793協議中給出的建議是兩分鐘，不過實際上不同的操作系統可能有不同的設置，以Linux爲例，通常是半分鐘，兩倍的MSL就是一分鐘，也就是60秒，並且這個數值是硬編碼在內核中的，也就是說除非你重新編譯內核，否則沒法修改它：
#define TCP_TIMEWAIT_LEN (60*HZ)
如果每秒的連接數是一千的話，那麼一分鐘就可能會產生六萬個TIME_WAIT。
爲什麼主動關閉的一方不直接進入CLOSED狀態，而是進入TIME_WAIT狀態，並且停留兩倍的MSL時長呢？這是因爲TCP是建立在不可靠網絡上的可靠的協議。例子：主動關閉的一方收到被動關閉的一方發出的FIN包後，迴應ACK包，同時進入TIME_WAIT狀態，但是因爲網絡原因，主動關閉的一方發送的這個ACK包很可能延遲，從而觸發被動連接一方重傳FIN包。極端情況下，這一去一回，就是兩倍的MSL時長。如果主動關閉的一方跳過TIME_WAIT直接進入CLOSED，或者在TIME_WAIT停留的時長不足兩倍的MSL，那麼當被動關閉的一方早先發出的延遲包到達後，就可能出現類似下面的問題：
- 舊的TCP連接已經不存在了，系統此時只能返回RST包
- 新的TCP連接被建立起來了，延遲包可能干擾新的連接
不管是哪種情況都會讓TCP不再可靠，所以TIME_WAIT狀態有存在的必要性。
如何控制TIME_WAIT的數量？
從前面的描述我們可以得出這樣的結論：TIME_WAIT這東西沒有的話不行，不過太多可能也是個麻煩事。下面讓我們看看有哪些方法可以控制TIME_WAIT數量，這裏只說一些常規方法，另外一些諸如SO_LINGER之類的方法太過偏門，略過不談。
ip_conntrack：顧名思義就是跟蹤連接。一旦激活了此模塊，就能在系統參數裏發現很多用來控制網絡連接狀態超時的設置，其中自然也包括TIME_WAIT：
shell> modprobe ip_conntrack shell> sysctl net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait
我們可以嘗試縮小它的設置，比如十秒，甚至一秒，具體設置成多少合適取決於網絡情況而定，當然也可以參考相關的案例。不過就我的個人意見來說，ip_conntrack引入的問題比解決的還多，比如性能會大幅下降，所以不建議使用。
tcp_tw_recycle：顧名思義就是回收TIME_WAIT連接。可以說這個內核參數已經變成了大衆處理TIME_WAIT的萬金油，如果你在網絡上搜索TIME_WAIT的解決方案，十有八九會推薦設置它，不過這裏隱藏着一個不易察覺的陷阱：
當多個客戶端通過NAT方式聯網並與服務端交互時，服務端看到的是同一個IP，也就是說對服務端而言這些客戶端實際上等同於一個，可惜由於這些客戶端的時間戳可能存在差異，於是乎從服務端的視角看，便可能出現時間戳錯亂的現象，進而直接導致時間戳小的數據包被丟棄。參考：tcp_tw_recycle和tcp_timestamps導致connect失敗問題。
tcp_tw_reuse：顧名思義就是複用TIME_WAIT連接。當創建新連接的時候，如果可能的話會考慮複用相應的TIME_WAIT連接。通常認爲「tcp_tw_reuse」比「tcp_tw_recycle」安全一些，這是因爲一來TIME_WAIT創建時間必須超過一秒纔可能會被複用；二來只有連接的時間戳是遞增的時候纔會被複用。官方文檔裏是這樣說的：如果從協議視角看它是安全的，那麼就可以使用。這簡直就是外交辭令啊！按我的看法，如果網絡比較穩定，比如都是內網連接，那麼就可以嘗試使用。
不過需要注意的是在哪裏使用，既然我們要複用連接，那麼當然應該在連接的發起方使用，而不能在被連接方使用。舉例來說：客戶端向服務端發起HTTP請求，服務端響應後主動關閉連接，於是TIME_WAIT便留在了服務端，此類情況使用「tcp_tw_reuse」是無效的，因爲服務端是被連接方，所以不存在複用連接一說。讓我們延伸一點來看，比如說服務端是PHP，它查詢另一個MySQL服務端，然後主動斷開連接，於是TIME_WAIT就落在了PHP一側，此類情況下使用「tcp_tw_reuse」是有效的，因爲此時PHP相對於MySQL而言是客戶端，它是連接的發起方，所以可以複用連接。
說明：如果使用tcp_tw_reuse，請激活tcp_timestamps，否則無效。
tcp_max_tw_buckets：顧名思義就是控制TIME_WAIT總數。官網文檔說這個選項只是爲了阻止一些簡單的DoS攻擊，平常不要人爲的降低它。如果縮小了它，那麼系統會將多餘的TIME_WAIT刪除掉，日誌裏會顯示：「TCP: time wait bucket table overflow」。
需要提醒大家的是物極必反，曾經看到有人把「tcp_max_tw_buckets」設置成0，也就是說完全拋棄TIME_WAIT，這就有些冒險了，用一句圍棋諺語來說：入界宜緩。
…
有時候，如果我們換個角度去看問題，往往能得到四兩撥千斤的效果。前面提到的例子：客戶端向服務端發起HTTP請求，服務端響應後主動關閉連接，於是TIME_WAIT便留在了服務端。這裏的關鍵在於主動關閉連接的是服務端！在關閉TCP連接的時候，先出手的一方註定逃不開TIME_WAIT的宿命，套用一句歌詞：把我的悲傷留給自己，你的美麗讓你帶走。如果客戶端可控的話，那麼在服務端打開KeepAlive，儘可能不讓服務端主動關閉連接，而讓客戶端主動關閉連接，如此一來問題便迎刃而解了。