計算機網絡基礎(十七)---傳輸層-TCP的可靠傳輸

文章內容概覽

建議結合個人上一篇文章來看本篇內容：可靠傳輸的基本原理

TCP協議的可靠傳輸

• TCP的可靠傳輸是基於連續ARQ協議的（關於ARQ協議，能夠看個人上一篇文章）
• ARQ協議中有兩個重要的概念：滑動窗口和累計確認。這兩個概念在TCP的可靠傳輸中一樣適用
• TCP的滑動窗口以字節爲單位

假設有一段的字節流須要傳輸，滑動窗口的大小爲7，這裏是爲了方便理解，因此窗口設的很小，實際狀況下的窗口是很大的。窗口中的7個字節表示都是能夠傳輸的，窗口左邊的是已經確認的字節序號，窗口右邊的是不容許發送的字節序號。圖中的23表示的就是對方期待接收到的下一個字節，其實也就是TCP首部中的確認號的概念

假如在某一個時刻23~26這四個字節已經發送出去了，可是沒有收到確認信息，這個就屬於已發送但未確認的字節。而窗口中剩下的三個字節就屬於可用窗口，也就是後邊三個字節是能夠發送的。可是，由於發送出去的四個字節尚未收到確認，因此窗口還不能向後移動。假設通過一段時間以後，收到了2三、24這兩個字節的確認信息，此時就能夠將窗口向後移動兩個字節

假設窗口中的7個字節都已經發送出去了，可是一個確認信息都沒有收到，此時可用的窗口是0，由於窗口中全部發送的字節都沒有收到確認，這個時候，滑動窗口不能向後推動。這是實際可能存在的狀況

假設窗口中的7個字節都已經發送出去了，在某一個時刻，收到了25和27這兩個字節的確認信息。能夠發現，這種狀況，確認信息並非按窗口中字節的順序收到的，此時該怎麼辦？

首先能夠知道的是，2三、24這兩個字節的確認信息是沒有收到的，所以，窗口是不能往前推進的。假設如今超時時間已經到了，而2三、24尚未收到確認消息，此時會怎麼辦？這種狀況下，即便2五、27這兩個字節的確認信息已經收到了，可是，此時仍是會從23開始重傳消息，由於2三、24的確認信息尚未收到。所以，超時以後，會從23開始重發消息，即便收到了後邊字節的確認消息也沒有用，這個就屬於TCP協議的可靠傳輸

從上邊能夠知道，若是窗口中的字節沒有按序收到確認信息，那麼超時以後就會對窗口中的字節進行從新發送。由此也能夠看到，TCP的這種可靠傳輸，效率並非很高，由於已經收到了2五、27這兩個字節的確認信息，意思就是這兩個字節是準確的到達了接收方的，可是因爲2三、24這兩個前邊的字節沒有收到確認信息，超時以後，仍是須要對2五、27進行傳輸，這樣就致使可重傳的效率並不高。有沒有辦法能夠提升這個效率？

選擇重傳

選擇重傳，顧名思義，就是能夠選擇一部分消息進行重傳，而不是將窗口中全部的消息進行從新傳輸

選擇重傳是如何進行工做的？

• 選擇重傳須要指定須要重傳的字節
• 每個字節都有惟一的32位序號（這個在TCP首部中，選擇重傳會指定這個32位序號是什麼）

（建議在看後邊的內容以前，回看一遍TCP頭部的內容，這樣理解下邊內容會更加的容易）

對於TCP首部，其實咱們知道它並無存儲選擇重傳指定字節的位置。每個字節都有一個惟一的序號，因此在存儲須要選擇重傳的字節的序號時，也是須要耗費不少的空間的。所以，在實際的選擇重傳中，這個數據其實是存儲在TCP選項中的

在TCP協議詳解的文章中有進行過簡單的計算，知道了TCP選項最多有40個字節。由於一個序號是佔用4個字節，那也就是說，TCP選項中最多能夠放10個序號。那是否是表示，選擇重傳只能重傳10個字節？

其實並非的，在瞭解TCP的時候知道，TCP的報文，一次是能夠傳輸不少個字節的，前邊的例子主要是爲了方便對TCP可靠傳輸進行理解，才把每次能夠傳輸的字節數設置的不多。對於實際的TCP傳輸，它一次能夠傳輸上百或上千個字節

所以，這裏邊的序號並非說選擇指定某一個字節的。由於，若是發生出錯了，極可能整個TCP報文都丟失了，這種狀況其實就連續的丟掉一段的字節，所以，這裏的選擇重傳，更多的狀況是對一段字節來進行重傳的。因此這個時候序號所表達的意思，通常都是須要重傳的邊界

看個例子，假設要傳送1000~3500這麼多字節的數據，把500個字節看作是一個TCP報文。假設1000~1500範圍字節的TCP報文丟失了，這個時候就能夠指定兩個邊界，分別是1000和1500，將他們存儲到TCP首部中的TCP選項中，表示1000~1500這麼多個字節，都是須要從新傳輸的。所以，此時TCP選項中的1000和1500並非指重傳1000和1500這兩個序號的字節，而是重傳1000到1500這個範圍中的全部字節

若是看完對你有幫助，辛苦給個三連鼓勵一下哦！