后退N帧协议总结

1）后退N帧只是用一个计时器，当这个计时器超时时，则会重传超时报文之后 的全部报文。

2）后退N帧的发送窗口大小应该小于2^m。

这种原因要分两种情况讨论：假设接收端所期望接受的豹纹的序列号为n，

一种情况为：发送端还没发送能发送这个n,而是发送窗口刚好处于n的左边，那么这种情况说明发送端处于阻塞状态，并且窗口的所有分组都需要等待确认，假设这个窗口的大小刚好等于2^m,那么发送窗口的第一个报文序号是跟接收端所期望的序号是一样的，假设发送端进行了超时重传，那么此时发送窗口发送的第一个数字的序号跟接收端的是一样的，所以接收端分辨不出究竟是他所期望的序号报文，还是重传的报文，所以，不应该把发送端的窗口设置为>=2^m

二种情况，假设发送端的序号包括了接收端的序号，那么如果给发送端的窗口范围设置为2^m+1，此时由于接收端期望接收的数据序号是n，而如果刚好在发送端的窗口有包括有两个n，此时，如果接收端需要的是后一个n序号的报文，那么也就说明，他已经接受了前一个序号为n的报文，如果发送端没有接收到前一个序号为n的报文，并且产生了超时重传，那么发送端机会又发送前一个n的报文，此时由于接收端不知道是他所需的报文还是重传的报文，所以就会协议出现问题。所以就不能够把发送窗口的大小设置为>=2^m

3）后退N帧的发送端状况可以分为以下两种：

一:准备状态：

1）如果来自一个应用层的请求到达，发送方就产生一个序号为Rn的分组，这个R的副本分组被保存起来，而这个Rn分组则被发送出去，若那个唯一的计时器没有被启动，则把计时器启动起来，现在Sn的值递增到（Sn+1）mod 2^m,如果窗口满，即Sn=(Sn+Ssize)mod 2^m,那么发送端进入阻塞状态。

2）如果一个无差错且ackNo与某一待确认分组相关的Ack到达，那么发送窗口置为Sf=ackNo，如果所有待确认分组都被确认了（Sn=ackNo)，则计时器停止计时，若还有待确认报文还没有被确认，那么重启计时器。

3）如果有损坏的报文到达，或者无损坏但ackNo与待确认分组无关的Ack到达，那么机会丢弃这个Ack.

4)如果计时器超时，那么发送端就会重启计时器并且重传全部待确认分组。

二：阻塞状态：

1）如果一个无差错且ackNo与某一待确认分组相关的Ack到达，那么发送窗口置为Sf=ackNo，如果所有待确认分组都被确认了（Sn=ackNo)，则计时器停止计时，若还有待确认报文还没有被确认，那么重启计时器。

2）如果有损坏的报文到达，或者无损坏但ackNo与待确认分组无关的Ack到达，那么机会丢弃这个Ack.

3)如果计时器超时，那么发送端就会重启计时器并且重传全部待确认分组。

接收端则会只有准备状态，随时准备接受数据，接收端初始窗口大小为0，变量为Rn:

当有无错误的数据seqNo=Rn时，这个文组报文发送给应用层，此时窗口滑动到Rn=(Rn+1)mod2^m,并且会发送一个确认报文，此报文的确认号为Rn。

当一个无差错的报文到达，但是报文的序号确实在窗口之外，那么接收端则会发送一个Ack,此时的确认号为Rn.

当一个损坏的报文到达时，那么接收端则不会发送确认报文。

4）后退N帧传输可能出现的情况：

当发送端发送的报文在还没到达接收端时就发生损坏，导致无法传送到接收端，那么接收端接收到的报文就不是所要的那个报文，此时接收端则会重传它所需的那个报文的ACK，那么发送端当接收到三次这个ACK时，则会重传这个报文，这就是快速重传，他不用依赖重传时间来发送报文，假设发送报文损坏，然后接收端发送地ACK到达发送端所经历的时间已经超过重传时间，那么发送端则会根据超时重传机制进行数据包的传输。

当发送端的数据已经发送到接收端，此时接收端已经收到所需要的那个报文，那么接收端就会发送Rn的确认ACK,并把自己的Rn设置为Rn+1，但就在此时，接收端发送给发送端的确认ACK丢失或者延时了，那么再分几种情况讨论，

先讨论丢失的情况，假设接收端又收到了一个来自客户端的自己所期望的报文，那么接收端就会又发送报文，如果此时的报文在超时时间内到达发送端，那么发送端则会接收这个这个确认ACK，并且他进行的是一种累积确认，则会跳过之前损坏的那个确认报文，并且认为接收端正确处理了包括损坏的那个报文在内的所有报文。

在讨论丢失的另一种情况，假设一种极端的情况，接收端发了他所有窗口内的数据，此时他进入阻塞状态，而此时接收端都有一一回应，但ACK在发送回发送端的时候都损坏了，即都无法发送回发送端，那么此时发送端则会等待超时重传，当超时时间到，那么发送端重新发送数据，直到接收端回应，并且发送端能收到ACK。

在讨论延时的情况，假设都是延时问题，暂且不包括损坏的问题，假设接收端发送给发送端的ACK延时到达，但延时到达发送端的时间在超时时间内，在假设接收端又收到一个他所期望的报文，此时他肯定又会发送确认，假设此时的ACK先于之前的那个ACK到达，那么根据回退N帧的累计确认原则，则发送端则会认为接收端是处理了这个ACK之前的所有报文，然后把窗口向前移动，继续发送报文。但如果发送端又收到后来的ACK报文，那么这个ACK则会被丢弃。

再假设另一种情况，当发送端发送一个报文给接收端，但失序到达，可能第二个报文先到达，而第一个报文后到达，并且延时的时间超过超时时间，此时发送端就会重传第一个报文，但此时，如果之前那个报文又比重传的第一个报文快，那么此时应该会接收快的那个报文，并且发送ACK，然后当后面要来的那个第一个报文到达时，则丢弃他，并且发送一个ACK，先发送端说明接收端要接受的报文的序号。

如果发送端发送报文给接收端，接收端传给发送端的ACK延时了很长时间才到达，而且由于累积确认，发送窗口可能滑动了一个轮回了，并且停在了跟上次窗口号一样的位置，此时延时了很久的报文才到达发送端，假设刚好发送端所需要确认的序号刚好跟这个延时的序号一样，那么这时不会接受延时的ACK，而是把它丢弃，因为窗口范围已经不一样了。

假设发送端发给接收端数据报文，接收端回复ACK，但是回复的ACK都没有到达发送端，而且后面几个的ACK同样没有到达发送端，假设超过超时时间，那么此时发送端就会重传数据，发给接收端，此时接收端机会在发送ACK，那么此时的ACK是接收端所希望接受的报文，当这些ACK的其中一个到达发送端，那么发送端就会认为已经处理了这个ACK之前所有的报文，那么就不会再接收之前延时的ACK，而是把他们丢弃。