參考自：http://blog.csdn.net/hguisu/article/details/10241519
TIME-WAIT狀態存在的理由
(1)可靠地實現TCP全雙工連接的終止：（即在TIME_WAIT下等待2MSL，只是為了盡最大努力保證四次握手正常關閉）。
客戶端進入發送收到四次握手關閉的最后一個ACK后，進入TIME_WAIT同時發送ACK，如果其不停留2MSL時間，而是馬上關閉連接，銷毀連接上的資源，當發送如下情況時，將不能正常的完成四次握手關閉：
客戶端發送的ACK在網路上丟失，這樣服務器端收不到最后的ACK，重傳定時器超時，將重傳FIN到客戶端，由于客戶端關于該連接的所有資源都釋放，收到重傳的FIN后，它沒有關于這個FIN的任何信息，所以向服務器端發送一個RST報文端，服務器端收到RST后，認為搞連接出現了異常（而非正常關閉）。
所以，在TIME_WAIT狀態下等待2MSL時間端，是為了能夠正確處理第一個ACK（最長生存時間為MSL）丟失的情況下，能夠收到對端重傳的FIN（最長生存時間為MSL），然后重傳ACK。
是否只要主動關閉方在TIME_WAIT狀態下停留2MSL，四次握手關閉就一定正常完成呢？
答案是否定的？可以考慮如下的情況，
TIME_WAIT狀態下發送的ACK丟失，LAST_ACK時刻設定的重傳定時器超時，發送重傳的FIN，很不幸，這個FIN也丟失，主動關閉方在TIME_WAIT狀態等待2MSL沒收到任何報文段，進入CLOSED狀態，當此時被動關閉方并沒有收到最后的ACK。所以即使要主動關閉方在TIME_WAIT狀態下停留2MSL，也不一定表示四次握手關閉就一定正常完成。
**(2)確保老的報文段在網絡中消失，不會影響新建立的連接 **
考慮如下的情況，主動關閉方在TIME_WAIT狀態下發送的ACK由于網絡延遲的原因沒有按時到底（但并沒有超過MSL的時間），導致被動關閉方重傳FIN，在FIN重傳后，延遲的ACK到達，被動關閉方進入CLOSED狀態，如果主動關閉方在TIME_WAIT狀態下發送ACK后馬上進入CLOSED狀態（也就是沒有等待）2MSL時間，則上述的連接已不存在;
現在考慮下面的情況，假設客戶端（192.186.0.1:23） 到服務器192.168.1.1:6380）的TCP連接, 由于連接已關閉，我們可以馬上建立一個相同的IP地址和端口之間的TCP連接，并且這個連接也是客戶端（192.186.0.1:23） 到服務器192.168.1.1:6380），那么當上一個連接的重傳FIN到達主動關閉方時，被新的連接所接受，這將導致新的連接被復位，很顯然，這不是我們希望看到的事情。
新的連接要建立，必須是在主動關閉方和被動關閉方都進入到CLOSED狀態之后才有可能。所以，最有可能導致舊的報文段影響新的連接的情況是：
在TIME_WAIT狀態之前，主動關閉方發送的報文端在網絡中延遲，但是TIME_WAIT設定為2MSL時，這些報文端必然會在網絡中消失（最大生存時間為MSL）。被動關閉方最有可能影響新連接的報文段就是我們上面討論的情況，對方ACK延遲到達，在此之前重傳的FIN,這個報文端發送之后，TIME_WAIT的定時器超時時間肯定大于MSL，在1MSL時間內，這個FIN要么在網絡中因為生成時間到達而消失，要么到達主動關閉方被這確的處理，不會影響新建立的連接。
