?

2MSL (Maximum SegmentLifetime)?TIME_WAIT狀態(tài)的存在有兩個理由：

?

讓4次揮手關閉流程更加可靠；4次揮手的最后一個ACK是是由主動關閉方發(fā)送出去的，若這個ACK丟失，被動關閉方會再次發(fā)一個FIN過來。若主動關閉方能夠保持一個2MSL的TIME_WAIT狀態(tài)，則有更大的機會讓丟失的ACK被再次發(fā)送出去。

?

防止lost duplicate對后續(xù)新建正常鏈接的傳輸造成破壞。
lost duplicate在實際的網絡中非常常見，經常是由于路由器產生故障，路徑無法收斂，導致一個packet在路由器A，B，C之間做類似死循環(huán)的跳轉。IP頭部有個TTL，限制了一個包在網絡中的最大跳數，因此這個包有兩種命運，要么最后TTL變?yōu)?，在網絡中消失；要么TTL在變?yōu)?之前路由器路徑收斂，它憑借剩余的TTL跳數終于到達目的地。但非常可惜的是TCP通過超時重傳機制在早些時候發(fā)送了一個跟它一模一樣的包，并先于它達到了目的地，因此它的命運也就注定被TCP協(xié)議棧拋棄。

?

另外一個概念叫做incarnation connection，指跟上次的socketpair一摸一樣的新連接，叫做incarnation of previous connection。lost uplicate加上incarnationconnection，則會對我們的傳輸造成致命的錯誤。

TCP是流式的，所有包到達的順序是不一致的，依靠序列號由TCP協(xié)議棧做順序的拼接；假設一個incarnationconnection這時收到的seq=1000, 來了一個lost duplicate為seq=1000，len=1000, 則TCP認為這個lostduplicate合法，并存放入了receive buffer，導致傳輸出現(xiàn)錯誤。通過一個2MSL TIME_WAIT狀態(tài)，確保所有的lostduplicate都會消失掉，避免對新連接造成錯誤。

該狀態(tài)為什么設計在主動關閉這一方：

?

發(fā)最后ACK的是主動關閉一方。

?

只要有一方保持TIME_WAIT狀態(tài)，就能起到避免incarnation connection在2MSL內的重新建立，不需要兩方都有。

?

如何正確對待2MSL TIME_WAIT?

RFC (Request ForComments)，是一系列以編號排定的文件。收集了有關因特網相關資訊，以及UNIX和因特網社群的軟件文件。

RFC要求socket pair在處于TIME_WAIT時，不能再起一個incarnationconnection。但絕大部分TCP實現(xiàn)，強加了更為嚴格的限制。在2MSL等待期間，socket中使用的本地端口在默認情況下不能再被使用。

若A 10.234.5.5 : 1234和B 10.55.55.60 :6666建立了連接，A主動關閉，那么在A端只要port為1234，無論對方的port和ip是什么，都不允許再起服務。這甚至比RFC限制更為嚴格，RFC僅僅是要求socketpair不一致，而實現(xiàn)當中只要這個port處于TIME_WAIT，就不允許起連接。這個限制對主動打開方來說是無所謂的，因為一般用的是臨時端口；但對于被動打開方，一般是server，就悲劇了，因為server一般是熟知端口。比如http，一般端口是80，不可能允許這個服務在2MSL內不能起來。

?

解決方案是給服務器的socket設置SO_REUSEADDR選項，這樣的話就算熟知端口處于TIME_WAIT狀態(tài)，在這個端口上依舊可以將服務啟動。當然，雖然有了SO_REUSEADDR選項，但socktpair這個限制依舊存在。比如上面的例子，A通過SO_REUSEADDR選項依舊在1234端口上起了監(jiān)聽，但這時我們若是從B通過6666端口去連它，TCP協(xié)議會告訴我們連接失敗，原因為Addressalready in use.

RFC793中規(guī)定MSL為2分鐘，實際應用中常用的是30秒，1分鐘和2分鐘等。

總結

以上是生活随笔為你收集整理的TCP的2MSL问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。