Appearance
停止-等待协议
2026 大纲 三(四)2 停止-等待协议。信道利用率公式的原始推导集中在本篇,GBN 与 SR 只在本篇公式上乘窗口因子;窗口上限的推导反过来在那两篇。
一、丢弃之后呢
前两节把差错这件事处理到了这一步:CRC 查出坏帧、整帧丢弃。可丢弃之后那份数据就这么没了——上层不会自动拿到它,发送方也毫不知情。
CRC 只带来无比特差错,而帧丢失、帧重复、帧失序这三类里连一个比特都没错,它一概查不出。要补上这一段,还差三件事:
- 编号——让接收方区分"我等的新帧"与"上一帧的重传";
- 确认 ACK——让发送方知道对方到底收到没有;
- 超时重传——没等到确认就再发一次。
停止-等待协议就是这三件事的最简组合:发完一帧停下来等确认,收到才发下一帧。它是本章后面所有可靠传输协议的骨架,GBN 与 SR 都只是在它之上放开"一次能发几帧"这一条。
顺带说清 ARQ 里"自动"指的是谁:指重传由发送方超时自动发起。接收方不需要请求重传;实用协议一般也不发否认帧,检出差错就静默丢弃。
二、四种情形,动作只有一个
情形一:无差错
情形二:数据帧出错或丢失
"检出差错丢弃"与"帧根本没到"在接收方看来完全一样——都是"没收到",都不发任何信息。
情形三:ACK 丢失
这就是帧必须编号的直接理由:没有编号,接收方无法判断收到的是新帧还是重传帧,只能把重复数据也交给上层。可靠传输不只要求"不丢",同样要求"不重"。
而且接收方收到重复帧要做两件事:丢弃数据并且重发 ACK。不能因为"我已经确认过了"就沉默——发送方之所以重传,正说明它没收到那个确认,沉默会让它一直超时下去。
情形四:ACK 迟到
没出任何差错,只是 ACK 走得慢,在超时之后才到。发送方收下重复的确认后什么也不做;接收方那边同样丢弃重复帧、重传确认。
把四种放在一条时间轴上
设发送时延
| 时刻(ms) | 情形一(正常) | 情形二(数据帧丢) | 情形三(ACK 丢) | 情形四(ACK 迟到) |
|---|---|---|---|---|
| 0 | 发帧 0,启动计时器 | 发帧 0,启动计时器 | 发帧 0,启动计时器 | 发帧 0,启动计时器 |
| 21 | 接收方收到帧 0,交付上层 | 接收方什么也没收到 | 接收方收到帧 0,交付上层 | 接收方收到帧 0,交付上层 |
| 21 | 接收方发 ACK 0 | — | 接收方发 ACK 0(中途丢失) | 接收方发 ACK 0(走得慢) |
| 41 | 发送方收到 ACK 0,撤销计时器,发帧 1 | 发送方仍在等 | 发送方仍在等 | 发送方仍在等 |
| 45 | — | 超时,重传帧 0 | 超时,重传帧 0 | 超时,重传帧 0 |
| 66 | — | 接收方首次收到帧 0,交付上层 | 接收方发现重复帧:丢弃数据,重发 ACK 0 | 接收方发现重复帧:丢弃数据,重发 ACK 0 |
这张表最值得记的是它的列间关系:第三、四列在接收方看来是同一件事(收到重复帧),第二列则是"第一次收到";而发送方三列的动作完全一致。
换句话说,发送方在超时那一刻根本分不清是哪一种,也不需要分清——四种的正确动作都是重传。协议的健壮性正来自"用同一个动作覆盖所有分不清的情况",正确性则由接收方靠编号去重来兜底。
顺带一提:ACK 出错等同于 ACK 丢失。ACK 帧同样带校验,出错后发送方无法识别它,照样超时重传,分析时并入"ACK 丢失"这一类即可。
三、帧编号:1 位就够,也不必更多
为什么够。 任何时刻发送方最多只有一个已发送未确认的帧,接收方也只期待一个特定编号的帧,需要区分的只有"我正在等的新帧"和"上一帧的重传"两种情况——两个取值恰好够用。用后面几节的统一约束看即
为什么不用更多位。 多用几位不会出错,只是纯浪费:编号字段每多 1 位,每帧就多背 1 位开销,而停止-等待协议永远用不到第 3 个编号——它一次只允许一个帧在途。
但 1 位编号依赖一个前提:"旧帧不会长时间滞留后冒出来"。链路层路径短、时延有界,这个前提成立;运输层的报文段可能在网络中长时间滞留,前提不成立——这是 TCP 用 32 位序号的原因之一。
超时时间应比"数据在分组传输的平均往返时间"更长一些。太短会引发无谓重传,太长则发现丢帧太慢。链路层可以用固定值,运输层必须动态估算。
另外,发送方必须保留已发送帧的副本直到收到对应确认,副本不能提前丢。停等只要 1 个缓冲区,GBN/SR 则整个发送窗口都要留副本。
交互可视化
四、信道利用率:这一节的计算核心
一个完整周期依次发生五段:
周期长
分母是"一个完整周期",这是本节最容易丢分的地方。 题面给出了 ACK 帧长或接收方处理时延、而且没说忽略,就必须把对应的那一段加进分母;缺一段都会把
忽略
三个量各自往哪个方向推
先分清两个常被混起来的量:
| 参数变化 | |||
|---|---|---|---|
| 帧长变大 | 变大 | 变小 | 升高 |
| 数据率变大 | 变小 | 变大 | 降低 |
| 链路变长 | 不变 | 变大 | 降低 |
第二行反直觉,值得单独记:提高数据率反而降低利用率。
改进方向只有一个:让发送方在收到确认之前就能连续发多个帧,即流水线传输。要让信道满载需要的窗口大小是
本节小结
- CRC 只解决"错帧不被误收",可靠传输还差编号、确认、超时重传三件事;ARQ 的"自动"指重传由发送方超时自动发起,接收方不需要请求。
- 四种情形中发送方分不清也不需要分清,动作都是重传;正确性由接收方靠编号去重兜底——收到重复帧必须丢数据并且重发 ACK。1 位编号够用,但依赖"旧帧不会长时间滞留"这个只在链路层成立的前提。
- 利用率把一个周期拆成五段,只有
在送有用数据,故 ,忽略后两项得 。帧变长 → 小 → 升;数据率变高或链路变长 → 大 → 降;要让信道满载需 ,这把停等引向了流水线传输。
考点速记
本节在真题里被考过的形式全部围绕那一条利用率公式,两道题恰好把它的两个方向都考了一遍,而且分岔口是同一个:分母里到底该放几段。
① 给利用率反求帧长(cn-2018-36)。3 kbps、单向传播 200 ms、忽略确认帧的传输时延、
② 正求最大利用率(cn-2020-36)。10 kbps、单向 200 ms、数据帧长与确认帧长均为 1000 B。题面给了确认帧长且没说忽略,
两道题放在一起看就清楚了:题面写不写"忽略确认帧",直接决定分母是三段还是两段。 漏掉
易错:分母是一个完整周期,不是只有
。 题面给出确认帧长或接收方处理时延而没说忽略,就必须加进去。反过来,明说"忽略确认帧传输时延"时就不能画蛇添足地加。
易错:
是简化式,用它的前提是 与 都被忽略。 直接背这个式子去套给了确认帧长的题,必错。
易错:单向传播时延要乘 2 才是
。 题面给的几乎总是单向值。
易错:提高数据率会降低停等的信道利用率。
变小而 不变, 变大。绝对吞吐量可能仍上升,但被浪费的比例更大——这两句话不矛盾,选项常拿它做文章。
易错:帧长的单位。 题面给"1000 B"要先乘 8 变成 8000 bit 再除以 bit/s 的速率。
易错:接收方收到重复帧必须重发 ACK,不能沉默。发送方重传恰恰说明它没收到上一个确认。
教材出处
- 谢希仁《计算机网络》(第 8 版)p221(5.4 可靠传输的工作原理 / 5.4.1 停止等待协议):给出理想传输条件的两条前提,以及协议定义——"'停止等待'就是每发送完一个分组就停止发送,等待对方的确认。在收到确认后再发送下一个分组"。同页脚注指出这种协议源自早期链路层:"在计算机网络发展初期,通信链路不太可靠,因此在链路层传送数据时都要采用可靠的通信协议。其中最简单的协议就是这种'停止等待协议'。"
- 同书 p222(2. 出现差错):超时重传的定义与三条必须注意的要点——"A 在发送完一个分组后,必须暂时保留已发送的分组的副本";"分组和确认分组都必须进行编号";"超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些"。同页脚注还说明了编号回绕问题:"在所发送的分组中,必须能够区分开哪些是新发送的,哪些是重传的。对于在链路上传送的帧,如果用停止等待协议,只取 1 位的编号即可。"
- 同书 p223(3. 确认丢失和确认迟到):接收方收到重传分组时的两个动作——"丢弃这个重复的分组 M1,不向上层重复交付","向 A 发送确认。不能认为已经发送过确认就不再发送,因为 A 之所以重传 M1 就表示 A 没有收到对 M1 的确认";确认迟到的处理是"收下后就丢弃,但什么也不做"。同页给出 ARQ 的命名解释——"意思是重传的请求是自动进行的,因此也可见到自动请求重传这样的译名。接收方不需要请求发送方重传某个出错的分组。"
- 同书 p224(4. 信道利用率):信道利用率公式
的完整推导与一个数值例子——1200 km 信道 ms、分组长 1200 bit、发送速率 1 Mbit/s 时 ;若把发送速率提高到 10 Mbit/s, 反而降到 。同页给出改进方向:"为了提高传输效率,发送方可以不使用低效率的停止等待协议,而是采用流水线传输。"
相关知识
差错检测(CRC 校验)|后退 N 帧协议(GBN)|选择重传协议(SR)|三种 ARQ 协议对比|TCP 可靠传输