计算机网络学习：第三章数据链路层（一）

3.1 数据链路层概述

数据在主机与主机之间的传输过程在之前已经提到过，同时我们也提到过在五层网络体系结构之中如果只是单纯研究某一层的话我们可以只观察水平方向对应的实体（emm就是只看该层而忽略其他层），如下：

而在学习之前，我们需要先清楚几个概念：

然后我们来介绍数据链路层的三个重要问题：

• 封装成帧
  如图所示，两个主机通过一段链路互连，两台主机都会对所发送或接收的数据包进行五个层次的封装或解封：

发送方将待发送的数据通过应用层封装成为应用层协议数据单元，然后交付给运输层：

运输层为其添加运输层协议首部，使之成为运输层协议数据单元，然后交付给网络层：

网络层为其添加网络层协议首部，使之成为网络层协议数据单元，然后交付给数据链路层：

数据链路层给网络层协议数据单元添加一个数据链路层协议首部，简称为帧头，还要给其添加一个帧尾：
我们将数据链路层给网络层交付的协议数据单元添加帧头和帧尾的操作，叫作封装成帧。添加帧头和帧尾的目的都是为了在链路上以帧为单元来传送数据，也就是为了实现数据链路层本身的功能。
例如下图是以太网版本2的MAC帧格式：

• 差错检测
  发送方将封装好的帧通过物理层发送到传输媒体，帧在传输过程中遭遇干扰后可能会出现误码，也就是比特0可能变成了比特1，反之亦然。
  
  那么出现误码之后，接收方主机如何判断帧在传输过程中是否出现了误码呢？这可以通过差错检测码来发现，发送方在发送帧之前，基于待发送的数据和检错算法计算出检测码，并将其封装在帧尾，例如，以太网版本2的MAC帧的帧尾，就是4字节的帧检验序列FCS字段，要写入该字段的内容，也就是我们所说的检测码：
  
  接收方主机收到帧后，通过检错码和检错算法就可以判断出帧在传输过程中是否出现了误码：

• 可靠传输
  接收方主机收到有误码的帧后，是不会接收该帧的，将其丢弃。如果数据链路层对上层提供的是不可靠服务，那么丢弃就丢弃了，不会再有更多措施。但如果提供的是可靠服务，那么就还需要其他措施来确保接收方主机还可以重新接收到被丢弃的这个帧的正确副本。
  
  上述三个问题（封装成帧、差错检测、可靠传输）是数据链路层中最基本最重要的问题，后面还会详细介绍，这里只是稍微知道是什么意思即可。需要说明的是，我们在介绍这三个问题的时候，使用的是点对点信道的数据链路层来举例的。
  对于使用广播信道的数据链路层除了包含这三个问题以外，还有一些其他需要解决的问题。如图所示：
  

主机ABCDE通过一根总线相连，主机A要给主机C发送帧，代表帧的信号会通过总线传输到总线上的其他各主机：

那么主机BDE如何知道所收到的帧不是发送给它们的？而主机C又是如何知道该帧是发送给它的呢？相信大家能够说到地址或者说编址的问题，也就是将帧的目的地址添加在帧中一起传输。
例如下图是以太网版本2的MAC帧格式：

其首部的三个字段中，有两个字段和地址相关，一个是目的地址字段，另一个是源地址字段。除了编址问题外，再来看下面这个问题，当总线上多台主机同时使用总线来传输帧时，传输信号就会发生碰撞，这是采用广播信道的共享式局域网不可避免的：

以太网采用的协调方法是使用一种特殊的协议CSMA/CD，也就是载波监听多点接入/碰撞检测。
随着技术的发展，交换技术的成熟和成本的降低，具有更高性能的使用点对点链路和链路层交换机的交换式局域网，在有线（局域网）领域已经完全取代了共享式局域网：

那么该种形式的网络中的交换机又是如何转发帧的呢？另外，由于无线信道的广播天性，无线局域网仍然使用的是共享信道技术，例如，802.11局域网采用的媒体接入控制协议是CSMA/CA，也就是载波监听多点接入/碰撞避免，它的工作原理又是什么呢？

上述这些内容都是数据链路层中十分重要的问题，在本章我们后面都会一一进行详解。

3.2 封装成帧

封装成帧概念：

在帧头和帧尾中包含有重要信息，例如下图中以太网2版本的MAC帧格式：

下图是点对点协议PPP的帧格式：

发送方的数据链路层将上层交付下来的协议数据单元封装成帧后，通过物理层将构成帧的各比特转换成电信号发送到传输媒体，那么接收方的数据链路层如何从物理层交付的比特流中提取出一个个的帧呢？

实际上，帧头和帧尾的作用之一就是帧定界，例如下图中的PPP帧的格式中，在其帧头和帧尾中各包含有一个长度为1字节的标志字段，其作用就是帧定界。

假设发送方发送的是PPP帧，比特流中红色部分是比特流标志，那么接收方的数据链路层就可以依据帧定界标志从物理层交付的比特流中提取出一个个的帧：

需要说明的是，并不是每一种数据链路层协议的帧都包含有帧定界标志。例如以太网版本2的MAC帧格式中，其帧头和帧尾中就没有包含帧定界标志：

那么接收方又是如何从物理层交付的比特流中提取出一个个的以太网帧的呢？实际上，以太网的数据链路层封装好MAC帧后，将其交付给物理层，物理层会在MAC帧前面添加8字节的前导码，然后再将比特流转化为电信号发送。前导码的前七个字节为前同步码，作用是使接收方的时钟同步。之后的一字节为帧开始定界符，表明其后面紧跟着的就是MAC帧。

另外以太网还规定了帧间时间间隔为96比特的发送时间，因此MAC帧并不需要帧结束定界符，需要说明的是，帧间间隔还有其他作用，我们在后续课程中再介绍。

接下来我们介绍透明传输的问题。

举例说明，下图是发送方数据链路层收到其上层交付的协议数据单元，给其增加帧头和帧尾，使其成为帧：

为了简单起见，我们只画出来了帧头和帧尾中的帧定界标志。帧定界标志也就是一个特定数值，那么接下里思考一下，如果在上层交付的协议数据单元中恰好也包含了这个特定数值：

肯定不能啊，如果中间有这个特定数值，那么接收方判断到中间那个flag时就会停止接收了，那数据就出错了呀。
所以如果数据链路层不采取其他措施来避免接收方对帧是否结束的误判，就不能称为透明传输。也就是说，数据链路层对上层交付的协议数据单元有限制，其内容不能包含帧定界符。显然，这样的数据链路层没有什么使用价值。实际上，各种数据链路层协议，一定会想办法来解决这个问题，例如，在发送帧之前就对帧的数据部分进行扫描，每出现一个帧定界符，就在前面插入一个转义字符。

接收方数据链路层在物理层交付的比特流中提取帧，遇到第一个帧定界符时，认为这是帧的开始：

当遇到转义字符时，就知道其后面的1字节内容虽然与帧定界符相同，但它是数据而不是定界符：

剔除转义字符后将其后面的内容作为数据继续来提取，当再次提取到帧定界符时，表明这是帧的结束。
注意，如果是在上层交付给数据链路层的协议数据单元中既包括帧定界符又包含了转义字符的话，方法仍然和上面相同，在帧发送之前，对帧的数据部分进行扫描，每出现一个帧定界符或转义字符，就在其前面添加一个转义字符。

需要说明的是，转义字符是一种特殊的控制字符，其长度为一个字节，十进制为27，而并不是上面图中的ESC这三个字符。
我们刚刚介绍的是面向字节的物理链路，使用字节填充（或称字符填充）的方法来实现透明传输。对于面向比特的链路，应该使用比特填充的方法来实现透明传输，例如下图是某个点对点协议的帧：

为了简单起见，在帧首部和帧尾中，仅给出了帧定界标志而未给出其他控制字段：

而帧的数据部分，出现了两个帧定界标志：

但它们实际上是数据而不是帧定界，在发送前，可以采用零比特填充法，对数据部分进行扫描，每5个连续的比特1后面就插入一个比特0：

这样就确保了帧定界在整个帧中的唯一性，也就可以实现透明传输（只要保证帧定界的标志是唯一的即可）。接收方的数据链路层从物理层交付的比特流中提取帧时，将帧的数据部分中的每5个连续的比特1后面的那个比特0剔除即可。
考研真题：

选A。
另外为了提升帧的传输效率，应当使帧的数据部分的长度尽可能大些。
因为仅从数据链路层来看，帧的数据部分才是真正要传输的数据，帧头和帧尾是为了实现数据链路层功能而额外添加的。
当然了，考虑到差错控制等多种因素，每一种数据链路层协议都规定了帧的数据部分的长度上限，即最大传送单元MTU（Maximum Transfer Unit）。

3.3 差错检测

如下图是以太网版本2的MAC帧格式，其帧尾中包含了一个长度为4字节的帧检验序列FCS字段。其作用就是让接受方的数据链路层检查帧是否在传输过程中产生了误码。

下图是点对点协议PPP的帧格式，其帧尾中也包含了一个长度为两字节的帧检验序列FCS字段，其作用和上述相同。

检错方法

奇偶校验方法

举例说明，收发双方及数据如下：

假设收发双方采用奇校验，那么在数据后面添加的校验位应该为比特1，使得比特1的总数为奇数。假设传输过程中产生了1位误码，我们用红色表示：

接收方对收到的比特流进行奇校验，发现比特1的总数为偶数而不是奇数，就知道传输过程当中出现了误码，换句话说，采用奇校验，若比特1的数量的奇性发生了改变，就可以检查出错误。
但是如果传输过程中出现了两位误码，接收方进行校验时会发现比特1的总数依然为奇数，就会误认为传输过程中没有发生误码：

也就是说采用奇校验，若比特1的数量的奇性不改变，是无法检查出错误的。而用偶校验则思路和上面一样，我们在后面加一个比特0即可，总结如下：


上述的特性就导致奇偶校验方法的漏检率过高，所以一般数据链路层不会采用这种方法来进行检错。

循环冗余校验CRC方法（Cyclic Redundancy Check）

该方法是一种具有很强检错能力的检错方法，漏检率极低。

我们来看发送方如何处理：
使用除法来计算冗余码，待发送的数据作为被除数的一部分，后面添加生成多项式最高次个0以构成被除数，生成多项式各系数构成的比特串作为除数，得到商和余数：

余数就是所计算出的冗余码，将其添加到待发送数据的后面一起发送：

需要注意的是，冗余码的长度与生成多项式最高次数相同，而商仅仅作为标记，防止计算过程中对错位：

再来看接收方的处理，也是做除法，被除数就是接受到的数据，除数仍然是生成多项式各项系数构成的比特串。进行除法，得到商和余数。如果余数为0，可判定传输过程没有产生误码，否则可判定传输过程产生了误码：

下面我们对生成多项式进行说明：

例题：

再对差错检测做一个说明：

3.4.1 可靠传输的基本概念

通过上一节的学习我们知道：

可是当接收方的数据链路层知道了接收到的数据出现了比特差错该怎么办呢？

这取决于数据链路层向上层提供的服务类型：

例如，接收方可以给发送方发送一个通知帧，告诉它“之前发送的帧产生了误码，请重发”：

发送方收到通知后，重发之前产生了误码的那个帧即可。实际上，可靠传输的实现，并没有想象中的这么简单，试想一下如果这个通知帧也出现了误码会怎么样呢？
这后面会讲，本节课只是先介绍一下可靠传输的基本概念。

需要说明的是，比特差错只是传输差错中的一种，从整个计算机网络体系结构来看，传输差错还包括分组差错、分组失序以及分组重复。

举例说明，如下图所示：

主机H6给主机H2发送的分组到达了路由器R5，由于此时R5的输入队列快满了，R5根据自己的分组丢弃策略将该分组丢弃。这是一种分组丢失的情况。
再来看看分组失序的例子，主机H6依次给主机H2发送了三个分组，但它们并未按照发送顺序依次到达H2，也就是说，最先发送的分组未必最先到达。

再来看分组重复的例子，主机H6给主机H2发送的分组，由于某些原因在网络滞留了，没有及时到达H2，这可能造成H6对该分组的超时重发。重发的分组到达H2，一段时间2，滞留在网络中的那个分组又到达了H2，这就会造成分组重复的传输差错。

3.4.2 可靠传输的实现机制

可靠传输的实现机制一共有三种方式：

停止等待协议SW（Stop and Wait）

如图所示，收发上方基于互联网通信，而不是局限在一条点对点的数据链路，纵坐标为时间，发送方给接收方发送数据分组（DATA），接收方对其进行差错检测，若没有误码则接收该数据分组，并给发送方发送确认分组，简称为ACK：

发送方收到对所发送数据分组的确认分组后，才能发送下一个数据分组，假设这个分组在传输过程中出现了误码，接收方收到后对其进行差错检测发现了误码，则丢弃该分组，并给发送方发送否认分组，简称为NAK，发送方接收到该消息后就知道了之前自己发送的分组出错了，于是立刻重传该分组：

因此发送方每发送完一个数据分组后，并不能立刻将该数据分组从缓存中删除，只有在收到针对该数据分组的确认分组后，才能将其从缓存中删除。
看来，发送方每发送完一个数据分组后，就停止发送下一个分组，等待来自接收方的消息，继而做出下一动作。这样就实现了发送方发送什么接收方就收到什么，这也就是所谓的可靠传输，但实际情况远远复杂的多。
比如下面这张情况，发送方给接收方发送分组，结果分组在传输过程中丢失了：

需要说明的是，对于数据链路层点对点信道而言，不太容易出现这种情况，但对于多个网络通过多个路由器互连的复杂互联网环境而言，这种情况是会经常出现的。
对于这种情况而言：

即：

貌似通过上述手段，我们就可以实现可靠传输了，但深入思考之后就会知道应该还会有其它情况仅靠上述手段无法实现。
比如现在不是发送方发送的数据丢失，而是接收方发送的NAK或者ACK丢失了，这种情况下必定会引发发送方的超时重传，即又传送一个相同的分组过来，那么接收方怎么判定这个分组有无重复呢？

我们的解决办法是：

例如，上述问题中我们将该数据分组的序号设定为0：

对于停止等待协议，由于每发送一个数据分组就进行停止等待，只要保证每发送一个新的数据分组，其序号与上次发送的数据分组的序号不同就可以了。因此用一个比特来编号就够了，即序号0和1。这样接收方就可以判断出该数据分组是否是重复的。
即：

同理，接收方的确认分组信号也需要进行编号（分析过程同上）：

注意，上图中最下面的DATA0和上面的DATA0不是同一个数据分组，组厦门的DATA0是指另外一个数据分组的0号版本。
需要说明的是，对于数据链路层的点对点信道，往返时间比较固定，不会出现确认迟到的情况，因此如果只在数据链路层实现停止-等待协议，可以不用给确认分组编号。
接下来我们给停止等待协议的一些注意事项进行一下小结：

接下来我们来看看停止-等待协议的信道利用率：

上图中的利用率忽略了双方对数据分组的处理时延。
下图中有一个例子可以帮助理解停等协议的信道利用率：

最后顺便提一下，像停止等待协议这种通过确认和重传机制实现的可靠传输协议常称为自动请求重传协议ARQ（Automatic Repeat reQuest）。意思是重传的请求是自动进行的。

回退N帧协议GBN

先来看看和停等协议的区别：

这一节介绍回退N帧协议GBN，该协议在上面的流水线传输的基础上利用发送窗口来限制发送方可连续发送数据分组的个数。
举例说明，假设采用3个比特给分组编序号，因此序号的取值范围是0~7（000到111），如图所示，下图有收发双方各自的分组序号：

当序号增加到7时，下一个序号又从0开始。发送方要维持一个发送窗口，序号落在发送窗口内的数据分组可被连续发送，而不必等收到接收方的相应确认分组后再发送。发送窗口的尺寸记为WT，对于本例，其取值范围为1<WT<2^3-1，其中的3是构成分组序号的比特数量。本例取WT的值为5，如果WT的值取为1，则变成了停止等待协议。如果WT的值超过了取值范围的上线则会造成严重的错误，之后会举例说明。
如图所示，序号落在发送窗口内的这5个数据分组可以连续发送而序号落在发送窗口外的数据分组不允许发送。

接收窗口的尺寸记为WR。对于回退N帧协议，其取值只能为1，这一点于停止等待协议是相同的，如图所示，序号落在接收窗口内的这个数据分组允许接收，而序号落在接收窗口外的数据分组不允许接收：

首先来看最简单的情况，也就是无差错的情况，发送方将落在发送窗口内的0~4号数据分组依次连续发送出去：

它们经过互联网的传输正确到达了接收方，也就是没有出现乱序和误码，接收方按序接收它们，每接收一个，接收窗口就往前滑动一个位置，并给发送方发送真多所接收分组的确认分组：

0~4号确认分组经过互联网的传输正确到达了发送方，发送方每接收一个发送窗口就往前滑动一个位置：

这样就有新的序号落入了发送窗口，发送方可以将收到确认的数据分组从缓存中删除了，而接收方可以择机将已接收的数据分组交付上层处理：

接下来，我们来看累积确认的概念。使用回退N帧协议的接收方，可以采用累积确认的方式：

举例说明，发送方将序号落在发送窗口内的0~4号数据分组依次连续发送出去：

它们经过互联网的传输正确到达了接收方，接收方按序接收它们：

当接收完0号和1号数据分组后，给发送方发送了一个累积确认ACK1，当接收完2~4号数据分组后，又给发送方发送了一个累积确认ACK4。
假设ACK1在传输过程中丢失了，而ACK4正确到达了发送方：

发送方接收ACK4后就知道了，序号为4及之前的数据分组已经被接收方正确接收了，于是将发送窗口向前滑动五个位置：

这样就有新的序号落入了发送窗口，发送方可以将收到确认的数据分组从缓存中删除了。而接收方可以择机将已经接收的数据分组交付上层处理。从本例可看出，累积确认的其中一个优点就是即使确认分组丢失，发送方也可能不必重传。例如本例中ACK1丢失了，但并没有造成1号数据分组的超时重传。使用累积确认还有其他好处，例如可以减少接收方的开销减少对网络资源的占用。当然了，使用累积确认也有缺点，那就是不能向发送方即使反馈接收方已经正确接收的数据分组信息。
接下来我们看出现差错的情况，发送方将序号落在发送窗口内的这个5个数据分组依次连续发送出去：

在传输过程中假设遇到了干扰，其中5号数据分组出现了误码：

接收方通过数据分组中的检错码发现了错误，于是丢弃该数据分组：

而后续到达的这4个数据分组的序号与接收窗口中的序号不匹配：

接收方同样也不能接受它们，将它们丢弃，并对之前按序接收的最后一个数据分组进行确认，也就是发送ACK4：

每丢弃一个数据分组就发送一个ACK4，这4个ACK4经过互联网的传输到达了接收方，发送方之前就接收过ACK4：

当收到这些重复的ACK4时，就知道了之前所发送的数据分组出现了差错，于是可以不等待超时计时器超时就立刻开始重传。至于收到几个重复确认就立刻重传，由具体实现来决定，在本例中假设收到这4个重复的确认并不会触发发送立刻重传，一段时间过后，超时计时器出现超时，发送方将发送窗口内已发送过的这些数据分组全部重传：

可见，当通信线路质量不好时，回退N帧协议的信道利用率并不比停止等待协议高。
接下来我们来看看如果发送窗口的尺寸WT超过其取值范围的上限会发生什么情况。对于本例，因为WT的最大值为7，那么我们故意将WT取成8，所以发送方会将序号落在发送窗口内的0~7号这8个数据分组依次发送出去：

它们经过互联网的传输正确到达了接收方，接收方正确接收它们后，给发送方发挥累积确认ACK7：

假设ACK7在传输过程中丢失了，这将导致发送方的超时重传：

重传的0~7号数据分组到达接收方，现在问题来了，接收方根据当前接收窗口内的序号会对这个8个数据分组按序接收。但是，接收方之前已经接收过这8个数据分组了，现在是在重复接收，也就是说接收方无法分析新旧分组，进而会产生分组重复这种传输差错：

因此发送窗口的尺寸不能超过其上限。

最后总结一下：

选择重传协议SR

在介绍该协议之前，先明白下面这些内容：

下面我们来举例说明选择重传协议的工作原理。
假设采用3个比特给分组编序号，因此序号的取值范围是0~7，双方的分组序号皆如下所示（基本条件和上一小节一样，不再重复叙述），不一样的地方在于，接收窗口的尺寸WR的取值一般情况下可与发送窗口的尺寸WT的取值相同，在本例中其值为4：

发送方将落在发送窗口内的这4个数据分组依次连续发送出去，直到到达接收方：

但其中的2号数据分组丢失了：

但只要序号落入接收窗口内且无误码的数据分组，接收方都会接收。接收方接收0号和1号数据分组，并发送0号和1号确认分组，接收窗口向前滑动两个位置，这样就有4和5这两个新的序号落入接收窗口：

接收方接收3号数据分组，并发送3号确认分组，但接收窗口不能向前滑动：

因为3号数据分组是未按序到达的数据分组。这些确认分组经过互联网的传输陆续到达发送方，发送方每按序收到一个确认分组，发送窗口就向前滑动一个位置，发送方接收0号和1号确认分组，发送窗口向前滑动两个位置：

这样就有4和5这两个新的序号落入发送窗口。发送方将序号落入发送窗口的4号和5号数据分组发送出去：

发送方现在可以将已经收到确认的0号和1号数据分组从发送缓存中删除了。而接收方可以择机将已经按序接收的0号和1号数据分组交付给上层处理。发送方接收3号确认分组，但发送窗口不能向前滑动，因为这是一个未按序到达的确认分组：

发送方还未收到它之前的2号确认分组，不过，需要记录3号数据分组已收到确认，这样该数据分组就不会超时重发：

4、5号分组到达接收方，并且接收方接收了他们，并发送了4、5号确认分组，但接收窗口不能向前滑动，因为它们是未按序到达的数据分组：

接收方还未收到它们之前的2号数据分组，假设在4、5号确认分组的传输过程中，发送方针对2号数据分组的重传计时器超时了，发送方重传2号数据分组：

4、5号确认分组陆续到达发送方，发送方接收它们，但发送窗口不能向前滑动，因为它们是未按序到达的确认分组，发送方还未收到它们之前的2号确认分组。不过，需要记录4号和5号数据分组已收到确认，这样它们就不会超时重发：

发送方之前重传的2号数据分组到达接收方，接收方接收该数据分组，并发送2号确认分组，接收窗口现在可以向前滑动4个位置，这样就有6、7、0、1这四个新的序号落入接收窗口，2号确认分组经过互联网的传输到达发送方：

发送方接收该确认分组，发送窗口可以向前滑动4个位置，这样就有6、7、0、1这四个新的序号落入发送窗口：

发送方现在就就可以继续将这四个序号的数据分组依次发送出去了。

接下来我们再来讨论一下，选择重传协议的发送窗口和接收窗口的尺寸问题：

论证原理和之前上一小节的内容一样，可自己推导，这里不再赘述。

总结一下：