1 UDP实现可靠数据传输
UDP具有无需建立连接，延迟小，速度快等优点，但是其提供的服务较差，没有TCP的多，那么UDP是如何实现可靠数据传输的呢。
一般来说，如果传输层采用UDP协议，应用层就需要增加一定的可靠性机制。同时UDP也有自己的简单的可靠性机制，UDP校验和。
2 RDT协议的设计
可靠数据传输协议，是位于传输层的协议，向上提供服务给应用层，向下，使用网络层链路层等传输数据，其接口如下图所示：
2.1 RDT 1.0协议
RDT 1.0协议是基于底层信道完全可信的情况，此时，数据传输不会出错，不需要进行错误检测等步骤，当然这种情况是最简单，最理想化的一种情况。
2.2 RDT 2.0协议
RDT 2.0协议，面向的是，底层信道有且仅有可能产生数据位错误。这时，RDT2.0协议就要考虑，我接受的数据错没错，要是错了我该怎么办。
首先考虑的问题是我接收的数据错没错，可以利用之前采用的校验和的方法进行检验。如果发生了错误，接收方应该告知发送方，我这把出现错误了，不然发送方就永远不可能知道，我发出去的信息，你那边接收的情况，这时候就引入了确认机制ACK/NAK。
如果接收方告诉发送方，我这接收的数据有问题，处理的方法就很简单，再发一份得了呗。
这时候的发送机的状态就比较复杂了，因为发了一次消息后，需要等待反馈，如果接收方反馈ACK，就发下一个，如果是NAK，就重发。
2.3 RDT 2.1协议
只能说开始套娃。你传送的数据不对，我反馈一个NAK。那么我反馈的ACK/NAK也有可能在传输中发生错误啊，我要怎么去解决这个问题呢。
因为RDT2.1是停-等协议，只有当一个分组发送完成后，才会发送下一个分组。如何发送方的状态时1，而接收方的状态时0，这时候，发送过去的数据，接收方是返回ACK还是NAK呢，还是说干脆不回应啊。结果很简单，发ACK，因为不回应，发送方永远都不知道你想要干嘛，回NAK，接收方只会重发，回ACK，才会使发送方的状态变成0，下一次发的数据就是我想要的了。
2.4 RDT 2.2协议
2.5 RDT 3.0协议
归根结底还是停-等传送协议的效率实在是太低太低了，对面不回传信息，就一直在这傻等着，啥也不干。为了提高效率啊，需要对我们的RDT协议继续的改进。
2.6 对停-等机制的改进
停-等协议一次只发一个，那一次发一群，就能明显提高效率，这就有了流水线机制。
其中滑动窗口协议就是基于流水线机制的一种实现
2.6.1 GBN协议
滑动窗口，就是通过不断确定base的那个数据以及ACK了，然后就将base不断的往后移动，就实现了滑动。
接收方的工作原理就很简单了，只认准自己要接收的有最大序列号的那个，没收到就丢弃。
通过这个图看原理就简单了，发送方只要收到了一个ACK，就往后移动到这一个序列（为什么不是移动一个？因为ACK可能丢失，小的没收到，但是收到大的了，能收到大的，说明小的已经被接受了），没收到就直接将窗口里面的全部重发。接收方只要接收到了目前想要的那个（序列号没接受到的最大的哪一个），就返回这个的ACK，收到的不是，就丢弃掉，并且返回目前已经收到的那个。
2.6.2 SR协议
SR协议对GBN协议作出的一些改进，允许了乱序到达。
发送方为每一个序列号创建定时器，并且从接收方接受到ACK(n)后，如果在窗口内，就标记收到，要是这个之前的全部都被接收到了，就将窗口滑到这个位置。
接收方收到了一个序列号，在窗口里就缓存下来，并返回接收到序列号的ACK，并且等待还没接受到的。将窗口滑动到之前的全部被接受的位置。
为了避免上一个的序列0被当成这一次的序列0，滑动窗口的尺寸是有要求的。