根據TCP協議，主動發起關閉的一方，會進入TIME_WAIT狀態，持續2*MSL(Max Segment Lifetime)，預設為240秒，在這個post中簡潔的介紹了為什麼需要這個狀態。

值得一說的是，對於基於TCP的HTTP協議，關閉TCP連線的是Server端，這樣，Server端會進入TIME_WAIT狀態，可 想而知，對於訪問量大的Web Server，會存在大量的TIME_WAIT狀態，假如server一秒鐘接收1000個請求，那麼就會積壓240*1000=240，000個 TIME_WAIT的記錄，維護這些狀態給Server帶來負擔。當然現代作業系統都會用快速的查詢演算法來管理這些TIME_WAIT，所以對於新的 TCP連線請求，判斷是否hit中一個TIME_WAIT不會太費時間，但是有這麼多狀態要維護總是不好。

HTTP協議1.1版規定default行為是Keep-Alive，也就是會重用TCP連線傳輸多個 request/response，一個主要原因就是發現了這個問題。還有一個方法減緩TIME_WAIT壓力就是把系統的2*MSL時間減少，因為 240秒的時間實在是忒長了點，對於Windows，修改登錄檔，在HKEY_LOCAL_MACHINE/ SYSTEM/CurrentControlSet/Services/ Tcpip/Parameters上新增一個DWORD型別的值TcpTimedWaitDelay，一般認為不要少於60，不然可能會有麻煩。

對於大型的服務，一臺server搞不定，需要一個LB(Load Balancer)把流量分配到若干後端伺服器上，如果這個LB是以NAT方式工作的話，可能會帶來問題。假如所有從LB到後端Server的IP包的 source address都是一樣的(LB的對內地址），那麼LB到後端Server的TCP連線會受限制，因為頻繁的TCP連線建立和關閉，會在server上留 下TIME_WAIT狀態，而且這些狀態對應的remote address都是LB的，LB的source port撐死也就60000多個(2^16=65536,1~1023是保留埠，還有一些其他埠預設也不會用），每個LB上的埠一旦進入 Server的TIME_WAIT黑名單，就有240秒不能再用來建立和Server的連線，這樣LB和Server最多也就能支援300個左右的連線。 如果沒有LB，不會有這個問題，因為這樣server看到的remote address是internet上廣闊無垠的集合，對每個address，60000多個port實在是夠用了。

一開始我覺得用上LB會很大程度上限制TCP的連線數，但是實驗表明沒這回事，LB後面的一臺Windows Server 2003每秒處理請求數照樣達到了600個，難道TIME_WAIT狀態沒起作用？用Net Monitor和netstat觀察後發現，Server和LB的XXXX埠之間的連線進入TIME_WAIT狀態後，再來一個LB的XXXX埠的 SYN包，Server照樣接收處理了，而是想像的那樣被drop掉了。翻書，從書堆裡面找出覆滿塵土的大學時代買的《UNIX Network Programming, Volume 1, Second Edition: Networking APIs: Sockets and XTI》，中間提到一句，對於BSD-derived實現，只要SYN的sequence number比上一次關閉時的最大sequence number還要大，那麼TIME_WAIT狀態一樣接受這個SYN，難不成Windows也算BSD-derived?有了這點線索和關鍵字 (BSD)，找到

做個試驗，用Socket API編一個Client端，每次都Bind到本地一個埠比如2345，重複的建立TCP連線往一個Server傳送Keep-Alive=false 的HTTP請求，Windows的實現讓sequence number不斷的增長，所以雖然Server對於Client的2345埠連線保持TIME_WAIT狀態，但是總是能夠接受新的請求，不會拒絕。那 如果SYN的Sequence Number變小會怎麼樣呢？同樣用Socket API，不過這次用Raw IP，傳送一個小sequence number的SYN包過去，Net Monitor裡面看到，這個SYN被Server接收後如泥牛如海，一點反應沒有，被drop掉了。

按照書上的說法，BSD-derived和Windows Server 2003的做法有安全隱患，不過至少這樣至少不會出現TIME_WAIT阻止TCP請求的問題，當然，客戶端要配合，保證不同TCP連線的sequence number要上漲不要下降。