采用TCP時，應用層需要超時重傳嗎？

需要，原因如下：

1tcp的超時控制不是你能設置的，所有的tcp超時都是用系統的時間設定，而且這個時間很長，超時的結果就是斷開連接。和你應用要達到的目的顯然差很遠

2send的返回OK!=數據被對方成功收到，且，數據被對方成功受到!=數據被對方邏輯成功處理

舉個極端的例子：
對方收到包，但是還沒來的及處理，程序崩掉了，這個時候你的網絡層顯示的顯然是對方收到了（確實也是對方收到了），但是對方并沒有正確處理這個包，這個時候從邏輯上講，你應該需要重發的，保證對方正確處理完畢。

3如果底層通信質量不好，TCP可能會斷鏈重連，或者序號檢測發現異常重置序號。這些情況下TCP層都會丟幀，應用層如果有重要的消息還是要自己做重傳。

TCP協議本身是可靠的，它的重傳機制保證了消息的可送達性（如果沒有收到對端的ACK確認，它會在等待一定時間后，嘗試再次發送，且這是一個循環過程，上限是9分鐘。超過9分鐘，則認為連接已經斷開，關閉socket）。
雖然有了TCP的可靠性保證，但是很多基于TCP的應用間通信依然會采用RETRY機制：發送消息后，如果在一定時間內沒有收到對端的確認消息，則重發消息。明明TCP已經可以保證消息的可送達，為什么還要在應用層加這么一層實現呢？

1. 有些服務進程，基于性能或是內存容量方面的考慮，使用了限長的消息隊列：如果收到的瞬時消息過多，超過了消息隊列的可處理個數，所有超出的消息會被它丟棄。注意，在這種情況下，TCP確實是將消息成功送達了，只是應用層不接受而已。客戶進程等待一小段時間，嘗試再次發送，有可能此時服務端的處理壓力已經降下來了，消息就能被處理了。

2. 進入了弱網環境的移動應用，發送超時往往意味著已經斷連。此時的RETRY，在底層意味著重新連接，然后再次發送消息。

其他：進入了弱網環境的移動應用，可能會給用戶帶來不大順暢的使用體驗。當用戶發送了一條消息，與其讓用戶等待9分鐘才得知消息未能送達，不如在應用層設置超時重傳，一旦超過規定時間（比如20s），則直接告知用戶，當前網絡狀況不佳，不妨晚些時候再嘗試發送。

總結

以上是生活随笔為你收集整理的tcp 重发 应用层重传的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。