Appearance
后退N帧协议(GBN)
2026 大纲 三(四)3 后退 N 帧协议(GBN)。
的推导(含序号绕回反例)集中在本篇; 的一般形式在《选择重传协议 SR》,利用率公式的原始推导在《停止-等待协议》。
一、停等把信道空着,那就连续发
上一节结尾算出了一个很难看的数:卫星链路上停止-等待的利用率不到 3%。原因很直白——发完一帧就干等一个 RTT,这段时间信道完全空着。
改进思路只有一条:发送方连续发送多个帧,不必每发完一个就停下来等确认,让信道上一直有数据在传。这就是流水线传输,配套的协议叫连续 ARQ 协议。
但"连续发"不能无限制:发送方必须为每个未确认帧保留副本,缓冲区有限;接收方的处理能力也有限。这个上界就是发送窗口
| 区域 | 含义 | 能不能丢副本 |
|---|---|---|
| 窗口左侧 | 已发送且已确认 | 能 |
| 窗口内、已发出 | 已发送但未确认 | 不能,随时可能要重传 |
| 窗口内、未发出 | 可以立即发送 | — |
| 窗口右侧 | 还不允许发送 | — |
窗口同时承担两个职责:可靠传输(窗口内保留副本以备重传)+流量控制(限制未确认数据量,天然防止淹没接收方)。滑动规则是:每收到一个确认,左边界前移到"被确认帧的下一个",右边界随之前移同样格数。
GBN 是流水线的第一种做法,它由三条互相咬合的规则定义:
这条链条是本节的主线,四个环节一个推一个,下面逐段拆开。
二、接收窗口为 1:一笔主动做的交易
丢掉一个正确无误的帧看起来很浪费,但这是一笔主动做的交易:
| 代价 | 换来什么 |
|---|---|
| 乱序帧被丢弃,将来要重传 | 接收方不需要缓冲区,只需记住一个"期望序号" |
| — | 接收方不需要重排序逻辑,收到什么就交付什么,天然按序 |
| — | 接收窗口只占一格,使发送窗口能开到 |
在误码率低的链路上这笔账划算:乱序本来就很少发生,为那点小概率养一整套缓冲与重排逻辑不值得。误码率高时账就翻过来了,那时该用 SR。
三、累积确认:信息的粒度决定重传的粒度
接收窗口为 1,接收方就只能说"到第几帧为止我都收全了",说不出"第 4、5 帧其实到过"。于是确认只能是累积的:
ACK
累积确认有一个很实用的好处:中间的 ACK 丢了不必重传——后面任何更大的 ACK 都会把它覆盖掉。做题时这一条会直接省掉一大堆分析。
代价也很硬:它无法反映接收方的详细接收情况。发 5 帧丢了第 3 帧,接收方只能确认到第 2 帧,第 4、5 帧其实到过、发送方却一无所知。信息的粒度决定了重传的粒度——这正是 GBN 效率损失的根源。
对乱序帧的处理还留下一条线索:接收方每丢弃一个乱序帧,就重发上一个按序帧的 ACK。这些重复 ACK 是发送方察觉"中间丢了帧"的唯一提示(TCP 的快速重传把这条线索用到了极致)。
⚠️ 编号口径有两种。 一种是"ACK
确认到第 帧"(链路层讲法),一种是"ACK 表示期待第 帧、即 及之前已收到"(TCP 讲法)。读题以题面给定的口径为准,不要跨口径套用。
四、超时回退重传
最早的那个未确认帧超时时,发送方回退到该帧,把它及其后所有已发送的帧全部重传——"后退 N 帧"的名字就来源于此。
重传范围是:从最早的未确认帧,到已发出的最后一帧。 两头都要卡准——不是只重传丢失的那一帧(累积确认给不出那个信息),也不包括窗口内还没发出的帧。
图上看不出每个时刻窗口在哪、接收方在等谁,把这两列补上就完整了。设
| 时刻 | 发送方动作 | 发送窗口 | 接收方期待 | 接收方动作 | 回送 |
|---|---|---|---|---|---|
| 发帧 0 | 0 | 收下帧 0,交付上层,期待+1 | ACK 0 | ||
| 发帧 1 | 1 | 收下帧 1,交付上层,期待+1 | ACK 1 | ||
| 发帧 2(丢失) | 2 | 什么也没收到 | — | ||
| 发帧 3 | 2 | 收到帧 3 ≠ 期待的 2 → 丢弃 | ACK 1(重复) | ||
| 收到 ACK 0,窗口滑 1 格 | 2 | — | — | ||
| 收到 ACK 1,窗口滑 1 格;发帧 4 | 2 | 收到帧 4 ≠ 2 → 丢弃 | ACK 1(重复) | ||
| 发帧 5 | 2 | 收到帧 5 ≠ 2 → 丢弃 | ACK 1(重复) | ||
| 连收 3 个重复 ACK 1,且帧 2 超时 | 2 | — | — | ||
| 回退重传帧 2,3,4,5 | 2 | 收下帧 2 并交付;3,4,5 也按序到达并交付 | ACK 5 | ||
| 收到 ACK 5,窗口滑到 | 6 | — | — |
表里能直接读出三件事:① 帧 3、4、5 本身没有任何错误,只因为帧 2 丢了就被丢弃、被重传,这就是 GBN 的效率损失;② 发送方在
窗口大小直接改变重传范围。 同样是发出帧 0,1,2,3,4 且帧 1 丢失、所有 ACK 均未丢失:
所以 GBN 的重传代价与窗口大小正相关——窗口越大流水线越满、正常时效率越高,但一旦丢帧被连累的帧也越多。
五、窗口上限
序号循环使用,就意味着同一个序号会被反复用到。接收方必须永远分得清"新的一轮"与"旧帧重传",这条要求给出了窗口的硬上限。
设
若允许
| 时刻 | 发送方 | 信道 | 接收方( |
|---|---|---|---|
| ① | 窗口 | 4 帧全部正确到达 | 依次期待 0→1→2→3,全部收下并交付上层 |
| ② | 仍在等确认 | 接收方发出 ACK 3 | 接收窗口前移到 期待帧 0(序号绕回) |
| ③ | — | ACK 3 在途中丢失 | — |
| ④ | 帧 0 超时,回退重传 帧 0,1,2,3 | 重传的帧 0 到达 | 接收方正期待帧 0 ——收下,当作新数据交付上层 |
第 ④ 步就是灾难:接收方期待的序号是 0,重传的旧帧序号也是 0,两者完全无法区分,一份重复数据被当新数据交给了上层。
若取
| 时刻 | 发送方 | 信道 | 接收方 |
|---|---|---|---|
| ① | 窗口 | 全部正确到达 | 收下 0,1,2,交付上层 |
| ② | 仍在等确认 | 接收方发出 ACK 2 | 接收窗口前移到 期待帧 3 |
| ③ | — | ACK 2 丢失 | — |
| ④ | 帧 0 超时,回退重传帧 0,1,2 | 重传的帧 0 到达 | 期待的是 3,收到的是 0 → 不是期望帧,丢弃,重发 ACK 2 |
窗口留出的那一个空格,恰好让接收方期待的序号与任何可能重传的旧序号都不相同。这就是
写成统一形式:序号空间必须同时容纳"发送方还没被确认的那批帧"和"接收方正在等的那批帧",两批不能撞号,即
记住这个统一形式比记住两个上限有用——SR 的
交互可视化
六、信道利用率:先判断有没有封顶
GBN 在一个周期
(分母那一段的来历见停止-等待协议。)
第二段的道理:当窗口大到"第一个 ACK 回来时发送方还没把窗口发完",信道就再也没有空闲时刻,利用率封顶在 1。
做题第一步永远是比较
反过来问"要让信道满载,序号位数
最后一条容易被忽略的判断:窗口越大不总是越好。窗口大提高无差错时的利用率,同时放大单次丢帧的重传代价。误码率高到几乎每个窗口都丢一帧时,GBN 的有效吞吐可能低于停止-等待——停等每次白费一帧,GBN 每次白费一整批。改进方向就是 选择重传协议 SR:接收方缓存乱序帧,只重传真正出错的那一帧。
本节小结
- GBN 的三条规则互相咬合:
→ 乱序帧只能丢弃 → 确认只能累积 → 发送方得不到"哪些帧其实到过" → 超时只能把最早未确认帧起的全部已发帧成批重传。丢弃正确的乱序帧是主动交易,换来接收方无需缓冲与重排、且发送窗口能开到 。 的实质是序号空间要同时容纳"发送方未确认的那批"和"接收方正在等的那批",两批不得撞号;留出的那一格作用就是防撞号。重传范围是从最早未确认帧到已发出的最后一帧,窗口越大被连累的帧越多。 - 利用率分段:
时 ,否则 ,分段判断是第一步。误码率高到每个窗口都丢帧时,GBN 的有效吞吐可能低于停止-等待,此时应改用 SR。
考点速记
本节是链路层出题最密的一处,在真题里被考过的形式按问法分四类:
① 数重传帧数(cn-2009-35)。已发出 0~7,超时时只收到 0、2、3 号帧的确认,问要重发几帧。关键只有一句:累积确认取收到的那些 ACK 里最大的那个——ACK 3 就意味着 0~3 全部收到,中间 ACK 1 丢了根本不影响。所以要重传的是 4、5、6、7,共 4 帧。选项里的 3 和 5 分别对应"漏看了累积"和"把已确认的 3 也算进去"。
② 求最大平均数据传输速率(cn-2014-36)。
别忘了先判断有没有封顶:
③ 反求帧序号位数(cn-2012-36)。16 kbps、单向 270 ms、帧长范围 128~512 B、接收方以与数据帧等长的帧确认,问"为使信道利用率达到最高,帧序号比特数至少为多少"。三个坑串在一起:
- 取哪个帧长:要对整个范围都满载,就得看最不利的情形——帧长最小时
最小、 最大、需要的窗口最大。取 128 B。 - 确认帧要不要算:题面明说等长,
必须进周期。 ms,周期 ms。 - 用哪个窗口上限:
;GBN 的上限是 ,故 。
④ 三种协议的利用率比大小(cn-2023-35)。同一信道、同样帧长、忽略确认帧、序号 3 比特,问停等、GBN、SR 的最大利用率关系。不必算数值,只比窗口上限:停等
另有一道 9 分综合题(cn-2017-47)考双向传输 + 捎带确认下的 GBN:给两幅收发时序图,问某时刻发送方能断定对方已正确接收哪几帧、下一帧该发什么。动作仍是本节那两条——确认序号
易错:累积确认取最大的那个 ACK。 中间的 ACK 丢失完全不影响判断,别一个个数收到了哪几个。
易错:重传范围是"最早未确认帧 → 已发出的最后一帧"。 已确认的不重传,还没发出的也不算进去。
易错:GBN 的窗口上限是
,SR 是 ,GBN 更大。 两者都从 来,代入不同的 。
易错:求利用率前先比较
与 。 已经封顶还去乘 ,会算出大于 1 的利用率。
易错:帧长给了一个范围时,取最小帧长——那是需要窗口最大的最不利情形。取最大帧长会把
算小。
易错:确认帧等长时
要进周期。 这一条与停止-等待那两道题是同一个坑。
教材出处
- 谢希仁《计算机网络》(第 8 版)p224(4. 信道利用率):给出流水线传输的引入理由——"为了提高传输效率,发送方可以不使用低效率的停止等待协议,而是采用流水线传输……流水线传输就是发送方可连续发送多个分组,不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一直有数据在不间断地传送"。
- 同书 p225(5.4.2 连续 ARQ 协议):滑动窗口的滑动规则——"连续 ARQ 协议规定,发送方每收到一个确认,就把发送窗口向前滑动一个分组的位置";累积确认的定义与利弊——"接收方不必对收到的分组逐个发送确认,而是在收到几个分组后,对按序到达的最后一个分组发送确认,这就表示:到这个分组为止的所有分组都已正确收到了。累积确认有优点也有缺点。优点是容易实现,即使确认丢失也不必重传;但缺点是不能向发送方及时反映接收方已经正确收到所有分组的信息"。同页给出 Go-back-N 的命名来源与代价——"如果发送方发送了前 5 个分组,而中间的第 3 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落,而只好把后面的三个分组都再重传一次。这就叫作 Go-back-N(回退 N),表示需要再退回来重传已发送过的 N 个分组。可见当通信线路质量不好时,连续 ARQ 协议会带来负面的影响"。
- 同书 p222 脚注:序号必须循环使用及由此产生的新旧帧区分问题——"分组编号使用的位数总是有限的,编号会重复使用……因此,在所发送的分组中,必须能够区分开哪些是新发送的,哪些是重传的"。这是本篇窗口上限推导的出发点。
相关知识
停止-等待协议|选择重传协议(SR)|三种 ARQ 协议对比