TCP古董TIME_WAIT：爲何被動關閉的一方不須要TIME_WAIT傻等呢，彷佛人人都瞭然了

TIME_WAIT，是網絡高手們的必經之路，有不少文章可參考，隨便給一個我以爲寫得頗有經驗的文章：你所不知道的TIME_WAIT和CLOSE_WAIT - 老男孩教育博客。

用本身的話說，大體就是，

主動關閉鏈接的那一方呢，雖然也收到了對方的分手信號，能夠說是順利的完成了分手手續了，但是，它但仍是擔憂對方有什麼遲延數據等會兒會亂來，因此等幾十幾百秒。

• ####有道理啊，可是很傻，特別是對於Web Server這樣的被動服務來講是很傻。

反正現狀是，幾乎全部的Web Server在建立時socket server時都指定了SO_REUSEADDR標記了，部分緣由就是爲了克服這個破TIME_WAIT時不讓偵聽的毛病。不然鐵定被人投訴。同理，NodeJS之類的工具裏也是這樣處理了。

若是沒有這個標記，那常常在Debug時手動中止或者不當心死了（反正都會引起這個TIME_WAIT）後，再次啓動Web Server時，就會爆「地址有人在用了」，那誰能忍受啊。

Web Server：想開點，對本身好點，別扣着破標準了，我主動關閉了鏈接後，既然也收到了對方的結束信號了，那後面來的什麼遲延數據關我啥事兒啊，發現亂數據我就回個RST，就算是出事兒也是對方那邊出事兒。

因此呢，這麼多年過來，也沒人說Web Server和NodeJS這麼有什麼問題，那麼多高手都盯着呢。

固然，這些大白話都不是什麼嚴謹的話，扣字眼就沒完沒了了。

• ####而對於客戶端，路由器，這些東西上面的TIME_WAIT仍是不能簡單無視的，這在上面的連接文章裏有例子。

---

• ####我好奇的是，爲何被動關閉鏈接的那一方，當順利的完成了分手手續後，不進入那該死的幾十幾百秒等待狀態呢？

爲何文檔上不明確添加個說明呢，光給出個狀態圖硬說：就是這樣的狀態遷移，你愛接受不接受。

隨便給個連接：CLOSE_WAIT

猜想一下，那是由於TCP是排序處理數據的，既然都收到了主動方發出的FIN信號(就是主動方發了一堆數據後單獨發了個FIN代表完了)，那就說明主動方的全部數據都已經接收到了，不存在什麼遲到的數據的事兒了。以後一旦收到了主動方的ACK，那就OK了，乾乾淨淨分手。

猜想是猜想，可這東西又很差作實驗，不找個100%確定的文章我是不放心的，這是強迫症。

例如，若是主動方發來的FIN比以前的數據還早來，那分手以後，豈不是仍是有可能對方的數據遲遲而來？不過幸虧，TCP是檢查順序的，來早的FIN應該會被cache起來，並不馬上當真處理的。

這就是我要確認的內容，理論上顯然是沒錯的，可實際上誰知道呢，我須要一個有經驗的人的話才安心。

硬翻那協議說明的話，老是隔靴撓癢，不貼心，我就想要個人問題的答案。

還好，找到了有人明確這樣說了，我就罷休了。 TCP數據流穩定性－－TCP分片,重組及亂序 - 曉風殘夢 - 博客園

TCP協議規定，對於收到的亂序報文並不丟棄，而是緩存下來(這樣作是爲了減小更多的重傳)，當即發送但願接受的報文確認。例如：發送端A發送瞭如下幾個包：第一個：1001－1100，第二個1101－1200，第三個FIN包(序列號是1201，一個虛字節)。

1）第二個包在傳輸的過程當中丟失了，接收端收到第三個包後並不丟棄，而是緩存下來，而後，當即發送一個ACK，確認號是1101（這樣作的目的是沒必要等到發送端A的第二個包超時後重傳，發送端A收到3個一樣的ACK後當即重傳，這是快速重傳的概念）。