溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
圖1：TCP 套接字的數據交流進程
上圖給出了主機A分2次（分2個數據包）向主機B傳遞200字節的進程。起首，主機A經過1個數據包發送100個字節的數據，數據包的 Seq 號設置為 1200。主機B為了確認這一點，向主機A發送 ACK 包，并將 Ack 號設置為 1301。
為了包管數據精確抵達，目的機械在收到數據包（包含SYN包、FIN包、通俗數據包等）包后必需立刻回傳ACK包，如許發送剛才能確認數據傳輸勝利。
此時 Ack 號為 1301 而不是 1201，緣由在于 Ack 號的增量為傳輸的數據字節數。假定每次 Ack 號不加傳輸的字節數，如許固然可以確認數據包的傳輸，但無法明白100字節全體準確傳遞照樣喪失了一局部，比方只傳遞了80字節。因而按如下的公式確認 Ack 號：
Ack號 = Seq號 + 傳遞的字節數 + 1
與三次握手協定相反，最初加 1 是為了通知對方要傳遞的 Seq 號。
下面剖析傳輸進程中數據包喪失的狀況，如下圖所示：
圖2：TCP套接字數據傳輸進程中發作毛病
上圖表現經過 Seq 1301 數據包向主機B傳遞100字節的數據，但兩頭發作了毛病，主機B未收到。經由一段工夫后，主機A仍未收到關于 Seq 1301 的ACK確認，因而測驗考試重傳數據。
為了完成數據包的重傳，TCP套接字每次發送數據包時都邑啟動準時器，假如在必定工夫內沒有收到目的機械傳回的 ACK 包，那么準時器超時，數據包會重傳。
上圖演示的是數據包喪失的狀況，也會有 ACK 包喪失的狀況，一樣會重傳。
這個值太大了會招致不用要的等候，太小會招致不用要的重傳，實際上最好是收集 RTT 工夫，但又受制于收集間隔與瞬態時延變更，所以實踐上運用自順應的靜態算法（例如 Jacobson 算法和 Karn 算法等）來肯定超不時間。
往復工夫（RTT，Round-Trip Time）表現從發送端發送數據開端，到發送端收到來自接納端的 ACK 確認包（接納端收到數據后便立刻確認），總共閱歷的時延。
TCP數據包重傳次數依據零碎設置的分歧而有所差別。有些零碎，一個數據包只會被重傳3次，假如重傳3次后還未收到該數據包的 ACK 確認，就不再測驗考試重傳。但有些請求很高的營業零碎，會不時地重傳喪失的數據包，以盡最大能夠包管營業數據的正常交互。
最初需求闡明的是，發送端只要在收到對方的 ACK 確認包后，才會清空輸入緩沖區中的數據。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
