逐步解決可靠運輸

在這裡我們介紹rdt（Reliable Data Transfer）協議，即可靠資料傳輸協議的逐步完善。

假如底層通道完全可靠(rdt1.0)

我們首先考慮最簡單的情況，即底層通道完全可靠，不會發生錯誤，此時將協議定為rdt1.0。此時傳送方和接受方的狀態如下。
rdt1.0傳送方

傳送方僅有一個狀態，通過rdt_send來接受高層的資料，進行分路複用，將packet傳送至接收方。rdt1.0接收方

接收方也只有一個狀態，它通過rdt_rcv從較底層接收packet，進行分路分解,將data傳送到較高層。

引入位元差錯(rdt2.0)

在底層通道傳輸的過程中，實際上分組中的位元可能受損。若還是像rdt1.0那樣是無法保證運輸的都是沒有出位元差錯的資訊的。
為了解決這個問題我們還需要另外三種協議來處理這種差錯:

1.差錯檢測：我們需要一種機制來檢測我們什麼時候出現了位元差錯。
2.接受方反饋：傳送方和接受方不在同一個系統上執行，若是接受方檢測到錯誤後不作出反饋，那麼傳送方並不知道自己傳輸的過程中出現了位元差錯。我們引入了肯定確認(ACK)和否定確認(NAK)來反饋。我們的rdt2.0從接收方向像傳送方會送ACK和NAK分組來表示是否發生差錯。
3.重傳：如果發生位元差錯，傳送方需要進行一次重傳。

rdt2.0傳送方

rdt2.0傳送與rdt1.0的不同點在於，傳送方多了一個等待ACK的狀態，並且不只是單純的將data進行make_pkt操作，而是計算出校驗和，在原來packet的基礎上加上校驗

與以前相比，接收方會將接收的sndpkt進行校驗，並向傳送方反饋。

但是有一點我們需要考慮，接收方發出的反饋也有位元差錯的可能性。因此反饋也應當加上校驗供傳送方檢查。而需要解決的問題是：接收方應當怎麼樣才能確認自己傳送的反饋傳送了錯誤，而傳送方發給自己的是一次重傳而不是下一個分組呢。我們解決這個問題的方法是為資料分組新增新的欄位—-序號。於是接收方只需要檢查序號便知道確認是否是一次重傳。
rdt2.1傳送方 

可以發現傳送多了兩個狀態，並且在傳送的sndpkt中加入了序號來表示是哪一次傳送的分組，且ACK和NAK也進行了校驗檢測，判斷是否有位元錯誤。
rdt2.1接收方

若是在等待時，傳來的分組與自己想要等待的不同，那麼可以確定，這是傳送方發來的重傳，我們需要再次檢驗並且反饋。

在原來的基礎上，我們因為序號的引入。從而可以不傳送NAK也能夠確認是否需要重傳。傳送方如果接受到了對同一個分組的兩個ACK（即冗餘ACK）後，就知道接收方沒有正確接受到跟在被確認兩次分組後面的分組。rdt2.2是具有位元差錯通道上實現的無NAK的可靠運輸協議。變化在於接收方必須包括一個ACK報文確認的分組序號，傳送方必須檢查收到的ACK的序號來處理冗餘分組情況。 
rdt2.2傳送方 
rdt2.2接收方 

引入丟包(rdt3.0)

從傳送方的觀點來看，重傳是一種萬能的方法。傳送方不知道是一個數據分組的丟失,ACK丟失還是過度的時延。在所有的情況下，傳送方的解決方案都是一樣的，那就是重傳。為了實現基於時間的重傳機制，我們需要一個倒計時定時器。在一個給定的時間過期後，可以中斷髮送方。傳送方需要滿足幾點要求：

1.每次傳送一次分組，便啟動一個定時器。
2.響應定時器的中斷
3.終止定時器

rdt3.0傳送方 

在這裡歸納我們所用到的要點。校驗和，序號，定時器，肯定確認和否定確認，這些機制的共同合作下終於得到了一個有效的可靠資料傳輸協議！雖然是一個停等協議（每傳送完一個分組就停止傳送，等待對方的確認。在收到確認後再發送下一個分組），但為TCP協議的完善建立了基礎。

流水線可靠資料傳輸運輸協議

若是用停等協議，完全可以想象，這樣對於傳送方的利用率將極低，因為總是處於等待的狀態下。效能根本無法滿足我們的需要，若是我們要解決這個問題，我們就不應該採用停等的方式來執行，應當允許傳送方傳送多個分組而不需等待確認。
若要完成這一需求：

1.必須增加序號的範圍，因為每一個傳輸的分組都必須有一個唯一的序號。
2.協議的傳送方和接收方必須快取多個分組。
3.對處理丟失，損壞以及過度延時分組的解決方案。