回覆列表
  • 1 # 使用者4694372508781

    應用層設定週期性的心跳Keepalive,這些keepalive在TCP的眼中,那就是application data,毫無疑問,一旦這些keepalive在超時時間內沒有收到對方TCP的ACK,就會繼續重傳,至於重傳的上限次數是多少,這要看具體的TCP協議的實現,一般至少重傳8次,越往後重傳的時間間隔將越來越大,這樣可以避免網路重新收斂對TCP連線的短期影響。

    上文最後這句話有點難以理解,它的意思是,當前使用的路徑即使斷了,路由協議會動態選擇新的物理鏈路,那麼後續的TCP重傳報文會使用新的鏈路到達目的地,這樣就避免了TCP超時斷開的風險。

    所以,並不是說只有TCP斷開重連才會選擇更優路徑,行動網路IP層會實時更新最新的、最優路徑,這是TCP報文所依賴的IP網路平臺的特性,無論你喜歡或不喜歡,它一直就是這樣的表現形式!

    接下來多些一點內容有助於讀者理解TCP長連線。

    TCP長連線的存在可以最佳化客戶端訪問伺服器的訪問效率。如果沒有TCP長連線,客戶端每次訪問伺服器,都要三次握手,平添了1.5RTT時間延遲。

    而TCP長連線如果存在,客戶端可以節省建立TCP連線的時間 = 1.5RTT。

    但凡事有利必有弊,TCP長連線的存在,如果沒有資料的重新整理,至少存在1個風險:行動網路使用了NAT技術。換句話說,TCP長連線在NAT裝置上,是以一個NAT表項條目存在著,這個條目是有壽命的,如果沒有資料的重新整理,一般2-20分鐘不等會被刪除。

    不會!

    NAT裝置如何處理?

    丟!

    但是週期性的心跳並不是萬能的,比如以下情況的發生:

    (1) 網路擁塞

    重傳的心跳報文被一次次無情丟棄

    (2) NAT裝置重啟

    NAT條目消失

    (3) 伺服器重啟

    TCP四元組消失

    (4) 網路環路

    心跳報文永遠無法到達伺服器

    (5) 網路收斂緩慢

    TCP報文一直被丟,一直到TCP被Reset也沒有恢復

    當TCP長連線即使配置了心跳,也沒有逃脫被Reset的命運,可以從上文找原因。

  • 中秋節和大豐收的關聯?
  • 鹽飯的做法?