在這裡我們介紹rdt（reliable data transfer）協議，即可靠資料傳輸協議的逐步完善。
我們首先考慮最簡單的情況，即底層通道完全可靠，不會發生錯誤，此時將協議定為rdt1.0。此時傳送方和接受方的狀態如下。
rdt1.0傳送方
傳送方僅有乙個狀態，通過rdt_send來接受高層的資料，進行分路復用，將packet傳送至接收方。rdt1.0接收方
接收方也只有乙個狀態，它通過rdt_rcv從較底層接收packet，進行分路分解,將data傳送到較高層。
在底層通道傳輸的過程中，實際上分組中的位元可能受損。若還是像rdt1.0那樣是無法保證運輸的都是沒有出位元差錯的資訊的。
為了解決這個問題我們還需要另外三種協議來處理這種差錯:
1.差錯檢測：我們需要一種機制來檢測我們什麼時候出現了位元差錯。2.接受方反饋：傳送方和接受方不在同乙個系統上執行，若是接受方檢測到錯誤後不作出反饋，那麼傳送方並不知道自己傳輸的過程中出現了位元差錯。我們引入了肯定確認(ack)和否定確認(nak)來反饋。我們的rdt2.0從接收方向像傳送方會送ack和nak分組來表示是否發生差錯。
3.重傳：如果發生位元差錯，傳送方需要進行一次重傳。
rdt2.0傳送方
rdt2.0傳送與rdt1.0的不同點在於，傳送方多了乙個等待ack的狀態，並且不只是單純的將data進行make_pkt操作，而是計算出校驗和，在原來packet的基礎上加上校驗位，產生新的sndpkt，可以讓接收方實現校驗功能。
rdt2.0接收方
與以前相比，接收方會將接收的sndpkt進行校驗，並向傳送方反饋。
但是有一點我們需要考慮，接收方發出的反饋也有位元差錯的可能性。因此反饋也應當加上校驗供傳送方檢查。而需要解決的問題是：接收方應當怎麼樣才能確認自己傳送的反饋傳送了錯誤，而傳送方發給自己的是一次重傳而不是下乙個分組呢。我們解決這個問題的方法是為資料分組新增新的字段—-序號。於是接收方只需要檢查序號便知道確認是否是一次重傳。
rdt2.1傳送方
可以發現傳送多了兩個狀態，並且在傳送的sndpkt中加入了序號來表示是哪一次傳送的分組，且ack和nak也進行了校驗檢測，判斷是否有位元錯誤。
rdt2.1接收方
若是在等待時，傳來的分組與自己想要等待的不同，那麼可以確定，這是傳送方發來的重傳，我們需要再次檢驗並且反饋。
在原來的基礎上，我們因為序號的引入。從而可以不傳送nak也能夠確認是否需要重傳。傳送方如果接受到了對同乙個分組的兩個ack（即冗餘ack）後，就知道接收方沒有正確接受到跟在被確認兩次分組後面的分組。rdt2.2是具有位元差錯通道上實現的無nak的可靠運輸協議。變化在於接收方必須包括乙個ack報文確認的分組序號，傳送方必須檢查收到的ack的序號來處理冗餘分組情況。
rdt2.2傳送方
rdt2.2接收方
從傳送方的觀點來看，重傳是一種萬能的方法。傳送方不知道是乙個資料分組的丟失,ack丟失還是過度的時延。在所有的情況下，傳送方的解決方案都是一樣的，那就是重傳。為了實現基於時間的重傳機制，我們需要乙個倒計時定時器。在乙個給定的時間過期後，可以中斷傳送方。傳送方需要滿足幾點要求：
1.每次傳送一次分組，便啟動乙個定時器。2.響應定時器的中斷
3.終止定時器
rdt3.0傳送方
在這裡歸納我們所用到的要點。校驗和，序號，定時器，肯定確認和否定確認，這些機制的共同合作下終於得到了乙個有效的可靠資料傳輸協議！雖然是乙個停等協議（每傳送完乙個分組就停止傳送，等待對方的確認。在收到確認後再傳送下乙個分組），但為tcp協議的完善建立了基礎。
若是用停等協議，完全可以想象，這樣對於傳送方的利用率將極低，因為總是處於等待的狀態下。效能根本無法滿足我們的需要，若是我們要解決這個問題，我們就不應該採用停等的方式來執行，應當允許傳送方傳送多個分組而不需等待確認。
若要完成這一需求：
1.必須增加序號的範圍，因為每乙個傳輸的分組都必須有乙個唯一的序號。2.協議的傳送方和接收方必須快取多個分組。
3.對處理丟失，損壞以及過度延時分組的解決方案。
可靠傳輸資料概述之RDT到滑動視窗協議的發展
主要思想是有限狀態機。rdt1.0 rdt1.0是模擬通道可靠的情況下。rdt1.0存在的問題 通道完全可靠是理論的模型 rdt2.0 rdt2.0是模擬通道不可靠的情況下 資料位翻轉，但不丟失分組 解決資訊傳送接收的問題，加入checksum校驗位。傳送方在傳送完成後會進入乙個等待確認的狀態，當收...
對rdt傳輸協議的形象化理解
1.rdt1.0 這個版本的rdt協議就像傳統的老師給你講課，傳送方只用傳送資料，就像老師滔滔不絕，接收方只用接收資料，就像你在底下努力的往自己的小腦瓜裡塞知識，至於塞不塞的進，有沒有接收到老師的話，老師也不管，他會假設你們都聽進去了，就像rdt1.0假設通道是安全的一樣，具體的原理圖如下 這個版本...
運輸層 流水線可靠資料傳輸協議
禁止碼迷，布布扣，豌豆 碼農教程，愛碼網等第三方爬蟲 爬取！目錄選擇重傳 參考資料 我們來考慮位元交替協議，會發現由於協議需要等待 ack，中間的等待時間內傳送端和接收端都是無所事事的。根據分析，我們可以計算出位元交替協議的通道利用率，我們會發現這個量級是十分可憐的。而且我們還忽略了傳送方和接收方的...