原始的快速重傳機制

如圖所示， 客戶端與伺服器互動資料之前 首先已經將資料分割槽然後依次上傳了( 這大概是因為資料包大小的問題吧！以後我有了解了 再補充 )
假設客戶端有一個數據A要傳送給伺服器 要經歷以下步驟 (除開握手環節 這個請看我的TCP握手流程 隨筆 )

1. 將資料A 標記為 N塊 (這裡假設為5塊) 【 seq , seq , seq , seq , seq 】
2. 分好了組之後 按在循序在內部帶上 序號發給服務

3. 首先發送seq1 伺服器成功接收返回ack2

4 傳送seq2也成功 伺服器返回ack3 （意味著等著你的3號位呢）

5 傳送seq3失敗了 但是seq4成功了 伺服器還是會返回一次ack3 （雖然我收到了，但是你得3呢！~~）

6 傳送seq5成功了 但是還是返回ack3（雖然我收到5了，但是你得3呢！~~）

7 傳送seq6成功了 但是還是返回ack3（雖然我收到6了，但是你得3呢！~~）

8 客戶端：連續收到了3次提示沒有收到3 看來3真的丟包了，再發一次把 （於是客戶端有發了一次seq3 ）

9 伺服器: 你總算給我把3交出來了，我看看現在有最大到多少序號了 哦 是6呀 給你發個ack7找你要7 你要是沒有了就算了

缺點： 很明顯，如果出現多個連續丟包情況 無法識別 假如3丟失了 4也丟失了 但是 伺服器只會返回ack3 一旦客戶端補充了3 但是 成功了5,6的話 就會導致返回ack7 中間的4就徹底丟失了 再就是客戶端會連續收到3次的提示沒有3才會再次重發（因為有可能3的請求被4超車了也有可能的），導致如果這次丟失情況靠末尾最後可能會因為沒有返回徹底丟包 (這是我的理解，有錯誤望指出)

SACK 帶確認的重傳機制

這個機制和原始機制才用的互動形式還是一樣的 只是傳遞的引數發生了變化 一旦發生了丟包行為 就會在下一次成功中返回一個SACK資料，這個資料表明了除開ackX 丟包的位置以外成功的位置範圍例如上圖的 ACK30,SACK=40~50 就說嘛丟失的為30號 但是後面成功的序號為40~50, 哪怕後面的繼續成功 ack30也不會變但是sack的成功範圍會增加變為40~60;

優點：記錄了成功的資料請求可以讓客戶端知道具體差了那

缺點：還是無法處理重複傳值情況，(如果說伺服器收到資料給與返回資訊的時候資訊丟失了，客戶端無法就會因為沒有收到回覆，進入超時重傳流程，資料會多次傳送，為了解決這個情況 於是就出現了 D-SACK機制)

D-SACK 機制

D-SACK機制實際上只是收到重複資料之後會返回一個除開當前缺少的序列 ack30之後的範圍 40~50 還會在前面加上 30之前已經有的範圍 SACK 10~20 40~50 (只是少了30 ~ 39) 其餘的都有了 你別傳了

額 應該算是講的很清楚了吧！~~~