《
tcp的time_wait快速**與重用》中提到了「從外部乾掉time_wait」。其實方法就是用reset來終止乙個tw狀態的連線。之所以要終止掉這個tw連線是因為某種程度上我們對無聊等待乙個行將就木的套接字的憤慨，另一方面也說明了要麼我們沒有關於old duplicate資料的概念，要麼根本就不在乎它帶來的損失，比如我們使用了ssl協議對連線進行了保護。
然而，不考慮這些額外的防護，也可以原諒我們知識的淺薄！僅僅針對tcp規範，rfc1337給出了幾個駭人聽聞的old duplicate帶來的噩夢例項值得一讀。鑑於從不深拷貝整篇rfc文件的原則，這裡就不再貼出來了，直接閱讀更好，那幾個例子也十分簡單易懂。之所以會出這種事，是因為time_wait狀態的提前終止。提前終止的原因就是傳送了乙個ack到已經不存在的連線上，進而對方反發了reset，至於說為何會傳送乙個ack，很多情況，比如收到了乙個old duplicate資料，比如收到了fin，比如收到了乙個特意構造的符合該tw套接字的資料，不一而足。
rfc1337說了這麼多令人髮指的old duplicate帶來的危害，無非就是為了找乙個為time_wait存在意義的正當辯護理由。不管怎樣，time_wait雖然很煩人，但是確實是有存在必要的。在linux上，rfc1337也就乙個配置，其實現很簡單，那就是即時收到了乙個reset也要保證time_wait狀態到底，而不是直接釋放time_wait連線。
值得注意的是，很多人都會把time_wait的目的理解為「為了阻止使用相同的ip，埠連線相同的服務」，理解為「不允許使用相同的ip，埠連線相同的服務」，這真是一派胡言！真是本末倒置！可是是聽別人說的，也可能是看書看多了！實際上time_wait的目的只有乙個，這也是協議設計者的初衷，那就是「確認老的連線所有的資料報要麼到達，要麼消失」，而這個目標在連線的established狀態是可以通過ack以及視窗機制保證的，到了最後的收尾階段，不得不使用外部物理條件，即等待msl來保證，所謂的阻止新連線並不是目的，而只是乙個結果。理解這一點非常必要，你會走出乙個誤區，即不再認為time_wait是為了阻止新連線！
既然time_wait不是為了阻止新連線，那麼只要能證明自己確實屬於新連線而不是老連線的殘留資料，那麼該連線即使匹配到了time_wait的四元組也是可以接受的，即可以重用time_wait的連線。如何來保證呢？很簡單，只需要把老的資料丟在視窗外即可。為此，只要新連線的初始序列號比老連線的fin包末尾序列號大，那麼老連線的所有資料即使遲到也會落在視窗之外，從而不會破壞新建連線！
即使不使用序列號，還是可以使用時間戳，因為tcp/ip規範規定ip位址要是唯一的，根據這個唯一性，欲重用time_wait連線的新連線的必然發自同一臺機器，而機器時間是單調遞增不能倒流的，因此只要新連線帶有時間戳且其值比老連線fin時的時間戳大，就認為該新連線是可以接受的，時間戳重用tw連線的機制的前提是ip位址唯一性匯出的發起自同一臺機器，那麼不滿足該前提的則不能基於此來重用time_wait連線，因此nat環境不能這麼做遍成了自然而然的結論。
機場安檢的目的並不是為了阻礙你登機，恰恰相反，它是為了你的安全！
關於TIME WAIT重用與RFC1337
tcp的time wait快速 與重用 中提到了 從外部乾掉time wait 其實方法就是用reset來終止乙個tw狀態的連線。之所以要終止掉這個tw連線是因為某種程度上我們對無聊等待乙個行將就木的套接字的憤慨，另一方面也說明了要麼我們沒有關於old duplicate資料的概念，要麼根本就不在乎...
唯快不破 TIME WAIT重用與RFC1337
tcp的time wait快速 與重用 中提到了 從外部乾掉time wait 其實方法就是用reset來終止乙個tw狀態的連線。之所以要終止掉這個tw連線是因為某種程度上我們對無聊等待乙個行將就木的套接字的憤慨，另一方面也說明了要麼我們沒有關於old duplicate資料的概念，要麼根本就不在乎...
關於軟體重用
在現實的大多數專案中，我們都在考慮著軟體重用的問題，因為這是在軟體開發中無法避免的乙個很現實的問題，也是乙個很讓人的頭疼的問題。下面是我對軟體重用的非常個人的理解，僅作參考。軟體重用可分為兩個層次，乙個層次是設計上的重用，另外乙個層次是 級的重用，而 級的重用上又可分細分為兩個層次，乙個是基於源 的...