TCP/IP中MSL詳解

       MSL是Maximum Segment Lifetime的英文縮寫,可譯爲“最長報文段壽命”,它是任何報文在網絡上存在的最長的最長時間,超過這個時間報文將被丟棄。我們都知道IP頭部中有個TTL字段,TTL是time to live的縮寫,可譯爲“生存時間”,這個生存時間是由源主機設置設置初始值但不是但不是存在的具體時間,而是一個IP數據報可以經過的最大路由數,每經過一個路由器,它的值就減1,當此值爲0則數據報被丟棄,同時發送ICMP報文通知源主機。RFC793中規定MSL爲2分鐘,但這完全是從工程上來考慮,對於現在的網絡,MSL=2分鐘可能太長了一些。因此TCP允許不同的實現可根據具體情況使用更小的MSL值。TTL與MSL是有關係的但不是簡單的相等關係,MSL要大於TTL。

下面我們來看一張TCP連接釋放的圖:

 wKiom1c_C3zTY5p7AAIQhDP5xCk816.png

                        (此圖摘自謝希任計算機網絡第六版)

       從上圖我們注意到,在TCP連接釋放的過程中,從TIME_WAIT狀態到CLOSED狀態有一個超時設置,這個超時設置是2MSL(RFC793定義MSL爲2分鐘),那麼爲什麼在TIME_WAIT後必須等待2MSL時間呢?主要原因有兩點(在我的上一篇博客中有講,我們再來說下吧):

       1.爲了保證客戶端(我們記爲A端)發送的最後一個ACK報文段能夠到達服務器端。這個ACK報文段有可能丟失,因而使處在LASK—ACK端的服務器端(我們記爲B端)收不到對已發送的FIN+ACK報文段。B會超時重傳這個FIN+ACK報文段,而A就能在2MSL時間內收到這個重傳的FIN+ACK報文段。接着A重傳一次確認,重新啓動2MSL計時器。最後,A和B都正常進入到CLOSED狀態。如果A在TIME_WAIT狀態不等待一段時間,而是在發送完ACK確認後立即釋放連接,那麼就無法收到B重傳的FIN+ACK報文段,因而也不會再發送一次確認報文段,這樣,B就無法正常進入CLOSED狀態。

      2.我們都知道,假如A發送的第一個請求連接報文段丟失而未收到確認,A就會重傳一次連接請求,後來B收到了確認,建立了連接。數據傳輸完畢後,就釋放了連接。A共發送了兩個連接請求報文段,其中第一個丟失,第二個到達了B。假如現在A發送的第一個連接請求報文段沒有丟失,而是在某些網絡節點長時間都留了,以至於延誤到連接釋放後的某個時間纔到達B,這本來是已失效的報文段,但B並不知道,就會又建立一次連接。而等待的這2MSL就是爲了解決這個問題的,A在發送完最後一個確認報後,在經過時間2MSL,就可以使本鏈接持續時間內所產生的所有報文段都從網絡中消失,這樣就可以使下一個新的連接中不會出現這種舊的連接請求報文段。

       我們回到MSL,在2MSL時間內,該地址上的連接(客戶端地址,端口和服務器的端口地址)不能被使用,比如我們在建立一個連接後關閉連接然後迅速重啓連接,那麼就會出現端口不可用的情況。













發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章