Rdt(Reliable Data Transfer)可靠数据传输

数据传输引擎涉及到的rdt(可靠数据传输)，所以学习一下

在TCP网络传输中，数据都是通过网络上可靠的通道来传输。但实际存在许多状况，如资料位元错误、封包遗失，造车资料不可靠，所以必须建立有效的传输协定。

1.rdt1.0
rdt的模型主要是用FSM(Finite State Machine-有限状态机)来定义状态与操作方式。

rdt1.0是假设使用最可靠的通道情况。主要有传输端与接收端两个部分，资料传输方式很单纯，传输端等待上层传资料进来，收到上面的资料以后装成封包送出去。

接收端收到封包以后，将封包解开，把讯息往上送。

2.rdt2.0

2.0考虑到了资料错误的情形，当接收端收到资料，会有ACK(相当于OK)与NAK(相当于Send Again)两种讯息，当资料接收到以后确认无误，会送ACK给来源已确定资料无误。当侦测到错误时 会传回NAK通知来源端再送一次。

3.rdt2.1

2.1新增了sequence number，同样使用ACK与NAK来确认讯息，封包的号码可以用来确认是否重新传输封包。例如接收端在等待编号0的封包，结果收到封包1，此时会回传ACK1给来源端，而正在等候ACK0的来源端收到ACK1 表示封包0可能遗失，所以会再重送封包0.

4.rdt2.2

一次使用两种确认讯息 处理起来比较费力，因此2.2中移除NAK的讯息，在ACK中加入编号 就可以达到确认与否认的效果。

5.rdt3.0

3.0同时考虑到封包遗失与资料错误的情形，除了使用ACK机制，另外在传送端多了倒数计时器，封包送出去如果超过时间仍未收到ACK或是收到不正确编号的ACK，则再送出封包一次。

6.Stop-and_Wait与Pipelined Protocol

rdt3.0虽然确保了资料的可靠性，可是它采用Stop-and-Wait机制，效能方面无法让人接受，因为送出封包后必须等待对方回应才能继续传送，假如连线Delay太长，整体效率会严重低落。

为解决这问题，后来发展出 Pipelined Protocol，可以让传送端同时传送多个封包不需等待确认相对的，传输端与接收端都必须增加封包的暂存空间与序列号码。当其中的封包出现错误时有不同的回覆方法，主要有Go-Back-N(GBN)与Selective Repeat(SR)两种方法。

Go-Back-N(GBN)

传输多个封包 必须有个暂存的区域，暂存的区域中存在着窗格大小(Window Size) N，存放着各种封包(已确认、已送出但未收到ACK、未送出的封包等等)。

接收端也会开启窗格来接收封包，会记着目前收到封包的编号，假设收到顺序不对的封包N+1(等待接收第N个，下一个传来的却是第N+1号)，会将N以后的封包全部丢弃，此时传送端一直没收到ACK(N)，会把N号以后的封包全部重新传送出去。

Selective Repear(SR)

GBN的传送方法往往会造成不必要的重复，因此SR的传送方法就是只针对未收到的封包做重新传输的动作。首先规划出大小为N的窗格来限制大小，窗格的基底会停留在最近一个尚未收到ACK的封包区域，当封包时间逾时会重新送出封包，直到收到该封包的ACK 窗格基底才会往前移动。

7.Flow Control(流量控制)

虽然TCP接收端有缓冲区，但有时候应用程序读取讯息的速度小于传输端传送讯息的速度，假如缓冲区满了还继续传资料过来，会造成缓冲区溢位的情况，为避免此状况，设了一个"receive window(接收窗格简写成rcvWindow)"变量，用来记录缓冲区剩余的空间有多少。

当接收端收到讯息后，会回传给传送端rcvWindow的数值，如果rcvWindow=0，传送端会停止传输资料但这个方法会造成问题，假设停止后 接收端一直没讯息通知传送端，此时传送端不会运作，而接收缓冲区也是空的，资料传输停止。

因此当接收端rcvWindow=0时，传送端会持续传送一个1byte的区段给接收端 以确认缓冲区可否继续接收资料。