TCP 應用中，如何避免客戶端發送大數據時導致心跳超時斷開連接？

客戶端主動發心跳，服務端被動回心跳。客戶端發送大數據時，心跳包堆積到發送隊列，客戶端沒有定時收到心跳反饋，斷開連接。有什麼辦法嗎？收大數據時設置反饋嗎？

客戶端發送的網路帶寬有多大？

心跳的周期是多少？

心跳超時的閾值是多少？

想想我為什麼要問以上三個問題。

跟協議有關，如果協議對分片不友好，就不能要求實時響應ping。替代的方式是只在連接空閑時發ping。當然，更好的辦法是對分片友好，這樣也方便傳輸多個並行的流

已經有 人 提過問題了。

發送隊列過長，導致心跳包很長時間發不出去，應該要檢查下網路帶寬，看看是不是帶寬不夠導致發送請求堆積在發送隊列裡面。

設計問題。心跳應該在長時間沒有通訊時才發送，用來檢測網路的可用性。客戶端和伺服器正在正常傳輸數據的時候為什麼要心跳？

難道不是伺服器收包的時候就更新時間戳嗎，

我們遇到過這個問題。

原本是：TCP連接，專門的20秒一次 keepalive，APP 檢測發送 keepalive 超過20秒沒收到keepalive則斷開連接。

後來，在網路不佳時，確實可能單個大協議阻塞超過20秒。例如，用戶手機10k上下的帶寬，單個協議超過200k。但是這種情況下，實際上會一直不斷收到數據包，只不過 APP 協議層還在等待拼裝出協議，同時 keepalive 還在排隊中。

所以，後來改成： socket 收到任意數據包，就重置心跳超時時間。

要麼把數據發送當做心跳，不在單獨發心跳請求。心跳回應就是伺服器發給客戶端，這樣客戶端收發兩不誤。