简介北京邮电大学计网实验中的滑动窗口协议模拟项目是一份以C语言实现的课程设计/期末大作业资源适合计算机网络专业学生完成数据链路层实验或复习滑动窗口机制时参考。压缩包共18个文件包含8个C源程序、4个头文件以及Visual Studio工程配置、.gitignore、说明文档和实验截图等整体仅71KB小巧易用C源文件覆盖协议主体实现头文件定义接口工程文件可方便直接打开调试。目前已有173人学习使用源码可在本地编译后直接运行据作者说明评审分数达95分以上内容经助教审定难度适中具有较好的参考价值。配套文档包含README说明与实验效果图结合selective、gobackn等协议实现可帮助理解选择重传、回退N帧等数据链路层核心机制适合作为课程报告写作或代码复现的对照样例。1. 从北邮计网实验到滑动窗口协议值得跑通的第一个可靠传输代码很多学生把“计网实验”当成拼报告的三天苦役结果在滑动窗口协议上翻车代码跑起来后屏幕不断刷 timeout 和乱序交付最后只能交一份“算法正确但代码放不下”的说明。这个实验的任务落在数据链路层核心是让你亲手实现发送窗口、接收窗口、超时重传与确认机制源码加文档说明就是为这份理解服务的。它解决的是“课本上两三页的滑动窗口描述落到 C 语言状态机里到底是什么样”的问题适合正在赶实验、准备答辩的本科生也适合想自己动手看 TCP 可靠传输底层原理的自学者。2. 滑动窗口协议的三条实现路线停等、GBN 与 SR 的选型依据数据链路层的基本功能包括封装成帧、透明传输和差错检测但真正让链路在丢包环境下还能可靠交付的是编号、确认与重传的组合也就是滑动窗口协议。这一章先把三条实现路线讲清楚——停等协议、后退 N 帧GBN、选择重传SR。你手上这个“源码文档说明”的压缩包不管代码怎么组织核心状态机一定落在三者之一选型选对了后面所有代码和文档都好写。2.1 帧格式与状态变量发送端和接收端要记住什么滑动窗口协议里发送端必须记住三个东西窗口基序号base、下一个待发送序号nextseq、窗口大小N。接收端只需要记住一个东西期望收到的下一个序号expectedseq。这两个端点之间通过帧交换信息所以帧里至少要带帧类型、序号和数据三块内容典型帧字段如下。字段示例含义type帧类型DATA、ACK、NAKseq数据帧自身的序号ack确认号表示“该序号及之前的帧已收到”payload上层交付的数据checksum差错检测码实验中常简化为随机误码模拟接收端为什么只记一个expectedseq因为 GBN 接收窗口大小为 1它只接受恰好等于期望序号的帧。凡是序号不对的帧一律视为乱序帧丢弃同时回一个重复 ACK 提醒发送端。这个“丢弃 重复 ACK”的行为是整个 GBN 协议最容易写错的地方后面避坑章节会专门展开。2.2 三种协议在代码上的差异窗口、确认与重传策略三条实现路线的差别集中在三个维度发送窗口多大、接收端要不要缓存乱序帧、超时后重传哪些帧。对比表如下。维度停等GBN后退 N 帧SR选择重传发送窗口1NN 1NN 1接收窗口11N乱序帧处理丢弃丢弃缓存确认方式逐帧 ACK累计 ACK逐帧 ACK超时重传范围当前帧窗口内全部帧仅超时的那一帧序号空间约束2 bit 足够N ≤ 2^n − 1N ≤ 2^(n−1)停等协议是窗口大小为 1 的 GBN 特例代码只需要一个seq一个ack循环但信道利用率太低实验报告里能写的数据量有限。GBN 是大多数实验包的主选实现接收端不需要缓存状态简单又能明显观察到“一个帧丢了后续所有帧跟着重传”的窗口效应。SR 最接近 TCP 的可靠传输思路但要维护每个帧的独立计时器和接收缓存代码量和调试难度都会上一个台阶。2.3 我为什么推荐先做 GBN复杂度与实验报告的平衡北邮这类计网实验的常见要求是“至少实现一种滑动窗口协议并模拟帧丢失场景”。从零开始的话我一般会建议先写 GBN原因很实际GBN 能把顺序交付、累计确认、超时重传、窗口滑动四个知识点全部覆盖代码量控制在两百行以内文档说明也好配图——画一张“每个序号随时间变化的发送/确认时序图”就够了。SR 在报告里只能把缓存管理多写一大段答辩时反而容易被追问“窗口大小和序号空间的关系为什么是 N ≤ 2^(n−1)”。如果你时间充裕更划算的做法是花 2~3 天把 GBN 完整跑通并记录测试数据再留半天按第 6 章的方法改成 SR 做对比。这样文档里既有“基础实现”又有“进阶对比”实验报告比只交一个协议的同学厚实得多。3. 拆解“源码文档说明”包从目录结构到滑动窗口状态机的调用链拿到压缩包先别急着解压双击 main.c。我一般会先看文档说明的第一节实验要求、交付物、评分点。这类计网实验包的常见组织方式是“源码目录 一份说明文档”源码管运行文档管设计思路和测试截图两者缺一不可。3.1 文件组织与每个文件在实验中的角色一个典型的实验包会按下面这种结构组织每个文件承担一条明确的职责链。路径在实验中的角色README.md 或 实验说明.docx运行方法、参数含义、测试步骤src/main.c命令行参数解析启动发送端与接收端src/gbn.cGBN 发送端核心窗口维护、超时重传src/rcv.c接收端逻辑按序交付、丢弃乱序帧、生成 ACKsrc/channel.c模拟物理信道按丢包率随机丢弃帧include/config.h集中管理窗口大小、序号位数、丢包率等参数拿到包后先读说明文档再看 main.c 里参数解析逻辑最后才进 gbn.c 和 rcv.c。很多同学跳着看代码搞不清哪个函数是发送端调用的、哪个是模拟物理层调用的最后改参数时连入口都找不到。记住一条主线main.c 创建发送端和接收端两个角色发送端调 gbn.c 的接口发帧接收端处理到帧后生成 ACK 返回channel.c 夹在中间按概率丢帧。3.2 发送端核心代码窗口管理与超时重传的 C 语言实现下面是裁剪出逻辑主线的 GBN 发送端代码省略了make_frame、deliver_to_physical等模拟辅助函数。它体现的是发送端状态机的核心窗口是否已满、收到 ACK 后 base 怎么推进、超时后重传哪些帧。/* gbn_sender.c - Go-Back-N 发送端核心逻辑骨架 */ #define WINDOW_SIZE 4 /* 发送窗口大小 */ #define SEQ_MOD 8 /* 序号空间 0~7对应 3 bit 序号 */ #define TIMEOUT_TICKS 5 /* 超时计数阈值单位由模拟时钟决定 */ struct gbn_sender { int base; /* 窗口基序号即最早未确认帧 */ int nextseq; /* 下一个要发送的帧序号 */ int timer; /* GBN 只需要一个窗口定时器 */ }; /* 判断 seq 是否落在 [base, baseWINDOW_SIZE-1] 的窗口内环形计数 */ static int in_window(int seq, int base) { int diff (seq - base SEQ_MOD) % SEQ_MOD; return diff 0 diff WINDOW_SIZE; } void gbn_send_frame(struct gbn_sender *s, uint8_t *payload, int len) { if (!in_window(s-nextseq, s-base)) { /* 窗口已满暂停发送等待 ACK 推进 base */ printf([sender] window full, base%d nextseq%d\n, s-base, s-nextseq); return; } struct frame f make_frame(s-nextseq, payload, len); deliver_to_physical(f); /* 把帧交给模拟信道 */ printf([sender] send frame seq%d\n, s-nextseq); if (s-nextseq s-base) { s-timer TIMEOUT_TICKS; /* 窗口内第一帧启动定时器 */ } s-nextseq (s-nextseq 1) % SEQ_MOD; } /* 收到 ACK 时采用累计确认ACKn 表示序号 n 及之前的帧都已收到 */ void gbn_on_ack(struct gbn_sender *s, int acknum) { int diff (acknum - s-base SEQ_MOD) % SEQ_MOD; if (diff 0 || diff WINDOW_SIZE) { /* 重复 ACK 或无效 ACK忽略即可 */ return; } s-base (acknum 1) % SEQ_MOD; printf([sender] recv ack%d, base moves to %d\n, acknum, s-base); if (s-base ! s-nextseq) { s-timer TIMEOUT_TICKS; /* 窗口内仍有未确认帧重启定时器 */ } } /* 超时后重传窗口内所有帧[base, nextseq) 范围 */ void gbn_on_timeout(struct gbn_sender *s) { int seq s-base; printf([sender] timeout, retransmit base%d nextseq%d\n, s-base, s-nextseq); while (seq ! s-nextseq) { struct frame f make_frame(seq, frame_payload_of(seq), frame_len_of(seq)); deliver_to_physical(f); printf([sender] retransmit frame seq%d\n, seq); seq (seq 1) % SEQ_MOD; } s-timer TIMEOUT_TICKS; }逻辑上要抓住三点。第一in_window用环形差值判断窗口边界不能用普通的大于小于比较否则序号从 7 回到 0 时会立刻判错。第二收到 ACK 后base直接跳到acknum 1这就是累计确认和停等协议最大的区别如果这里写成base窗口每次只滑一格协议会退化成效率极低的逐帧确认。第三超时重传的循环条件是while (seq ! nextseq)这意味着超时瞬间已经把窗口内所有帧重新交给了物理信道定时器只保留一个。参数上最值得调整的是WINDOW_SIZE和SEQ_MOD的关系。GBN 要求WINDOW_SIZE SEQ_MOD - 1。举例说序号空间只有 0~3 时窗口最多只能开 3。如果窗口也开到 4发送方连续发 0~3四帧全丢后重传 0~3接收端期望的是 0会把重传的旧帧当成新周期的新帧造成重复交付。这个约束写进文档说明答辩时是实打实的得分点。3.3 接收端核心代码按序交付与丢弃乱序帧的分支判断GBN 接收端只有两个分支代码比发送端短得多。/* rcv.c - Go-Back-N 接收端核心逻辑骨架 */ void gbn_receiver(struct receiver *r, struct frame *f) { if (f-seq r-expectedseq) { /* 正好是期望的那一帧交付给上层并滑动接收窗口 */ deliver_to_upper(f-payload); r-expectedseq (r-expectedseq 1) % SEQ_MOD; send_ack(r, f-seq); printf([rcv] deliver seq%d, expected now %d\n, f-seq, r-expectedseq); } else { /* 乱序帧丢弃同时回传期望序号前一个的 ACK */ printf([rcv] drop seq%d, expected %d\n, f-seq, r-expectedseq); send_ack(r, (r-expectedseq - 1 SEQ_MOD) % SEQ_MOD); } }这里最容易忽略的是乱序帧分支里的重复 ACK。如果不回这个 ACK发送端可能一直等到超时才意识到帧丢了吞吐量会明显恶化。重复 ACK 的作用是让发送端尽快知道“期望序号之前的帧已经全部到达就差窗口里那一帧”但请注意GBN 收到重复 ACK 后只应重置窗口定时器不应立刻重传否则会和超时重传打架这个坑第 5 章再细说。3.4 参数配置区改哪几个宏就能切换协议行为实验包的参数一般会集中在一个头文件里方便文档说明里写“测试条件”也方便你快速做多组对比实验。/* config.h - 实验参数配置区 */ #define WINDOW_SIZE 4 /* GBN 窗口大小必须小于序号空间 */ #define SEQ_BITS 3 /* 序号位数序号空间为 2^SEQ_BITS 8 */ #define LOSS_RATE 0.1 /* 模拟信道丢包率0.0~1.0 */ #define TOTAL_FRAMES 1000 /* 本次实验计划发送的帧总数 */把WINDOW_SIZE改成 1代码就退化成停等协议把LOSS_RATE从 0.1 调到 0.3重传次数会明显上升把SEQ_BITS改成 2序号空间缩小到 4对应窗口必须同步调小。这些参数组合起来就是文档说明里“测试方案”一节的素材建议每次改参数只动一个变量记录一组输出不要同时改两个。4. 在本地重现实验结果编译命令、参数矩阵与正确性验证代码读完了接下来要做的是在自己机器上把实验跑起来。这个环节的核心不是“让程序通过编译”而是“让程序告诉你它是对的”。我见过太多人拿一份能跑通的源码交差但问他为什么最终交付帧数和发送帧数相等时答不上来。4.1 最小编译与运行命令gcc 一行出结果这类实验用标准 C 写的话编译命令非常简单。gcc -stdc11 -Wall -o datalink main.c gbn.c rcv.c channel.c ./datalink -w 4 -m 8 -l 0.1 -t 1000命令行参数建议在main.c里用getopt解析-w指定窗口大小-m指定序号空间-l指定丢包率-t指定本次实验要发送的总帧数。这样比每次改头文件重新编译要高效得多也方便在第 4.2 节里跑参数矩阵。如果编译时出现assignment discards ‘const’ qualifier之类的警告多半是deliver_to_physical的参数声明少了const把函数签名统一成void deliver_to_physical(const struct frame *f)即可。跑通后窗口压到 4、丢包率 0.1 时的输出大概长这样[sender] send frame seq0 [sender] send frame seq1 [sender] send frame seq2 [sender] send frame seq3 [rcv] deliver seq0 [rcv] deliver seq1 [sender] recv ack1, base moves to 2 [rcv] drop seq2, expected 3 [rcv] deliver seq3 [sender] recv ack3, base moves to 4 [report] delivered1000 retrans37 loss0.1注意第 4 行和第 5 行之间没有deliver seq2说明 2 号帧在信道里丢了接收端跳到了 3之后 2 号帧要靠超时重传补上。最后一行report里的三项指标是实验报告的关键数据交付帧数、重传次数、丢包率。4.2 推荐的三组参数组合窗口、序号位数、丢包率怎么配合新手最容易犯的错误是一上来就拿窗口 4、序号空间 8、丢包率 0.5 跑数据量一大根本看不出行为对错。我一般会按下面三组参数逐步推进。组号窗口序号空间丢包率观察目标A180.0验证链路和协议基本通路是否正常B480.1GBN 标准行为超时重传、累计确认、窗口滑动C480.3高丢包下重传次数膨胀观察窗口效应A 组是“最小可用”验证窗口为 1 时协议退化为停等任何序号回绕问题都会立刻暴露。B 组是文档说明里最常展示的配置丢包率不高不低重传行为明显但不会刷屏。C 组用来证明你的协议在恶劣信道下仍然不会丢帧但重传次数会显著上升如果 C 组跑出来的重传次数和 A 组差不多说明 channel.c 的丢帧逻辑根本没生效这是个常见翻车点。三组跑完后把delivered、retrans、loss三个数字整理成表格放进文档说明报告的核心结论就支撑起来了。4.3 验证协议没写错的三个观察点时序、丢包计数、吞吐量程序能跑和协议正确是两回事。我判断一个滑动窗口实现是否正确的标准是下面三条缺一不可。第一最终交付帧数必须严格等于TOTAL_FRAMES。多一帧说明重复交付少一帧说明帧永久丢失两者都是致命的。第二交付序号必须单调递增且不重不漏可以通过一条命令检查。./datalink -w 4 -m 8 -l 0.1 -t 1000 | grep deliver seq \ | awk -Fseq {print $2} | sort -n | uniq | wc -l如果输出是1000说明接收端交付的序号形成一个完整的 0~999 序列如果小于 1000说明有丢帧或覆盖大于 1000说明有重复交付。第三重传次数应当随丢包率单调上升。把这三条检查写进文档说明的“验证方法”一节比贴十行代码更有说服力。提示跑高丢包率时如果输出里出现大量window full且重传次数异常低先把窗口调到 1、丢包率调到 0 重跑一遍。很多所谓“玄学死锁”其实只是窗口基序号推进条件写错在正常丢包率下被并发输出掩盖了。5. 滑动窗口实验的 5 个高频坑现象、原因与解决手段这一章是我的血泪经验。滑动窗口协议的 bug 有个特点单帧发送时永远测不出来一上并发、一上丢包就翻车。下面五条按“现象 → 原因 → 解决”的方式写基本覆盖了实验中九成以上的故障。5.1 窗口满了永远不滑动先查 ACK 推进逻辑现象程序运行几秒后输出卡在[sender] send frame seq4之后全是window full什么都不动了。原因窗口大小为 4发送了 0~3 号帧后nextseq变 4窗口已满。正常情况下收到 ACK 后base推进窗口才能继续发。卡死说明 ACK 处理函数没有正确推进base常见写法是if (ack base) base但 GBN 的 ACK 是累计确认ACK2 表示 0~2 全收到base应该直接跳 3。解决在gbn_on_ack入口打印每一次 ACK 的序号和当前base确认收到的 ACK 是否落在[base, baseWINDOW_SIZE-1]区间内。正确做法是base (acknum 1) % SEQ_MOD且只有当acknum确实在窗口内时才允许更新。5.2 序号回绕被当成新帧模运算没做对现象丢包率调到 0.2 后接收端交付日志里出现连续重复的序号比如先交付了seq5紧接着又交付一个seq5。原因序号空间 8、窗口 4 时帧序号会从 7 回绕到 0。如果接收端用if (f-seq r-expectedseq)判断帧是否有序回绕后的 0 会小于当前的 4被误判为“旧帧”或“乱序帧”逻辑全乱。解决所有序号比较必须按环形差值做正确写法是int diff (f-seq - r-expectedseq SEQ_MOD) % SEQ_MOD;再判断diff是否等于 0。发送端的in_window和接收端的期望判断都要用这个模式只改一处必然出问题。5.3 快速重传和超时重传打架吞吐量掉一半现象丢包率 0.1 时重传次数比理论值几乎高一倍吞吐量曲线也出现异常断崖。原因代码里既写了“收到重复 ACK 立即重发”又有超时重传逻辑。一个帧丢失后接收端回重复 ACK发送端重传一次等真正的超时到达窗口内又重传一次。同一个丢帧被重传两遍浪费了带宽。解决GBN 协议里重传的唯一触发点是超时。收到重复 ACK 时只做一件事——重置窗口定时器不要调用retransmit。如果你想在报告里讨论快速重传就把这部分单独放不要和 GBN 混在一起。5.4 确认号多滑了一位累计 ACK 与逐帧确认混用现象接收端交付序号完全正常但发送端窗口滑得比预期快跑到最后发送端认为自己发完了接收端还在等一个永远不来的帧。原因确认号语义不一致。接收端发的是“最后正确收到的那一帧序号”发送端却按“该序号之前全部确认”来推进两者语义错位窗口就会多滑一格。比如接收端确认 5发送端把base推到 6但真正被确认的只有 5 号帧6 号帧实际丢了从此双方等待的序号永远错开。解决文档说明里明确写死一种语义代码里全局统一。用累计 ACK 就把base设为acknum 1用逐帧 ACK 就把base设为acknum不要一套代码两种理解。建议优先选累计 ACK更贴近 GBN 的标准定义。5.5 文档与源码编号不一致答辩被追问的经典现场现象文档里画的重传范围是[base, nextseq)代码里循环却是while (seq nextseq)多发了nextseq这一帧。答辩时老师照着文档问你“窗口还有几帧”你对着代码答不上来。原因写文档时用的是伪代码编号和 C 语言实际实现错位。多数人习惯最后一天统一补文档代码和说明自然对不上。解决写文档时每个算法步骤后面标注对应源码文件名和函数名例如“超时重传范围见 gbn.c 的gbn_on_timeout循环条件为seq ! nextseq”。改代码后同步改文档对应段落别把文档留到最后补。这份对应表本身也是文档说明里结构清晰度的加分项。6. 把实验从 GBN 扩成 SR三个函数带你做出对比实验如果时间允许把 GBN 改成 SR 是投入产出比最高的进阶操作。改动量不大却能让你在文档说明里多一张“协议对比表”和一组对比数据答辩时明显更从容。6.1 只改三个点的 SR 改造方案GBN 和 SR 的核心差别在三处正好对应三个函数。行为GBNSR超时重传范围base 到 nextseq 全部仅超时的那个帧乱序帧处理丢弃缓存并回 ACK确认方式累计 ACK逐帧 ACK/* SR 超时只重传超时的单帧并重启该帧的独立计时器 */ void sr_on_timeout(struct sr_sender *s, int seq) { retransmit_one(seq); start_timer(seq); } /* SR ACK 处理标记该帧已确认只有当 base 连续时才推进窗口 */ void sr_on_ack(struct sr_sender *s, int acknum) { mark_acked(acknum); slide_if_possible(); }GBN 的定时器只有一个SR 需要在每个未确认帧上各挂一个GBN 的base随累计 ACK 跳变SR 要靠一张布尔表记录哪些帧已确认窗口只能连续推进。这三个差异写进文档说明对比表一放实验报告的深度就出来了。6.2 用同一组丢包率跑完对比后报告里放那张曲线改造完 SR 后用第 4.2 节的同一组丢包率把两个协议各跑一遍记录重传次数和交付帧数。丢包率从 0.05、0.15 到 0.3GBN 的重传次数会明显快于 SR因为一个丢帧会拖累整个窗口重传而 SR 只补那一帧。这个对比不需要画多精致的图一张简单柱状图或折线图放进文档说明就能直接支撑“SR 在高丢包环境下的信道利用率更高”的结论。我当年做这个实验时先交了一份纯 GBN答辩前两天改成 SR靠这张对比曲线少挨了很多追问。先跑通一种协议再谈协议之间的优劣永远是计网实验报告里最划算的投入。希望帮到你。本文还有配套的精品资源点击获取