计网第三章（数据链路层）（二）
目录
一、可靠传输
二、可靠传输的三种实现机制
1.停止等待协议SW（自动重传协议ARQ）
（1）理想情况（即无差错情况）：
（2）有误码的情况：
（3） 超时重传：
（4）确认丢失：
（5）确认迟到：
2.回退N帧协议GBN
（1） 无差错的情况：
（2）累积确认：
（3）有差错的情况：
最简单的情况：
更为复杂的情况：
（4）发送窗口的范围
3.选择重传协议SR
（1）有差错情况：
（2）窗口的范围
发送窗口：
接收窗口的范围：
二、总结：
一、可靠传输
计网第三章（一）最后提到可靠传输服务。简单来说就是采取一系列的措施，使得发送方发送什么，接收方就能接收到什么。
所谓的采取措施的目的就是防止出现传输错误，事实上传输错误并非只有前面提到的比特差错，还包括分组丢失、分组重复和分组失序，这几种错误一般不会出现在数据链路层，而在其上层。
所以可靠传输并不局限于数据链路层。
二、可靠传输的三种实现机制
为了讨论问题方便，只考虑单向传输。
1.停止等待协议SW（自动重传协议ARQ）
发送方每发送一个分组就会停止发送，等待接收方的确认。收到确认后再发送下一个分组。
（1）理想情况（即无差错情况）：
（2）有误码的情况：
这里有一个小细节：在可靠传输协议里面，接收方在检测出有错误后可以不发送否认分组，即什么也不做，这是因为后面的超时重传的特性，只需要等待发送方重新发送就可以。
发送否认分组的好处是可以发送方及早知道发送的分组出现了差错，但是这种处理方式也会使协议更加复杂化。 现在实用的可靠传输协议都不使用这种否认分组了。所以后续讨论默认不会发送否认分组。
（3） 超时重传：
所谓超时重传就是每次发送完一个分组就设置一个超时计时器，若计时器到时之前就收到接收方的确认，就撤销已设置的超时计时器。如果到时后仍没收到接收方的确认，那么发送方就会重传前面发送过的分组。
那么什么情况会导致超时重传呢？
首先就是前面所说的，传输时接收方发现有误码，直接将该分组丢弃的情况。如图：
看到这里，我想大家已经理解现在实用的可靠传输协议可以不使用否认分组了的原因了。
发送的数据分组在传输过程中丢失的情况：
有人可能会问，超时计时器的时间应该设置为多长？
理论上讲是要比数组在分组传输的平均往返时间更长一些。这里可以不用做过多深究。
既然发送分组有丢失，那么确认分组是否在传输中也会出现问题呢？
答案是肯定的，所以就有了后面的两种情况。
（4）确认丢失：
这其实也是引起超时重传的另外的情况：确认分组在传输的过程中丢失，但是发送方无法知道，他只要没有收到来自接收方的确认就会一直等待，直到进行重传。
注意图中的细节：在这张图中我给数据分组进行了编号，进行了编号接收方才知道数据分组是重复的，才会进行丢弃。也就是避免出现分组重复的情况。而我们只要保证每次发送的数据分组和上一次发送的数据分组不是同一个分组就可以，所以可以直接使用一个比特进行编号（即0和1）。
那么接收方的分组是否也需要进行编号？
答案是肯定的，这就要提到最后一个情况：确认迟到。
（5）确认迟到：
确认迟到也会引起发送方的超时重传，在给确认分组也编号后，发送方收到迟到的确认分组，判断它与之前的确认分组重复，便不会进行任何操作。
简单做一个总结：
SW协议利用超时计时器保证了发送方在发送数据分组后因各种因素（比如数据分组丢失，数据分组出现误码，确认丢失，确认迟到）而无法收到接收方的确认之后，该协议仍能继续运转，避免停滞的情况。
而给分组（不论是数据分组还是确认分组）进行编号，避免了分组重复的问题，让双方在收到重复的分组后都能进行正确的操作。
根据SW协议的特点，每次发送完一个数据分组就要至少等候收发双方间的往返时间后才可以发送下一个数据分组。如果往返时间较大，由于SW协议的信道利用率本身就很低，若是触发了超时重传就更是雪上加霜。显然，这种情况并不是我们愿意看到的。如果在发送方接收到接收方的确认分组之前，发送方可以连续发送多个数据分组，则可大大提高信道利用率，在这种流水线式传输的基础上，诞生了后面的两种协议。
2.回退N帧协议GBN
（GBN协议是一种连续ARQ协议，在协议的过程中，发送窗口和接收窗口都在不断滑动，因此又属于滑动窗口协议。）
在流水线传输的基础上，
对于发送方：采用发送窗口（
）来限制可连续发送数据分组的个数。
是有取值范围的，为
， 式中的n为用多少个比特数给分组编序号。
对于接收方：接收窗口（
）的值固定为1。
比如现在采用3个比特给分组数编号，那么有
。 只要 在该范围内都可以取值，我们假设为4。如图：
（1） 无差错的情况：
发送方将落在发送窗口内的数据分组连续发送出去。
数据分组正确到达（即没有出现乱序和误码）接收方后，接收方按序接收，每接收一个接收窗口就向前滑动一个位置，并给发送方发送接收分组的确认分组。
发送方每接收一个确认分组就将发送窗口向前滑动一个位置。
注意：在图中各自颜色的虚线框对应各自的初始状态，红色虚线框代表滑动的痕迹，各自颜色的实线框代表这段过程结束后各自窗口停留的位置。
这段过程结束后，发送方就可以将收到确认分组的从缓存中删除。而接收方可以择机将已接收到的分组交付给上层处理。
（2）累积确认：
GBN协议的接收方不一定要对每个数据分组逐个发送确认。它可以对按序到达的最后一个分组发送确认。
就代表n之前的包括序号为n的数据分组都已正确接收。
优点：有时候确认分组丢失也不会出现超时重传。比如上述情况，如果GBN采用累积确认，假设针对1号分组发送了
，最后又针对3号分组发送了
。即便在传输过程中丢失，只要被发送方接收到，就不会有1号分组的重传，并且下一次发送从4号分组开始。同时，使用累计确认也可以减小接收方的开销，减少网络资源的占用等。
缺点：无法向发送方及时反映接收方已经正确接收的数据分组的信息。
（3）有差错的情况：
我们按照上面的过程继续往下模拟
最简单的情况：
如果传输过程中出现误码，接收方检测到后就会丢弃该分组，而不论该分组之后的其余分组是什么情况，接收方都会因为与接收窗口的序号不匹配直接进行丢弃。发送窗口一直没有收到确认分组，所以就不会有任何动作。直到进行超时重传，发送窗口重新发送窗口内的数据分组，这就是回退N帧。（超时重传和前面的一样，在本图中没有画出）。
更为复杂的情况：
这里与之前SW协议里面提到过的发送否认分组有点联系，通过前面的学习我们知道发送否认分组的好处就是让发送方及时知道自己发送的数据分组出现了问题。
以上图为例，在GBN协议里面，丢弃4号分组后，对于后面的分组接收方每丢弃一个就向发送方发送一个之前按序接收的最后一个数据分组的确认分组，在本例中即为。发送方在收到一定数量（由具体实现决定）的后就知道之前所发送的数据分组出现了差错，就不用等待超时计时器超时后再进行重传。当然，如果发送方没有收到足够的重复确认，仍然是等待超时重传。
（4）发送窗口的范围
最后对的范围进行一些细节说明：
为什么要大于1？
其实不难看出，GBN协议的接收窗口的取值和SW协议的取值是一样的，都是每次接收一个分组。 那么，如果的值为1了，发送也是每次发送一个分组，那这不就是SW协议嘛！ 所以当的值为1时，就是SW协议。
为什么最大值只能取到
？
假设n的取值仍为3，那么最大值只能是7。我们用反证法进行证明。
我非要取的值为8,我们现在假设一种情况（默认数据分组全部正确按序到达）：
发送方发送的数据分组全部被成功接收，但是接收方的确认分组在传输过程中丢失了，这必然会引起发送方超时重传。
而由于接收方已经成功接收第一次发来的数据分组，所以接收窗口落在了新的序号为0的位置上，但是发送方因为重传，新一次的发送仍然是上一次发送过的数据分组，接收方判断序号一致，将其接收，并向发送窗口发送确认分组。接收方无法分辨新旧分组，进而产生了分组重复的问题。很明显，这种情况已经出现了差错。 这种情况其实也可以说为GBN协议的确认丢失的情况。
仔细想想，n个比特产生的位数共
个，当我们发送窗口的值恰巧取个值就会引发上面的问题，所以最大值只能取个。
我们不难发现GBN协议的缺点，如果出现有差错的情况，只要有一个分组出现问题后面的分组都会被丢弃，这是因为接收窗口的值为1，接收方只能按序接收分组。那么是否可以将接收窗口也进行改变呢？
答案是肯定的，所以就有了第三种SR协议。
3.选择重传协议SR
为了不再出现像GBN协议那样的资源浪费，可以采取措施只重传出现误码的分组。为此，接收方窗口的值需要大于1，这样只要是按序到达并且无误码的分组接收方都可以先收下。这就是SR协议的核心。注意：为了只重传出现误码的数据分组，SR协议不再使用累积确认。
对于发送方：采用发送窗口（）来限制可连续发送数据分组的个数。
是有取值范围的，为
， 式中的n为用多少个比特数给分组编序号。
对于接收方：接收窗口（）的值一般和发送窗口的值相等。
我们仍采用3个比特给分组数编号，那么有
。 只要 在该范围内都可以取值，我们假设为4。那么的值也为4。如图：
无差错情况和GBN的无差错情况类似，只是接收窗口发生了变化，这里不再做过多说明。
（1）有差错情况：
如图：假设发送方发送的数据分组在传输过程中1号分组丢失了，其余分组正确按序到达。
接收方在接收到0号分组后，接收窗口会向前滑动一个位置，但是之后的接收中未收到1号数据分组，接收方就先将按序到达的2号和3号接收，并发送它们的确认分组，此时接收窗口不会进行滑动。
发送方收到0号分组的确认分组后，发送窗口向前滑动一个位置，但是之后的接收并未收到1号确认分组，发送方先将2号和3号分组记录，保证它们不会超时重传，此时发送窗口不会进行滑动。在此过程中，发送窗口还会将新落入窗口的4号分组发送出去。
我们可以假设后续过程：接收方接收到4号分组后，确认无误码接收并发送确认分组，但是因为仍为收到1号分组，所以接收窗口仍然不会滑动。
发送方收到4号分组的确认分组后，将其记录保证4号分组不会超时重传。但因为没有收到1号分组的确认分组，所以发送窗口仍然不会滑动。 等超时计时器到时，便会引发超时重传，因为2、3、4号分组都已记录确认分组，所以重传的只有1号分组。
这次接收方成功接收到了1号分组，向发送方发送4号分组的确认分组，随后接收窗口向前滑动4个位置。
发送方接收到了1号确认分组，发送窗口向前滑动4个位置，随后将新落入窗口的分组发送出去......
我们可以看到，双方都是每按序接收一个分组，窗口就向前滑动一个位置。如果中间有未成功接收到的，就在窗口等这个分组的同时接收窗口内的其他分组，期间窗口即便接收了其他分组也不会进行滑动。如果接收到一个分组，相邻的分组都已经按序成功接收到。窗口就会滑动到第一个还未按序收到的分组的位置。
（2）窗口的范围
发送窗口：
如果
=1，就和停止等待协议相同。（此时的
只能是1）
时，接收方无法分辨新旧分组，会出现分组重复的情况。
同样地，我们非要超过其最大值，取=5，=5，
发送方先将发送窗口内的数据分组连续发送出去。
接收方全部成功接收，并向发送方发送每个数据分组的确认分组，接收窗口向前滑动5个位置。但是1号确认分组在传输过程中丢失。
发送方因为没有收到1号分组的确认分组，只会向前滑动一个位置，并记录其他按序到达的分组。并将5号分组发送出去。计时器到时后就会引起重传， 很明显只会重传1号数据分组。
如果是图中的状态（假设5号分组已经发送并成功接收），重传的1号分组会去哪？
很明显就被接收窗口接收到对应的序号位置了，但实际这个分组之前已经被接收了，也就是出现分组重复的差错了。
接收窗口的范围：
=1时，如果
，那就是回退GBN协议。
时，没有意义。
一般接收窗口取和发送窗口一样大的值。
二、总结：
本篇博客主要讨论了可靠传输的三个机制。简单来讲，GBN协议就是在SW协议的基础上对发送窗口进行了改变。因为发一个分组就需要等待，信道利用率太低。SR协议是在GBN协议的基础上对接收窗口进行了改变，因为对于一次只能接收一个分组的接收窗口来讲，如果对应的分组出现差错，其余按序到达的都会被丢弃，这样太浪费资源了。
对窗口限制范围就是为了防止一些分组丢失的情况导致分组重复。