以下是用 TCPView 查看連線狀況時的畫面，其中的 TIME_WAIT 狀態下的連線可能會很多：
熟悉 TCP/IP 的開發人員應該知道一台電腦可使用的 連接埠 (Ports) 是有限的，最多也只有 個連接埠可以使用，且不管 接收連線 (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 分鐘的時間。 ( 註：Windows 預設的 TIME_WAIT 時間為 4 分鐘，Linux 下則會依據不同 Distribution 版本而有不同的預設值，但都可以調整其時間長短 )
因此在流量較大的網站或伺服器，應該是要調整 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 工具直接進行機碼值設定：
調整完成後可能需要重新啟動伺服器才能讓設定生效 (註：我不知道有沒有不重開機的方法，如果有人知道麻煩留言告訴我，謝謝！)，自從我設定完這個機碼後，伺服器的連線數就明顯少了許多，因此也不用怕連接埠在短期內被用光的情況了。
心得分享
之前曾聽某些 IT 界的朋友跟我說，在 IT 這個領域裡不就是有問題就解問題嗎，至於怎麼解決問題的方法真的有這麼重要麼？有些問題 Google 一下就能找到解決方案，而且也真的有效，為什麼你還要花三倍的時間釐清所有細節呢？
書到用時方恨少，平時多研究一些與工作相關的知識細節很難說在日後會不會用到，現在學起來以後若遇到就能更快速的找到問題的癥結點，並以最快的速度解決問題，這樣才能替客戶帶來最大的價值，而且專業的價值正是出現在問題出現的時候，分析問題與解決問題是 IT 人的基本條件而已，未知的問題遲早有解決問題的一天，但你用多少時間解決問題才是 IT 人之間最主要的競爭差異。
當你手邊維護一個重要的系統時，就有可能需要花費 80% 的時間去研究 20% 罕見但可能發生的狀況，研究的方向可能會跟你過往的經驗與手邊的工作有關，我知道我們不可能學的完所有 IT 知識且在 IT 的領域裡一樣學海無崖，不過若養成研究習慣後你會發現在研究技術細節的過程中經常會獲得有許多意料之外的知識，而且這些知識有時候還真的派的上用場，我已經遇過好幾次這樣的經驗了！套一句阿甘正傳的名句：“IT is like a box of chocolates, You never know what you're gonna get.” ^__^