扫码获取 VIP 码
添加管理员微信获取 VIP 码
数据链路层承担着在相邻两个结点之间透明传输帧的职责，但物理信道并不理想。噪声、干扰、信号衰减会让比特在传输过程中发生差错，甚至整帧丢失。要在这个不可靠的物理介质之上构造出可靠的逻辑信道，数据链路层必须正面回答三个基本问题。第一个问题是差错检测，接收方要能发现收到的帧是否出错，这依赖校验技术，比如循环冗余校验CRC，它通过生成多项式与模二除法为每个帧附加冗余的校验信息，接收方用同样的多项式对收到的帧重新计算，余数不为零即可判定出错。第二个问题是确认与重传，发送方如何得知对方是否成功收到，一旦失败又如何补救，这正是自动重传请求机制要解决的核心，它要求接收方在正确收到帧后回送确认，发送方在超时未收到确认时重发。第三个问题是帧的编号与顺序，接收方要把乱序到达的帧重新排序，丢弃重复的帧，这需要为每个帧分配序号。滑动窗口协议正是把这三个问题统合起来的一整套解决方案，它既规定了确认与重传的时机，又规定了发送方和接收方各自允许使用的序号范围，同时借助序号实现了流量控制。需要强调的是，可靠传输的思想并不只停留在数据链路层，传输层的TCP同样借鉴了滑动窗口与确认重传的机制，这正是软考命题人偏爱跨层对比的根源。
自动重传请求，英文缩写为ARQ，Automatic Repeat reQuest，是差错控制的基本策略。它的逻辑十分朴素：接收方检测到差错或超时未收到数据时，就要求发送方重发。根据重发范围的不同，ARQ演化出停等ARQ、回退N帧ARQ和选择重传ARQ三种形式，这三种形式恰好对应滑动窗口协议的三个基本变体。滑动窗口则是实现流量控制与序号管理的手段。所谓窗口，本质上是发送方和接收方各自维护的一段连续的序号区间。发送窗口规定了发送方在未收到确认之前最多可以连续发出多少个帧，接收窗口规定了接收方当前愿意接收的序号范围。窗口内的序号可以操作，窗口外的序号要么尚未使用，要么暂时禁止进入。随着确认帧的到达，窗口像一扇在序号序列上滑动的窗，不断向前移动，这就是滑动窗口名称的由来。理解窗口是理解全部可靠传输协议的一把钥匙，无论是数据链路层的HDLC、PPP，还是传输层的TCP，其序号管理与流量控制都建立在滑动窗口的思想之上。在标准术语里，发送窗口大小常用WS表示，接收窗口大小常用WR表示，序号空间的总量则由序号字段的比特数决定，这些符号是理解后续计算题的共同语言。此外还需要辨析两个容易混淆的概念：差错控制与流量控制。差错控制关心的是如何发现并纠正传输过程中的错误，主要手段是校验、确认与重传；流量控制关心的是如何调节发送速率，避免接收方被过量的数据淹没，主要手段就是窗口。滑动窗口协议之所以重要，正是因为它同时承担了这两项职责，用一个窗口机制把差错控制与流量控制有机地结合在一起，这也是它在网络工程知识体系中占据核心地位的原因。
发送窗口的大小记为WS，它限定了发送方在等待确认之前能够连续发送的最大帧数。发送方只能发送序号落在发送窗口内的帧，每发送一帧，窗口的可用空间就减少一个；每收到一个确认帧，窗口就向前滑动相应的距离。发送窗口还有一个重要的约束：发送窗口内已经发出但尚未确认的帧，其序号必须彼此可以区分。如果序号空间太小，新帧的序号就会与还在途中的旧帧发生混淆，导致接收方无法判断这是新帧还是重传帧，这就是序号空间必须大于窗口大小的根本原因。接收窗口的大小记为WR，它限定了接收方当前愿意接受的序号范围。当接收方收到一个序号落在接收窗口内的帧时，就把该帧缓存下来，并把窗口向前滑动；如果收到的帧序号落在接收窗口之外，接收方通常会将其丢弃。滑动窗口的另一个精妙之处在于它天然地实现了流量控制，发送窗口的大小直接限制了发送方可以同时注入网络的帧数量，从而避免发送方把接收方或中间链路淹没。发送窗口越大，允许同时发送的帧越多，信道利用率越高，但对接收方缓冲能力和序号空间的要求也越高，这是一个需要权衡的工程问题。还需要注意窗口滑动的具体时机：发送方是在收到确认帧之后才滑动发送窗口，而不是在发送帧之后立即滑动，这一点常被初学者误解。接收方则是在正确收到并按序上交给网络层之后才滑动接收窗口。窗口滑动的方向始终是单向向前的，序号循环使用但窗口不会回退，这种单向性保证了协议状态的单调演进，便于证明其正确性。
确认帧是接收方向发送方传递的信号，表明某一帧或某些帧已经成功接收。确认有两种语义。一种是逐帧确认，即每一个正确收到的帧都单独回复一个确认，这种方式的优点是指示精确，缺点是确认帧本身也要消耗信道资源，而且确认帧过多会加重接收方和信道的负担。另一种是累积确认，接收方回复的确认序号N表示序号N及其之前的所有帧都已经正确接收。累积确认是回退N帧协议和TCP普遍采用的机制，它的好处是即便某个确认帧丢失，后续更大的确认序号仍然能够覆盖之前的信息，抗丢包能力强；它的代价是当中间某一帧出错时，发送方无法精确知道哪些帧已经成功、哪些需要重传，只能采用相对保守的回退策略。理解确认语义的关键在于认清一个事实：确认序号代表的是一道分界线，而不是单个帧。累积确认的确认序号N等于接收方期望收到的下一个帧的序号，它隐含地声明了序号小于N的所有帧都已成功到达。这种语义设计让确认信息更加紧凑，也为发送方简化了重传决策的逻辑。
序号空间的位数决定了可用序号的数量。如果用k个比特表示序号，那么序号从0到2的k次方减1循环使用。窗口大小与序号空间之间必须满足一条铁律：发送窗口与接收窗口之和不能超过序号空间的总量。对于回退N帧协议，接收窗口固定为1，因此发送窗口必须严格小于2的k次方，最多取2的k次方减1；如果取到2的k次方，就会出现新旧帧序号无法区分的致命问题，因为发送方发出的第2的k次方个新帧与最旧的一个未确认帧使用了相同的序号，接收方无法判断它到底是新数据还是迟到的重传。对于选择重传协议，由于接收窗口大于1，约束更为严格，发送窗口与接收窗口之和不得超过2的k次方，通常二者相等时各取2的k次方的一半。这条约束是整个滑动窗口计算题的题眼，历年真题反复围绕它出题。考生必须从原理上吃透这条约束的由来，它本质上是在回答一个问题：在序号循环使用的条件下，怎样保证任何一个序号在任一时刻都不会被两个含义不同的帧同时占用。只有真正理解了这个疑问，才能在题目变换窗口大小、序号位数时从容应对，而不是死记公式。不妨用一个具体的例子来巩固：如果序号字段是3位，那么序号空间是8个值，从0到7。对于GBN协议，发送窗口最大只能取7，因为一旦取到8，发送方发出第8个新帧时，它的序号会与最早那个尚未确认的帧的序号完全相同，接收方收到一个与旧帧同号的新帧时，就会误以为这是那个旧帧的重传而将其当作重复帧丢弃，导致数据丢失。这个例子清楚地说明了序号空间必须严格大于发送窗口的必然性，也解释了为什么计算题里的答案总是比窗口大小多出一位。
停等协议是滑动窗口协议的一个特例，它的发送窗口和接收窗口都等于1。发送方每发送一个帧之后，就停下来等待接收方的确认，只有收到确认帧才发送下一个帧；如果超过一定时间仍未收到确认，就重发该帧。停等协议的优点极其明显：实现简单，序号空间只需要1个比特，0和1交替使用就能区分新旧帧，接收方不需要缓存能力，硬件和软件的开销都降到最低。但它的缺点同样致命：信道利用率极低。在发送方等待确认的这段时间里，信道完全空闲，等于把大量带宽白白浪费。设帧长为L，数据率为C，单向传播时延为R，那么停等协议的信道利用率可以近似表示为L除以L与2RC之和，当传播时延远大于发送时延时，利用率趋近于零。这个公式揭示了停等协议的本质矛盾：它把发送和等待串行化，导致信道上大量时间处于沉默状态。因此停等协议只适合传播时延短、数据率低、可靠性要求不苛刻的场合，比如早期的点到点链
本篇完！