RT.
TCP協議既然自身是可靠性協議，在資料包沒有得到相應時會超時定時重發。
那么為什么經常在做業務時，需要在上層再做一次確認收到和重發機制？
求解釋！謝謝！
另外，TCP的重發機制是定時多次重發。那么這個多次有上限嗎？我認為應該肯定有一個上限的吧？
不會一直重發！
求驗證！
uj5u.com熱心網友回復：
TCP 是可靠的，如果可以知道發送成功還是失敗。如果發送失敗業務需要重發則重發UPD是不可靠的，發送成功失敗是未知的，所以需要接收方業務上告訴發送方是否成功。
uj5u.com熱心網友回復：
個人的一點淺見：
1. 應用層可能需要根據回執進行時序控制、流程控制等。例如，需要收到對流水號N的回執后，再發送下一幀N+1，這樣能起到流量控制的作用，最主要的便于接收端分幀處理
2. 傳輸層能最大程度保證要發送的內容正確到達對端，但不能保證應用層投遞的內容是正確的，例如發送長度為L的訊息到對端，實際上只發送了長度為4的訊息或者發送了別的訊息，此時應用層必須接入，通過CRC校驗等方法，確保發送的內容是對的
傳輸層協議的不同只決定了傳輸通道的可靠性程度，不代表通道上傳輸的內容一定是正確和期望的
uj5u.com熱心網友回復：
TCP發送端沒有收到確認報文，就會認為資料丟失，觸發重傳機制。頻繁觸發重傳，會引起整體帶寬利用率降低，也就是TCP同步
uj5u.com熱心網友回復：
有些是邏輯上的錯誤導致重發，而不是因為傳輸上的錯誤。再說，寫代碼的不一定理解TCP/IP
uj5u.com熱心網友回復：
TCP重傳當然也是有上限的，而且TCP的超時重傳機制也很有意思，具體可以https://blog.csdn.net/xiongyingzhuantu/article/details/39926325細看簡單點說就是第一次超時后，很快就會重發一個報文；第二次超時后，過一會重發一個報文（中間延時比上一次長）....第n次超時后，回傳TCP傳輸失敗
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/101228.html
標籤：網絡協議與配置