What is CLOSE_WAIT & TIME_WAIT?

Due to the way TCP/IP works, connections can not be closed immediately. Packets may arrive out of order or be retransmitted after the connection has been closed. CLOSE_WAIT indicates that the remote endpoint (other side of the connection) has closed the connection. TIME_WAIT indicates that local endpoint (this side) has closed the connection. The connection is being kept around so that any delayed packets can be matched to the connection and handled appropriately. The connections will be removed when they time out within four minutes. See http://en.wikipedia.org/wiki/Transmission_Control_Protocol for more details.

在 Windows 上遇到非常多 TIME_WAIT 連線時應如何處理

我們公司所代管的網站裡，有幾個流量是非常大的，在尖峰的時刻同時上線人數可能高達數千到數萬人，而在這個時候如果使用 netstat 或 TCPView 查看所有 TCP 連線時就會看到非常多處於TIME_WAIT 狀態的連線，平時就會多達數千條 TIME_WAIT 連線之多，尖峰的時候還有一萬多條TIME_WAIT 連線的狀況，雖然這些連線目前還不致於造成連線發生問題，但基於一股好奇心才決定研究到底查探個究竟，深入研究後才得知這問題現在不處理，等網站流量在大一些的時候那就會出亂子了！

以下是用 TCPView 查看連線狀況時的畫面，其中的 TIME_WAIT 狀態下的連線可能會很多：

熟悉 TCP/IP 的開發人員應該知道一台電腦可使用的 連接埠 (Ports) 是有限的，最多也只有 65536個連接埠可以使用，且不管  接收連線 (Inbound Connection) 或 發出連線 (Outbound Connections) 都需要用到連接埠，這些處於 TIME_WAIT 狀態下的連線都會各自佔用一個可分配給應用程式使用的連接埠。

注意：雖然系統總共可使用的 Ports 有 65536 個，但從本機連到外部網路(Outbound Connections)的連線埠最多只會使用到 5,000 個而已，如需增加數量可修改 MaxUserPorts 機碼值的數值。

由於 TCP 不是個三言兩語就能講清楚的傳輸協定，在這篇文章裡我只會專注在講解與 TIME_WAIT狀態有關的狀態而已，如需深入瞭解請參考本文最後的相關連結自行研究，我們先來看以下這張經典的 TCP 連線狀態圖：

從這張圖可以看出 TCP 連線在各種狀態之間變動的狀況與順序，其中 TIME_WAIT 連線已經是 TCP 連線在 完全關閉連線狀態 (CLOSED) 之前的一個狀態 (註：完全關閉連線是指網路完整斷線的意思)，而預設 TIME_WAIT 的逾時時間為 MSL (Maximum Segment Lifetime) 時間的兩倍，在RFC 793 規格定義的 MSL 為兩分鐘，也就是在預設的情況下，每一條連線從 打算關閉連線狀態(Closing) 換到 完整關閉連線狀態 (Closed) 之間還會停留在 TIME_WAIT 狀態約 4 分鐘的時間，如果你 4 分鐘以內使用者建立的連線數超過 65536 條連線的話，那麼很這台伺服器就再也無法連接了。 ( 註：Windows 預設的 TIME_WAIT 時間為 4 分鐘，Linux 下則會依據不同 Distribution 版本而有不同的預設值，但都可以調整其時間長短 )

MSL 為一個 TCP Segment (某一塊 TCP 網路封包) 從來源送到目的之間可續存的時間 (也就是一個網路封包在網路上傳輸時能存活的時間)，由於 RFC 793 TCP 傳輸協定是在 1981 年定義的，當時的網路速度不像現在的網際網路那樣發達，你可以想像你從瀏覽器輸入網址等到第一個 byte 出現要等 4 分鐘嗎？在現在的網路環境下幾乎不可能有這種事情發生，因此我們大可將 TIME_WAIT 狀態的續存時間大幅調低，好讓 連線埠 (Ports) 能更快空出來給其他連線使用。

注意：如果當系統所有可用的 連線埠 (Ports) 都用光的話，就會接收到以下錯誤訊息：WSAENOBUFS (10055) error: "An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full."

因此在流量較大的網站或伺服器，應該是要調整 Windows 預設的 TIME_WAIT 存留時間才對，如果要縮短 Windows 預設的 TIME_WAIT 狀態的續存時間可以調整以下機碼值，微軟建議最低可設定續存時間為 30 秒，而且也提到設定 30 秒應該不會出問題，因此我幾乎都只設定 30 秒而已：

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters]
"TcpTimedWaitDelay"=dword:0000001e

或可透過 reg.exe 工具直接進行機碼值設定：

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters" /v "TcpTimedWaitDelay" /t REG_DWORD /d 30 /f

調整完成後可能需要重新啟動伺服器才能讓設定生效 (註：我不知道有沒有不重開機的方法，如果有人知道麻煩留言告訴我，謝謝！)，自從我設定完這個機碼後，伺服器的連線數就明顯少了許多，因此也不用怕連接埠在短期內被用光的情況了。

心得分享

之前曾聽某些 IT 界的朋友跟我說，在 IT 這個領域裡不就是有問題就解問題嗎，至於怎麼解決問題的方法真的有這麼重要麼？有些問題 Google 一下就能找到解決方案，而且也真的有效，為什麼你還要花三倍的時間釐清所有細節呢？

書到用時方恨少，平時多研究一些與工作相關的知識細節很難說在日後會不會用到，現在學起來以後若遇到就能更快速的找到問題的癥結點，並以最快的速度解決問題，這樣才能替客戶帶來最大的價值，而且專業的價值正是出現在問題出現的時候，分析問題與解決問題是 IT 人的基本條件而已，未知的問題遲早有解決問題的一天，但你用多少時間解決問題才是 IT 人之間最主要的競爭差異。

當你手邊維護一個重要的系統時，就有可能需要花費 80% 的時間去研究 20% 罕見但可能發生的狀況，研究的方向可能會跟你過往的經驗與手邊的工作有關，我知道我們不可能學的完所有 IT 知識且在 IT 的領域裡一樣學海無崖，不過若養成研究習慣後你會發現在研究技術細節的過程中經常會獲得有許多意料之外的知識，而且這些知識有時候還真的派的上用場，我已經遇過好幾次這樣的經驗了！套一句阿甘正傳的名句：“IT is like a box of chocolates, You never know what you're gonna get.”   ^__^