逐步解决可靠运输
在这里我们介绍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.0接收方 
与以前相比，接收方会将接收的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.对处理丢失，损坏以及过度延时分组的解决方案。