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