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