rdt 可靠資料傳輸協定

由於運輸層(transport)的下面那一層~網路層(network)的傳輸很不可靠，所以我們想了個rdt這個辦法來解決資料資料在運輸過程遺失或是錯誤。這裡就從簡單版本到複雜版本循序來說明。

看看下圖，

sender端是called from above，意思是在傳送端，上層的訊息往下傳，receiver端就是called from below，從下面來的資料往上傳。

開始之前的行前通知

如下圖，我們等等用FSM 來說明rdt

說明:有event觸發，使state(狀態)改變，圖中event下面一條橫線後就是action(伴隨的動作)

rdt1.0

最理想的假設(也最不切實際)，rdt1.0假設下面的傳輸非常可靠，不會出錯或是資料遺失的發生。
如圖，虛線箭頭指的是初始狀態，sender等上面的資料傳上來，傳完訊息下去就回原狀態；receiver等待下方訊息到來，收完訊息之後往上傳完就回原狀態。

rdt2.0

該假設中有考慮到flip bits的出現，我們用checksum來偵錯。
問題是我們如果找到錯要怎麼處理?這時我們有了回饋機制，正確無誤時receiver傳"ACK"(acknowledgement)；錯誤時傳"NAKs"(也稱"NACKs")，一旦接收NACKs，sender就重傳該錯誤封包。

下圖是rdt2.0的互動:

有沒有想過，如果傳送過程中，回饋也有可能出錯?rdt2.0只有考慮到sender可能出錯，但是沒有考慮receiver出錯!

要解決這個問題，出現了rdt2.1!

注:sender傳送之後等待receiver這樣的行為叫作"stop and wait"!

rdt2.1

它是怎麼解決2.0的回饋時出現錯誤呢?
ACK或NACK 出錯時，只要sender看不懂，sender就會重傳該封包，如果是NACK發生錯誤還好，但如果是ACK發生錯誤，receiver不就重複收到兩個一樣的封包嗎?事實上在rdt2.1有料到這件事情，因此sender會在封包上添加序號。如此receiver就會丟掉重複的封包。

看看下圖，這是sender的狀態圖:

而這張是receiver的狀態，課本的圖需要上下兩張交替看

下面是我對上面兩張圖合起來作流程的解釋，如果看圖就懂了可以直接跳過。

這裡是0號、1號兩種編號交替用。
(再提醒一次，從虛線箭頭開始)
一開始上面這一層傳0號封包下來，sender送第0號封包出去，進入等待回饋狀態；receiver收到，發現錯誤封包後回傳NACK，幸好receiver的NACK沒有出錯，sender收到回饋後重傳0號封包，進入等待回饋狀態，receiver收到正確的0號封包後往上面傳，並傳回ACK，sender收到ACK，於是0號這一輪結束，進入1號回合。

上面這一層傳1號封包下來，sender送第1號封包出去，進入等待回饋狀態；receiver收到，確認是正確的封包，但是在傳的過程它的ACK壞掉了，sender收到看不懂，於是又重傳一次1號封包，receiver收到，因為封包上有標序列，所以receiver知道那是重複的，把序列1的1號封包丟掉，傳ACK，這次sender收到的ACK是對的，1號回合結束。

rdt2.2

在rdt2.2，在回饋機制上我們把NACK省略掉，只留ACK。

機制與rdt2.1相似，但是在回應的ACK上有標輪次序號，因為這樣如果sender送的封包是錯的，sender就回「標有上一輪序號的ACK」，sender收到重複的ACK，它會重傳封包；如果sender送的封包是對的，sender就回「標有這一輪序號的ACK」，就沒事。例如:sender在第0輪錯了，receiver會回(ACK,1)；sender在第0輪對了，receiver會回(ACK,0)。

不知道你有沒有發現，目前為止都沒有考慮到訊息遺失(loss)的情況
下一篇將會介紹如果考慮loss該怎麼處理，敬請期待囉!

參見:
CSDN|rdt 可靠數據傳輸協定