1. 别急着背协议先把流量控制这四个字拆开看把流量控制、停止等待、后退 N 帧协议 GBN这三个词放在一起很多人第一反应是考试题。我当年第一次看也确实这么想背了公式默了时序图考完就忘。真正让我搞明白它的是后来一段抓包经历一条链路明明空着传输速率却死活上不去重传日志刷得飞快查到最后发现是接收端的缓冲区被撑爆了发送端根本不知道对面已经吃不下。那会儿我才意识到这套东西根本不是纸上谈兵它是每一层可靠传输的实现骨架。这篇文章想解决的问题很具体把停止等待协议和 GBN 从能画出来变成能算出来、能写出来、能调出来。我会讲清楚它们各自解决什么问题、窗口大小为什么必须卡在那个数字上、信道利用率怎么一步步算出来、以及真在代码里实现时会在哪里翻车。适合三类人看正在啃计算机网络、想把滑动窗口彻底搞懂的同学在写通信中间件或者自定义私有协议、需要自己设计重传逻辑的开发者以及抓包时看到莫名其妙的重传、想弄清背后机制的运维和测试。1.1 一个很常见的误判流量控制和差错控制不是一回事这两个概念被混用得太厉害了。我见过不少人说TCP 有流量控制靠重传实现这话听着顺其实是错的。差错控制管的是数据别错、别丢手段是校验、确认、重传流量控制管的是别发太快让接收方喘口气手段是窗口、通告、限速。它们经常一起出现但动机完全不同。举个生活里的例子。你在给朋友寄一箱一箱的书。差错控制是路上箱子可能被摔坏所以每箱都要签收没签收就补寄。流量控制是朋友家只有一个小库房一次最多放五箱你寄第六箱他就得堆在门口淋雨所以他得提前告诉你我现在还能收几箱。摔坏和放不下是两个问题。而 GBN 和停止等待本质上是把这两件事用同一套机制合并处理了确认机制既证明收到了也隐含告诉对方我还能继续收。这是它们设计上最巧妙也最容易看漏的地方。维度差错控制流量控制拥塞控制要防的问题帧损坏、丢失、重复、失序接收缓冲区溢出网络中间节点过载判断依据校验和、序号、超时接收窗口余量丢包、时延增长典型手段ACK、NAK、重传、序号窗口大小、窗口通告慢启动、拥塞避免作用范围点到点端到端全局出问题的表现数据不对或缺失丢帧但链路没坏全链路吞吐同时塌陷1.2 为什么等这件事在网络里特别贵要理解停止等待为什么会被淘汰先得建立一个直觉光在光纤里跑也是要花钱的。信号传播速度大约每毫秒 200 公里跨城链路的单程时延就在几毫秒量级跨洲能到上百毫秒。你发出去一帧得等对面收到、处理、回确认再等确认跑回来整个来回这段时间里你的发送网卡是闲着的。闲着的这段时间就是被浪费掉的带宽。而带宽这东西是按秒计费的资源闲着等于亏钱。所以整个可靠传输协议的演进史本质就是一部如何让发送方在等确认的时候不闲着的历史。停止等待的选择是就闲着GBN 的选择是多塞几帧进去选择重传 SR 的选择是塞进去并且在出错时只补那一个。路线非常清晰。2. 停止等待协议:把每一步拆到不能拆停止等待是最朴素的可靠传输方案规则一句话讲完发一帧等确认收到确认再发下一帧超时没收到就重发。简单到不像个协议但它是理解后面所有滑动窗口协议的地基。我建议所有人在学 GBN 之前先把停止等待的四种异常情况在纸上画一遍画明白了后面窗口怎么滚就一清二楚。2.1 一次正常收发到底发生了什么正常流程是这样的发送方把上层交下来的数据封装成帧编号 0发出去同时启动一个定时器。帧经过链路到达接收方接收方先做校验校验通过就看序号发现是自己期待的 0 号于是把数据交给上层回一个 ACK0。发送方收到 ACK0停掉定时器把数据从缓冲区里删掉接着发 1 号帧。这里有几个容易被忽略的细节都是实操中会踩的。第一接收方交完数据才回 ACK还是回完 ACK 再交数据这两种做法都有。先回 ACK 效率高但如果上层处理失败比如磁盘满数据就丢了发送方还以为成功了。先交给上层再回 ACK 更稳妥代价是确认晚了一点。大多数实现选后者宁可慢一点也不能丢。第二定时器的时长怎么定定太短会误判为超时频繁重传定太长丢包恢复慢。实践中的做法是估算 RTT取一个滑动平均值再乘个系数留余量。这个思路后来在 TCP 里被做成了标准算法核心就是动态估计 方差修正因为网络时延抖动很大只看平均值会被偶尔的长尾拖死。第三重传的帧序号要不要变不变。重传的就是原来那一帧序号一样靠接收方的序号判断来去重。2.2 四种异常一种都不能漏教科书上通常列四种情况我按踩坑频率重排一下异常场景发送方怎么发现接收方怎么做关键点数据帧在路上丢了超时什么都没收到重传即可最简单数据帧到了,ACK 丢了超时收到重复帧,丢弃并重发 ACK必须靠序号识别重复ACK 迟到,发送方已重传收到旧 ACK无感发送方要丢弃过期 ACK接收方处理不过来无显式信号延迟回 ACK隐式流控,粗暴但有效第二种和第三种是重灾区。ACK 丢失这一种如果接收方没有序号机制会把重传的帧当成新数据再交付一次上层就收到两份相同数据。这个问题在文件传输里可能只是浪费在转账场景里就是灾难。所以序号不是可选项是必需项而且它的作用不是排序是去重。第三种更隐蔽。设想发送方发了 0 号帧超时了重传了一个 0 号帧这时候第一个 0 号帧的 ACK 姗姗来迟。如果发送方不加判断就认为确认到了把窗口往前推接下来发的 1 号帧就会建立在错误状态上。正确做法是ACK 里的序号必须和当前待确认的序号对上对不上就丢弃。这个检查看起来多余实际上救过无数条链路。2.3 序号只要 1 bit为什么就够了这是停止等待最优雅的地方。因为发送窗口大小是 1任何时刻在途的新帧最多只有一个。接收方只需要回答一个问题我刚收到的这个帧是新的还是上一帧的副本用一个二进制位交替 0 和 1就能完全区分。收到 0 时期待 1收到 1 时期待 0不符合期待的一律当副本处理。注意这里的前提是发送窗口为 1。一旦窗口开到 2 以上1 bit 序号立刻不够用歧义马上出现。这就是后面窗口大小约束的源头。2.4 算一遍信道利用率就明白它为什么只能待在教科书里公式很朴素U Td / (Td RTT Ta)其中 Td 是发送一帧所需时间帧长除以带宽RTT 是往返传播时延Ta 是确认帧的发送时间帧很短经常忽略。拿一组具体数字算。链路带宽 100 Mbps每帧 1500 字节也就是 12000 bitTd 12000 / (100 × 10^6) 120 μs 0.12 ms单向传播时延取 2 msRTT 4 ms。忽略 TaU 0.12 / (0.12 4) 0.0291 ≈ 2.9%也就是说一条 100 Mbps 的链路跑停止等待只能跑出 2.9 Mbps 的有效吞吐。传一个 10 MB 的文件数据量 80 Mbit理论上不限速 0.8 秒搞定实际要 80 / 2.9 ≈ 27.6 秒慢了三十多倍。换成卫星链路更夸张单程 270 msRTT 540 msU 0.12 / (0.12 540) ≈ 0.022%这个数字已经不能用低效形容了基本等于不能用。所以凡是长时延链路停止等待都是不可接受的。2.5 但它也没那么一无是处我做过几个工业现场的串口协议用的就是停止等待的变体。原因很实在链路速率低9600 bps 到 115200 bps帧短RTT 在微秒到毫秒级算出来的利用率能到 60% 以上而且逻辑简单单片机上一个状态机就写完了不用维护窗口数组不用处理乱序出问题单步调试十分钟能定位。判断标准其实就一条RTT 相对 Td 是否小到可以忽略。小就能用大就得换。这个判断比死记停止等待效率低有用得多。3. 滑动窗口:把干等换成边发边等滑动窗口不是一个具体协议是一套机制。它的核心思想特别直白既然等确认的时间里发送方闲着那就允许它一次多发几帧只要总数不超过一个上限。这个上限就是窗口。发送方每收到一个确认窗口就往前滑一格腾出位置发新帧。3.1 窗口本质是一份在途配额我更愿意把窗口理解成配额而不是什么抽象的窗口。发送窗口 Ws 的意思是我最多允许有 Ws 个帧已经发出去但还没被确认。这既是流控手段约束发送速率也是缓冲管理手段接收方只需要准备 Ws 大小的空间再多也不会来。这个配额有两个约束同时起作用发送方自己的序号空间限制它能连续发多少不重复序号的帧接收方的缓冲能力限制它能收多少两个约束取小就是实际窗口。3.2 发送窗口和接收窗口的组合决定了协议家族这是我认为最值得记住的一张表把三个协议串成了一条线协议发送窗口 Ws接收窗口 Wr接收方是否缓存乱序帧出错时的重传范围停止等待11不需要1 帧后退 N 帧 GBN11不缓存,直接丢出错帧及其后所有已发帧选择重传 SR11缓存,等缺口补齐只重传出错的那一帧看懂这张表就看懂了整个演进逻辑Wr 从 1 变到大于 1是要不要花内存换带宽的取舍。GBN 省内存代价是重传放大SR 费内存换来回退少。真实系统里很多时候是两者的混合。3.3 序列号空间、窗口大小、带宽时延积三个数怎么互相咬住这一段是实操中最容易算错的地方。要让链路跑满窗口必须足够大大到在途数据量能覆盖住链路上正在飞的数据量。这个量叫带宽时延积BDPBDP 带宽 × RTT举例1 Gbps 链路RTT 20 ms。BDP 10^9 × 0.02 2 × 10^7 bit 20 Mbit 2.5 MB每帧 1500 字节那么打满链路需要的在途帧数N 2.5 MB / 1500 B ≈ 1747 帧也就是说窗口至少要 1747链路才不吃亏。而 GBN 要求窗口不超过 2^n − 1于是n 10 时2^10 − 1 1023不够n 11 时2^11 − 1 2047够但余量很小n 12 时2^12 − 1 4095比较稳实际工程里通常再留一倍余量直接上 12 位或 16 位。这也解释了为什么很多自定义协议里序号字段是 16 位——不是拍脑袋定的是算出来的。提示如果你的协议跑在低带宽长时延链路上比如某些远程采集场景很可能根本用不到大窗口序号 8 位就够。窗口开多大要看 BDP不要抄别人的参数。4. 后退 N 帧协议 GBN:一个人掉队,全队陪着重来终于到正题。GBN 是滑动窗口的第一个正式落地形态它的全部设计可以用一句话概括发送方可以连续发接收方只认顺序出错就从出错那帧开始全部重来。名字里的后退 N 帧说的就是这个回退动作。4.1 GBN 的四条核心规则我把规则拆成发送方和接收方两侧这样实现的时候不容易漏发送方维护窗口[base, base Ws - 1]next_seq指向下一个可发的序号只要next_seq base Ws就继续发不等确认。整个窗口只维护一个定时器绑在base上。这是 GBN 和 SR 最本质的区别之一。收到 ACK n 且 n ≥ base 时把窗口推进到base n 1。如果此时base next_seq说明全部已确认停定时器否则重启定时器。定时器超时从base开始把窗口内所有已发未确认的帧全部重发一遍。接收方只维护一个变量expected表示下一个期望的序号。收到序号等于expected的帧收下交付上层expected加一回 ACK累计确认确认号是expected - 1。收到序号不等于expected的帧直接丢弃但仍然回一个 ACK确认号还是expected - 1。第 3 条里丢弃但仍然回 ACK这个动作新手很容易漏掉。如果不回发送方只能等超时回了发送方能立刻知道有缺口虽然它也做不了什么GBN 只能整体重传但至少能靠重复 ACK 触发快速重传不用死等超时。这个机制后来被 TCP 拿去发扬光大了。4.2 为什么接收窗口只能是 1这个问题值得单独说因为它直接决定了 GBN 的性格。接收窗口为 1 意味着接收方没有缓冲区去存乱序帧。它一旦收到 5 号帧而自己期待 3 号就只能把 5 扔掉——它没有地方放也没法告诉发送方我手上有 5缺 3。ACK 的语义被限定为到 n 为止我全收到了一个不缺中间不允许有空洞。这个限制带来了两个后果。好消息是接收方实现极其简单一个变量搞定内存占用几乎为零这在嵌入式场景里很香。坏消息是只要有一帧出错后面所有已经成功到达的帧都白发了。窗口开得越大浪费越严重。4.3 窗口大小必须 ≤ 2^n − 1,这个结论怎么推出来这个约束是 GBN 最容易记错的地方考试爱考实践中也真会因为这个出 bug。我用反证法推一遍比死记硬背强。假设序号用 n 位序号空间是 2^n如果允许发送窗口 Ws 2^n会发生什么设 n 2序号空间 {0,1,2,3}窗口开到 4。发送方连续发出 0、1、2、3 四帧全部成功到达接收方接收方逐帧接收并交付expected依次推进收完 3 之后回到 0模 4。同时接收方回了四个 ACKACK0、ACK1、ACK2、ACK3。现在假设这四个 ACK 全部丢失。发送方超时从 base 0 开始重传 0、1、2、3。问题来了接收方此时expected 0它收到重传的 0 号帧判断这就是我要的 0 号于是收下并交付上层。但实际上这是旧帧的副本上层已经收过一次了。重复交付协议失效。如果窗口限制为 3 呢发送方发 0、1、2全到ACK 全丢。接收方收完后expected 3。发送方超时重传 0接收方一看 0 ≠ 3直接丢弃正确。歧义消失。所以约束成立GBN 的发送窗口必须满足 Ws ≤ 2^n − 1。少一个不是浪费是为了留出安全距离让接收方能区分新帧和回绕后的旧帧副本。注意这个 bug 极其阴险。小流量测试时窗口根本填不满永远跑不到回绕那一步功能看起来完全正常一上压力测试窗口被填满序号回绕重复交付就出来了。我被这个坑过一次排查了两天。写完协议一定要专门设计一个ACK 全丢的用例。4.4 一次丢帧之后的完整时序光讲规则不如走一遍。假设 n 3序号 0~7窗口 4发送 0~4 共 5 帧时刻发送方动作接收方状态说明t0发 0,1,2,3expected0窗口填满,继续等t1收到 ACK0expected1base 推进到 1,发 4t2收到 ACK1expected2base 推进到 2t32 号帧在链路丢失expected2接收方干等t43 号帧到达expected23≠2,丢弃,回 ACK1t54 号帧到达expected24≠2,丢弃,回 ACK1t6base 定时器超时expected2重发 2,3,4t72 号帧重传到expected3收下交付,回 ACK2t83 号帧重传到expected4收下交付,回 ACK3t94 号帧重传到expected5收下交付,回 ACK4看 t4 和 t5 就知道了3 和 4 明明完好无损地到了却因为前面缺了 2 被白白丢掉。这就是后退 N 帧的代价。窗口 4 的情况下一个错误最多导致 3 帧的无效传输。4.5 效率账窗口越大,重传放大越狠先看无差错的情况。窗口内可以不间断发送所以在途数据量是 Ws × Td一个 RTT 内的有效传输占比U min(1, Ws × Td / (Td RTT))沿用前面的数字Td 0.12 msRTT 4 msWs 1U 0.12 / 4.12 ≈ 2.9%Ws 8U 0.96 / 4.12 ≈ 23.3%Ws 32U 3.84 / 4.12 ≈ 93.2%Ws 40U 4.8 / 4.12 1取 100%窗口开到 40 就打满了再大也没用在无差错前提下。这个数字和前面 BDP 算出来的 1747 差距很大是因为这里的链路带宽只有 100 Mbps 而不是 1 GbpsTd 相对大得多。再看有差错的情况。设单帧丢失概率为 pGBN 的近似效率模型是U ≈ (1 − p) / (1 (Ws − 1) × p)代几个数窗口 Wsp 0.001p 0.01p 0.0580.9920.9320.746320.9690.7560.4131280.8880.4430.137这张表信息量很大。低误码率下窗口越大越好高误码率下窗口越大越糟。当 p 0.05、窗口 128 的时候效率只剩 13.7%还不如老老实实开个 8。这个反直觉的结论解释了为什么在无线链路上单纯的 GBN 很少直接用。无线丢包率高退避重传的代价太大所以工程上普遍用选择确认的变体只补真正丢了的那几帧。4.6 GBN 和选择重传的分水岭对比项GBNSR接收方缓存不需要需要 Wr 个帧空间接收窗口1 1,一般等于 WsACK 语义累计,到 n 全收到逐帧,精确到具体帧出错重传从出错帧起全部重发只重传出错帧窗口约束Ws ≤ 2^n − 1Ws Wr ≤ 2^n实现复杂度低中适用场景低误码、低时延高误码、长时延实际系统里最典型的混合体是 TCP 的 SACK 扩展基础还是累计确认GBN 血统但通过可选的 SACK 块告诉发送方我手里攥着哪些乱序段让发送方可以只补缺口。本质上是在 GBN 的骨架上加了 SR 的肉既省内存又省带宽。5. 动手:写一个能跑起来的 GBN 模拟器理论讲完接下来是能验证的部分。我一直觉得协议这东西必须写一遍才算懂不写的话窗口边界、序号回绕、定时器重启这几个地方永远只停留在大概知道。5.1 设计思路事件驱动 逻辑时钟不用真实 socket太麻烦也不容易控制丢包。用事件驱动模拟更干净维护一个按时间排序的事件队列事件有两类——数据帧到达接收方、ACK 到达发送方。时间用一个逻辑时钟推进谁先到期谁先处理。发送方状态只有五个变量base窗口左沿、next_seq下一个可发序号、timer定时器到期时刻、rx_expected接收方期望序号模拟里放一起方便、delivered已交付数据。这种极简状态设计正是 GBN 的优势所在。5.2 核心代码import heapq, random random.seed(7) RTT_PROP 1.0 # 单程传播时延 TIMEOUT 3.0 # 超时时间 LOSS_DATA 0.15 # 数据帧丢失概率 LOSS_ACK 0.10 # ACK 丢失概率 N_BITS 3 WINDOW (1 N_BITS) - 1 # 必须 2^n - 1 TOTAL 12 events [] _seq 0 def push(t, kind, payload): global _seq _seq 1 heapq.heappush(events, (t, _seq, kind, payload)) # 发送方状态 base, next_seq, timer 0, 0, None tx_count 0 # 含重传的总发送帧数 # 接收方状态 expected 0 delivered [] def try_send(now): 只要窗口有空位就继续发这正是 GBN 与停止等待的分水岭 global next_seq, timer, tx_count while next_seq base WINDOW and next_seq TOTAL: if timer is None: timer now TIMEOUT # 整个窗口只有一个定时器绑在 base 上 if random.random() LOSS_DATA: push(now RTT_PROP, DATA, next_seq) tx_count 1 next_seq 1 def on_ack(k, now): 累计确认ACK k 表示 k 及之前全部收到 global base, timer if k base: base k 1 if base next_seq: timer None # 窗口空了停表 else: timer now TIMEOUT # 还有在途帧重启 try_send(now) def on_data(seq, now): 接收窗口恒为 1乱序直接丢但仍回重复 ACK global expected if seq expected: delivered.append(seq) expected (expected 1) % (1 N_BITS) ack_no seq else: ack_no (expected - 1) % (1 N_BITS) if random.random() LOSS_ACK: push(now RTT_PROP, ACK, ack_no) now 0.0 try_send(now) while events or base TOTAL: if not events: now timer # 队列空了只能等超时 for s in range(base, next_seq): tx_count 1 if random.random() LOSS_DATA: push(now RTT_PROP, DATA, s) timer now TIMEOUT continue now, _, kind, payload heapq.heappop(events) if timer is not None and now timer: for s in range(base, next_seq): # 超时从 base 起全部重发 tx_count 1 if random.random() LOSS_DATA: push(now RTT_PROP, DATA, s) timer now TIMEOUT continue if kind DATA: on_data(payload, now) else: on_ack(payload, now) print(交付顺序:, delivered) print(总发送帧数:, tx_count, 有效数据帧:, TOTAL)5.3 日志怎么读实验怎么做跑一遍大约会看到十几到二十几的发送帧数远大于 12多出来的全是重传。改几个参数能看出很明显的规律参数调整观察到的现象说明什么LOSS_DATA 设为 0发送帧数恰好等于 12无差错时 GBN 零浪费LOSS_DATA 调到 0.3发送帧数暴涨,交付变慢重传放大效应WINDOW 改成 8某些情况下出现重复交付违反 2^n − 1 约束的直接后果TIMEOUT 改成 0.5重传急剧增加定时器过短导致误判超时第二行和第三行是我特意设计的陷阱建议你自己跑出来看一眼。窗口改成 8 那个正是 4.3 节推导的场景用代码复现比看推导印象深得多。提示这个模拟器里timer只绑在base上如果改成每帧一个定时器行为立刻变成近似 SR——哪帧超时补哪帧重传数量会明显下降。这是我做对比实验时无意中发现的改一行代码就能直观感受到两个协议的分野非常值得试一下。6. 排查实录:GBN 在真实系统里会咬人的地方理论、公式、代码都过了最后讲几个我在实际问题里遇到过或者见别人踩过的坑。这些问题在网上搜不到标准答案都是现场攒出来的。6.1 问题速查表现象最可能的原因排查方向处理办法重传频繁但链路不丢包定时器过短抓包看 RTT 分布按 RTT 均值 × 2 到 4 倍设置大流量下出现重复数据窗口等于 2^n,序号回绕检查窗口配置窗口降到 2^n − 1 以下吞吐一直上不去,重传不多窗口小于 BDP算 BDP 对比窗口加大窗口或加大序号位宽某一帧永远收不到接收方 expected 卡死看是否持续回同一 ACK补触发超时机制突发丢包后长时间恢复不了全窗口重传撞车看重传是否集中加随机退避或改 SR结果时好时坏,压力测试才复现窗口边界越界检查数组下标严格按[base, baseWs)维护6.2 几条用血换来的经验第一条累计确认会让重传次数看起来很吓人但你得先分清是不是真丢了。抓包时经常看到同一个序号被重发五六次新手第一反应是链路质量差其实可能只是 ACK 在路上堵了一会儿触发了一次超时然后整个窗口跟着重传正好在时间上重叠了。判断方法很简单看重传之前有没有对应的重复 ACK有重复 ACK 大概率是缺口没有就是纯超时。第二条窗口大小这个参数宁可小一点不要顶着上限来。我见过一个实现把窗口设成刚好 2^n − 1逻辑上正确但任何一处多发了一帧的越界 bug 都会直接踩到约束边上变成偶发的重复交付。留一半余量出问题时的表现会温和很多也更容易定位。第三条GBN 的正确性极度依赖接收方丢掉乱序帧也回 ACK这个动作。我在一个嵌入式实现里见过为了省事直接静默丢帧的版本功能上能跑但每次丢包都要等一个完整超时周期吞吐直接掉一半。加上那一行回 ACK 的代码之后性能立刻回来了。这行代码看着没用实际上是整个协议性能的关键。第四条真实链路很少纯用 GBN。无线环境误码率高纯 GBN 的重传放大太亏有线环境误码率低用 GBN 是最划算的因为省内存省 CPU。选型的时候先估算误码率再看内存预算两个数一摆答案基本就出来了。别被先进协议四个字带跑合适的才是好的。第五条调试协议一定要有可控的丢包注入能力。靠真实网络丢包来复现问题效率低到令人绝望因为你要等它自然发生。在代码里加一个开关按序号精确丢弃指定的帧再配合固定超时能在几分钟内把各种边界场景跑一遍。这个能力我现在的习惯是写进协议的第一版代码里不写到测试阶段再补。我个人在实际做私有协议时的体会是GBN 最容易被低估的部分不是窗口计算而是那一个绑在 base 上的定时器。很多人为了看起来更高效改成每帧一个定时器结果协议悄悄变成了残缺版 SR窗口约束、重传逻辑、ACK 语义全都要重新推一遍bug 就是从这种半改不改里钻出来的。想清楚你要的是哪种语义然后整套逻辑一起改别只改一半这比任何优化都重要。
