计算机网络数据链路层：流量控制与可靠传输

为什么要建立可靠传输机制？主要有两个方面的考量。一是传送方的发送速度要与接收方的接受速度匹配，这样才不会引起丢失和冗余。二是考虑到一旦传输时发生错误，如何补救的问题。这里我们介绍三个协议：1、停止—等待协议。2、后退N帧协议。3、选择重传协议。

一、停止—等待协议（以下简称“停等协议”）

除了比特错，信道还可能出现因设备线路故障、病毒攻击、路由信息错误等原因引起的数据包（帧）丢失问题。（我们这一届所涉及到的各种错误及其解决方案也是围绕着“丢包”这个主题开展的）

停等协议，简单来说，就是每发送一个数据包就停止发送，等待对方确认。在收到接收方发送的确认信息后就发送下一个包。

我们来看看正常情况：
发送端先是发送第一个帧，然后等待确认。接收端接到第一个帧以后，发送一个控制帧（相当于是给发送端一个传递下一个帧的命令）ACK1，发送端接收到ACK1就确认了对方成功接收到第一个帧，于是发送第二个……

那么一旦出现差错又如何解决问题呢？问题大概有以下三种，我们一个一个来看：

1、帧丢失：

计时器的概念：在传送每一个帧时，发送端都会自动设置一个计时器来判定帧的传输是否正常在帧传送以后计时器开始计时，超过规定期限就判定帧的传输失败，启动相关机制应对。

发送方在每一个帧发送之前会自动拷贝该帧的副本，如果计时器检测到在规定时间内没有接收方的确认帧传回，则发送方会重新传输丢失的帧。规定时间比一个帧的发送及接受确认帧的时间和长一些。

2、ACK丢失

ACK确认帧发生丢失，即发送方在计时器规定的时间没有接受到确认帧，那么会再次发送上一个帧，接收方收到该帧以后，会自动删除已经接收到的这一个帧，并将上一个帧的确认帧重发一遍。

3、ACK迟到

例如：发送方发送0帧，接收方收到并返回ACK0，但发送方在超出计时器规定时间内还是没有收到ACK0。所以重新发送了0帧，接收方收到0帧后会丢弃重复的0帧并重发ACK0，发送方收到ACK0后发送1帧，但此时却接到了接收端第一次发送的ACK0，由此判定是上一个ACK0迟到，所以收下就丢弃。

二、后退N帧协议（GBN）

在停等协议下，无论是发送方还是接收方在发送一个帧后，都需要等待一段时间，这很浪费。所以现实中发送方在一个工作周期内会连续发送多个帧，这称之为流水线技术。在流水线技术下，我们要在原有停等协议基础之上增加新的规则和技术：

1、增加序号范围

因为一个周期内要发送多个帧，所以要再原有的符号基础之上增加符号以示区分和规则。

2、发送方需要更大的缓存

与基础的停等协议一样，流水线技术也存在应对丢包的现象。这就涉及到重传和缓存。因为一次发的帧多了，所以发送方的缓存就要相对变大，于是就诞生了后退N帧协议和选择重传协议。

我们先来看后退N帧协议。在进入正题之前，请先允许我聒噪几句关于滑动窗口的概念。滑动窗口在GBN和SR中都是很重要的概念。分为发送串口和接收窗口。所谓发送/接收滑动窗口，就是发送/接收方维持的一组连续的、允许发送的帧序号。是专门针对一个工作周期内发送/接收多个帧的一种设计。发送窗口根据实际情况设计长度，并且在一个工作周期内连续拷贝并发送多个帧，接收端成功接收并返回ACK，发送端收到下界（发送窗口中第一个发送的帧所在的位置）ACK之后，自动前进一格囊括一个帧进入滑动窗口准备发送。

要保证该协议下正常运转，发送方和接收方需要做到一些事。

发送方：

1、上层（网络）调用。上层需要发送数据时，发送方会检查滑动窗口是否已满，如果未满，则发送一个帧。如果满了，这些数据会返回给上层，暗示窗口数据已满。（实际上发送方具有缓存数据并给予编号形成帧序列的能力）

2、接收响应ACK消息。在GBN中采用累计确认机制，标明接收方已经接到n帧及其前面的全部帧。

3、超时事件。计时器将再次用于恢复、确认帧的丢失。如果超时，发送方会发送问题帧之前的所有帧。

接收方：

1、确认接受。2、遇到一组帧的传播出现问题的，将这一组帧中已经接受的部分统统抛弃。

发送方发送滑动窗口中的帧，每发送一个帧，都会有这个帧相对应的计时器监视记录。如果第n个帧丢失，那接收端自然是接受不到的，而且即使接收到了第n+1、n+2个帧之后，也统统抛弃。在某一时刻，发送方第n个帧的计时器确认超时，这是会重新发送第n帧，并且发送以后发送但未获确认的帧。

三、选择重传（SR）

鉴于GBN协议的一些缺点：累计确认和批量重传机制导致其工作效率不高。所以有没有一种办法只重传出错的帧呢？选择重传协议需要设置单个确认机制，同时要加大接收窗口（在GBN协议中接收窗口只需存放一个帧就行了，而在选择重传协议中，就收窗口的长度往往要和发送窗口等长。）还要设置接收缓存，缓存乱序到达的帧。

至于发送方响应的事关于上层调用和超时事件都与GBN协议中类似。至于接收ACK，如果接到ACK，则发送方将那个对应的帧标记为已接受。如果该帧对应在窗口的下界，则窗口向前移动直到下界为一个新的未确认帧。如果移动后滑动窗口内有未发送的帧，则按序发送这些帧。

SR接收方：

接收方只管接收帧二不管其是否有正确的帧序。若有失序帧被收到，则收下并发送确认帧，直到所有比该帧序号小的帧都被收到。于是便将这些帧交给网络层。然后向前移动窗口。需要注意的是：如果收到了窗口后面（小于窗口下界）的帧，容易判断这是ACK丢失的原因，那么这时再补发一个ACK就行了。
我们可以看到，在这张图上，发送端和接收端拥有相同长度的滑动窗口。发送窗口中按序发送0123，接收端按理说应该按序收到0123并返回ACK0、ACK1、ACK2、ACK3的。但是中途丢失了2帧。接收方没有接收到2帧，其他正常接收并返回ACK确认帧。发送端发送3帧后，向前移动一个单位发送四帧时，接收端窗口已经向前移动，做好接收4帧的同时把为接收到的2帧放在了下界……等ACK5发送以后发送方的2帧计时器开始报警，这是发送端才反应过来原来早已处在发送窗口下界的2帧传输过程中出了问题。于是重新发送2帧……

最后一个问题：窗口到底多长为好？

再SR协议中，双方的滑动窗口必须等长，这样才能保证发送接收双方正常履行SR协议而不出现无意义和溢出。滑动窗口的长度也遵从等式：

Lmax（最大长度）=2^n-1

n是指在一个周期内用多少个比特能给这些帧序列标号。如果有帧序列0 1 2 3 0 1 2 3，那么n=2，也就是说用两个比特就可以表示这四个数字了。所以长度应该取2。如果窗口过长，则接收方无法根据接受的0帧判断其为新来的0帧还是重传的旧帧。

关于流量控制和可靠传输的内容就讲到这里，有错误不足之处还望多多指教，在下感激不尽。