應用層設定週期性的心跳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的命運,可以從上文找原因。
應用層設定週期性的心跳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的命運,可以從上文找原因。