扫码获取 VIP 码
添加管理员微信获取 VIP 码
软考网络工程师和软件设计师的考生，几乎都在同一个地方栽过跟头：题目一旦涉及发送窗口大小、序列号位数、信道利用率这些词，就开始慌乱，不知道该套哪个公式。本文不绕弯子，直接从数据链路层的可靠传输机制讲起，把停止等待协议、回退N帧协议、选择重传协议三者的底层逻辑、窗口约束和计算套路一次讲透。
在展开三种协议之前，必须先把一个前提讲清楚：数据链路层为什么需要可靠传输。数据链路层位于物理层之上，它的职责是把比特流组织成帧，并在相邻两个节点之间完成无差错的数据投递。然而物理层提供的信道并不完美，帧在传输过程中可能因为噪声干扰、信号衰减、碰撞等原因发生错误或丢失。对于有线局域网中常见的误码，接收方可以通过差错检测码发现帧出错；但对于帧的完全丢失，接收方根本感知不到有东西要到来。于是，数据链路层必须引入一套机制，让发送方知道哪些帧被正确接收、哪些帧需要重发，这套机制就是自动重传请求，通常简写为ARQ。
ARQ的核心思想并不复杂：发送方发出一个数据帧后，接收方若正确收到，就回送一个确认帧；发送方在等待一段时间后若仍未收到确认，就认为该帧已丢失或出错，随即重发。这个"发一个、等确认、必要时重发"的过程，就是最朴素的停止等待协议，它是所有滑动窗口协议的原型。
然而停止等待协议的效率极低。想象一条传播时延很长的信道，发送方发完一个帧后，要干等整整一个往返时间才能发出下一个帧，信道大部分时间处于空闲状态。为了解决这个效率问题，人们在停等协议的基础上发展出了流水线式传输：发送方不等确认，连续发出一批帧，确认信息随后陆续返回。为了管理这些"在途"的帧，协议引入了"窗口"的概念，这就是滑动窗口协议名称的由来。
停止等待协议，英文全称Stop-and-Wait，是数据链路层可靠传输的起点。它的工作流程可以用四个字概括：发一、等一、验一、再发。发送方每发送一个数据帧，就立即启动超时定时器并停下来等待；接收方收到帧后先做差错检验，若无误则回送确认帧，若有误则直接丢弃并等待重传；发送方收到确认后，把待发送的下一帧填入缓冲区继续发送；若定时器超时仍未收到确认，则重发刚才那一帧。整个过程严格串行，任何一个时刻在信道上"在途"的数据帧最多只有一个。
停止等待协议之所以能保证可靠，靠的是超时重传和编号两个关键设计。超时重传解决了帧丢失的问题：无论是数据帧丢了还是确认帧丢了，发送方最终都会因为等不到确认而超时，然后重发。编号则解决了重复帧的问题：假如确认帧丢失，发送方重发了数据帧，接收方会再次收到同一个帧，此时它需要靠帧的序号判断这是新帧还是旧帧，从而避免把重复数据交给上层。停等协议中，用一位二进制序号，即0和1交替，就足以区分相邻两帧。
停止等待协议的致命缺陷在于信道利用率太低。如果数据帧的发送时延远远小于往返传播时延，那么发送方绝大部分时间都在空等确认，信道的传输能力被白白浪费。滑动窗口协议正是为解决这一矛盾而提出的。它允许发送方在收到确认之前连续发送多个帧，让多个帧在信道上"排队流动"，从而把原本被往返时延吃掉的空闲时间利用起来，显著提升吞吐量。
所谓窗口，本质上是发送方和接收方各自维护的一个帧序号区间，窗口内允许发送或接收的帧是有限的。随着确认信息不断到达，窗口沿序号方向向前移动，就像一扇沿序列号轴滑动的窗子。窗口越大，允许在途的帧就越多，信道的利用潜力就越高，但同时对序号管理、缓存资源和差错恢复的要求也越苛刻。窗口大小与序列号空间之间的约束关系，正是软考计算题的核心命题点。
需要特别说明的是，数据链路层的帧序号采用循环编号的方式，序号是有限的整数，用固定长度的二进制字段表示。当窗口向前滑动到序号空间末尾时，序号会回绕到起点重新使用，这就带来了一个根本性的问题：旧帧的序号和新帧的序号可能相同，接收方凭什么区分它们。正是这个序号回绕的问题，决定了窗口大小不能任意取值，必须与序号空间保持严格的数学关系。理解这一点，就抓住了所有窗口约束题的命门。
要真正掌握滑动窗口协议，不能只记住"窗口越大效率越高"这句话，必须理解窗口、确认、重传三者是如何协同工作的。这部分是原理层面的深挖，也是理解后面计算题的基石。
发送窗口是发送方允许连续发送而无需等待确认的帧序号集合。发送窗口的大小记为W，它限定了信道上最多可以同时在途的数据帧数量。发送方每发出一个帧，窗口的下界就占用一个位置；每收到一个确认，窗口下界前移，腾出的位置允许新的帧进入。当窗口被填满而确认尚未返回时，发送方必须停止发送，等待确认。
接收窗口是接收方允许接收的帧序号集合。在停止等待和回退N帧协议中，接收窗口大小都为1，意味着接收方只按顺序接收期望的那一帧，任何乱序到达的帧都会被丢弃。而选择重传协议允许接收窗口大于1，接收方可以把乱序但正确的帧缓存起来，等待缺失帧补齐后再统一上交。接收窗口的存在与否、大小如何，直接决定了协议出错时的重传代价。
确认机制是滑动窗口协议的"心跳"。累计确认是指接收方并不为每一个帧单独发送确认，而是只对连续正确收到的最后一个帧发确认，这一个确认隐式地表示它之前的所有帧也都已正确收到。例如接收方正确收到序号0、1、2的帧后，只需发送"确认2"，发送方就明白0、1、2都已妥收。累计确认的优点是节省确认帧的数量，缺点是它无法告知发送方"后面某个帧其实已经正确收到"。
捎带确认则是一种进一步节约带宽的技巧：当接收方同时也有数据要发送时，它把确认信息"搭车"放在自己发出的数据帧的确认字段里，而不是单独发一个确认帧，从而减少链路上的帧数量。双向通信场景下，捎带确认能有效降低协议开销，但也会引入额外的等待，因为发送方要凑到自己有数据可发时才能把确认带出去。
超时重传是滑动窗口协议应对帧丢失的最后一道防线。发送方每发一个帧（或一批帧）都会启动定时器，若在超时时间内没有收到对应的确认，就判定该帧已丢失并重发。超时时间的设置至关重要：设得太短，正常的确认还没回来就被误判为丢失，造成不必要的重传和拥塞；设得太长，一旦真的丢帧，恢复时间又被拉长。工程上通常把超时时间设为略大于往返时延，往返时延等于数据帧传播到接收方、再等确认帧传回发送方的总时间。
在计算题中，往返时延是判断信道利用率的核心参数。停止等待协议下，发送方发完一帧后必须等待一个完整往返时延才能继续，因此其信道利用率等于发送时延除以"发送时延加往返时延"。理解了这一点，后面所有关于利用率的计算就都有了统一的推导逻辑。
滑动窗口协议按出错后重传范围的不同，分为停止等待、回退N帧和选择重传三种。这一部分是软考考查最密集的区域，尤其是三者的窗口约束和序列号空间计算。
停止等待协议本质上是发送窗口等于1的滑动窗口协议。它的信道利用率可以严格推导。设一帧的发送时延为T，帧从发送方传到接收方的传播时延为t，那么发送方从发出帧到收到确认帧，至少要经历发送时延T加上往返传播时延2t。因此信道的有效利用率等于T除以T加2t。当传播时延远大于发送时延时，即2t远大于T，利用率趋近于零；只有在发送时延远大于传播时延时，利用率才能接近百分之一百。
这个公式是软考高频计算点。例如题目给出链路数据率、帧长和传播时延，要求计算停止等待协议下的最大吞吐量或信道利用率，解法就是先把帧长除以数据率得到发送时延，再套用上述公式。命题人常常在这里设陷阱：把传播时延误当成单向时延、漏乘2，或者把确认帧的发送时延也计入往返时间。只要抓住"往返时延等于两倍传播时延"这一本质，就能避开这些坑。
回退N帧协议，英文Go-Back-N，简称GBN，是流水线传输的经典实现。发送方允许在收到确认前连续发送最多W个帧，接收方只按序接收，采用累计确认。一旦某一帧出错或丢失，接收方会丢弃它之后所有乱序到达的帧，并要求发送方从出错的帧开始重新发送其后全部帧，也就是"回退重传"。这就是GBN名称的由来：出错点之后的N个已发帧统统作废，退回重来。
GBN的发送窗口大小受序列号位数严格约束。假设用n位二进制表示帧序号，则序号空间总共有2的n次方个取值。为了保证协议正确运行，GBN的发送窗口必须满足W小于等于2的n次方减1。这个约束的深层原因是：GBN采用累计确认，
本篇完！