简介这份计算机网络原理第四章试题汇总PPT聚焦数据链路层核心考点内容涵盖HDLC高级数据链路控制协议、PPP点对点协议、CRC循环冗余校验、流量控制与差错控制编码等关键知识点并整理了2008年至2009年多套已考试题适合备考计算机网络原理课程的本科学生及自考考生复习使用。资源包内含1个PPT文件体积约1.32MB页面内容精炼将数据链路层知识点与历年真题解析相结合题目类型覆盖单选、简答与计算题。每道试题均附有参考答案与详细计算过程如CRC校验生成多项式应用、停等协议信道利用率计算、HDLC帧格式画法及Go-back-N协议窗口判断等帮助读者快速掌握高频考点与解题思路。目前已有37人学习该资源可作为课程期末复习、自学备考的重要参考资料。1. 数据链路层真题为什么这份“试题汇总”比教材更值得刷备考计算机网络原理最怕的不是题难而是不知道考点到底长什么样。教材把 HDLC、PPP、CRC 讲得再细考试只考几个固定套路帧类型标志位是多少、监控帧长度是几位、CRC 生成多项式怎么除、停等协议的信道利用率怎么算。这份《计算机网络原理第四章试题汇总》最大的价值就是把 2008 年到 2013 年数据链路层的已考试题按年份整理好了单选、填空、简答、计算题全都有而且多数题后面直接附了答案和解题过程。它适合两类人一类是考前一两周需要刷题找手感的考生另一类是正在备课、想从真题里反推重点的老师和助教。我拆完这份资源后的结论是数据链路层拿分的关键不在背书而在把滑动窗口时序图画顺手、把 CRC 的模 2 除法练成本能。2. HDLC 与 PPP协议题的核心考点与记忆锚点2.1 从真题看 HDLC 的必考属性翻完整份试题可以明显看出HDLC 几乎是每年必考而且考法非常固定。总结下来集中在三个点上协议类型、帧类型、帧格式。协议类型这道题从 2008 年考到 2011 年变体几乎一样高级数据链路控制协议 HDLC 是一种什么协议答案是面向比特的同步协议。这里有一个容易混的点PPP 是面向字符的BSC 也是面向字符的同步协议而 HDLC 是面向比特的。记法很简单——HDLC 用比特填充法保证透明传输操作单位是比特流所以它必然面向比特。帧类型这个考点更细。HDLC 有三类帧信息帧I 帧、监控帧S 帧、无编号帧U 帧。真题反复考两个点监控帧的长度是多少、帧类型标识位的值是多少。监控帧长度答案是 48 位注意不是 16 位也不是 32 位。2009 年 7 月有一道题直接问 HDLC 的帧类型包括信息帧、监控帧和什么答案是无编号帧。2011 年 4 月问信息帧的帧类型标识位值答案是 02011 年 7 月问监控帧的帧类型标识位值答案是 10。这里有一个规律I 帧控制字段第一位是 0S 帧前两位是 10U 帧前两位是 11。把这三个值串起来记——0 开头是数据10 是控制11 是管理——基本就不会乱了。帧格式是简答题的高频考点。2008 年 7 月和 2011 年 4 月都考了 HDLC 帧格式要求画出帧结构并写出帧类型和类型标志。标准帧格式是标志字段8 位01111110 地址字段8 位 控制字段8 位 信息字段可变长 帧检验序列 FCS16 位或 32 位。标志字段固定是 01111110这个值必须背死因为后面做比特填充题也要用到它。2.2 比特填充HDLC 透明传输的解题套路2012 年 4 月有一道很有代表性的题若 HDLC 帧中数据段的内容为 0111110010则实际的数据是什么。这题考的是比特填充的反向操作。先理清规则HDLC 发送端在数据中每遇到连续 5 个 1 就插入一个 0避免数据中出现的 01111110 与标志字段混淆。接收端收到数据后每遇到连续 5 个 1 就删掉后面的 0还原原始数据。数据段 0111110010 的还原过程是从左往右扫描遇到 011111 这 5 个连续的 1后面跟着的 0 就是填充位删掉它。于是 0111110010 变成 011111010。我一般建议学生做题时把数据按位写开拿铅笔在 5 个连续 1 后面做个标记这样不容易漏删或多删。这里有个常见的翻车点如果 5 个 1 后面跟的是 1那这个 1 不能动它不是填充位。填充位只出现在连续 5 个 1 之后且必然是 0。考试时如果发现删掉 0 之后还能继续凑出 5 个连续 1就要继续检查后面有没有填充位。2.3 PPP 与链路管理选择题的送分点PPP 在真题里出现的频率比 HDLC 低但几乎每次出现都是送分题。2008 年 7 月问 PPP 协议是什么协议答案是面向字符的。2009 年 4 月问 PPP 提供的 3 类功能答案是成帧、链路控制和网络控制。这个知识点没什么计算量纯粹是记忆题。我的记法是PPP 先成帧把数据包装成帧再控制链路建立和释放连接最后控制网络配置网络层协议参数。2010 年 4 月有一道关于链路管理的填空题数据链路层连接的建立、维持和释放被称为什么答案是链路管理。这类题属于基本概念题在数据库、计算机网络教材里都有明确定义不需要额外分析。3. CRC 校验计算从生成多项式到模 2 除法的完整演练3.1 为什么 CRC 是拉分题数据链路层的计算题里CRC 的出镜率是最高的。2008 年到 2013 年几乎每年都有一道而且出题方式非常固定给出待发送数据、给出生成多项式求实际发送序列或者给出接收序列判断传输是否出错。这类题其实是送分题因为计算套路完全固定不像滑动窗口时序图那样需要画图分析。但很多学生在这里丢分原因只有一个——模 2 除法不熟练或者多项式转二进制时搞错位数。先说多项式转二进制的方法。生成多项式 X4X31展开是 1X4 1X3 0X2 0X1 1*X0对应二进制就是 11001。注意 X2 和 X1 的系数是 0不能省略。另外一个容易错的地方生成多项式的最高次数是 4意味着 CRC 校验码是 4 位待发送数据后面要补 4 个 0 再参与除法。3.2 手算 CRC2008 年真题完整过程2008 年 4 月真题设要发送的二进制数据为 10110011生成多项式为 X4X31求实际发送的二进制数字序列。生成多项式 X4X31 对应的二进制是 11001。数据 10110011 后面补 4 个 0得到 101100110000。然后用 11001 对 101100110000 做模 2 除法。模 2 除法的规则是每一位按异或运算处理1 异或 1 得 01 异或 0 得 10 异或 0 得 0。具体除法过程如下第一步10110 前 5 位对 11001 做异或得到 01111然后从被除数拉下一位 0变成 11110。 第二步11110 前 5 位对 11001 做异或得到 00111拉下一位 0变成 01110。 第三步01110 首位是 0商位为 0直接拉下一位 0变成 11100。 第四步11100 对 11001 异或得到 00101拉下一位 0变成 01010。 第五步01010 首位是 0商位为 0直接拉下一位 0变成 10100。 第六步10100 对 11001 异或得到 01101。余数是 1101。实际发送序列就是在原始数据后面接上余数10110011 1101。3.3 用 Python 快速验证 CRC 计算手算容易错尤其是位数多了以后很容易看花眼。我一般会建议学生写一个简单的 Python 脚本验证结果几秒钟就能出答案。def crc_divide(data, generator): # 将生成多项式转为二进制字符串 gen_len len(generator) # 被除数后补 len(generator)-1 个 0 dividend data 0 * (gen_len - 1) dividend list(dividend) for i in range(len(data)): if dividend[i] 1: for j in range(gen_len): # 模 2 减法等价于异或 dividend[i j] str(int(dividend[i j]) ^ int(generator[j])) # 取最后 gen_len-1 位作为余数 remainder .join(dividend[-(gen_len - 1):]) return remainder data 10110011 generator 11001 remainder crc_divide(data, generator) print(fCRC 校验码: {remainder}) print(f实际发送序列: {data remainder})这段代码的核心逻辑是模拟模 2 除法从被除数最高位开始遇到 1 就对生成多项式做异或遇到 0 就跳过。最后剩下的位数等于生成多项式位数减 1刚好是 CRC 校验码的位数。运行时要注意data 和 generator 都必须是字符串格式generator 的二进制表示不能省略中间的 0。代码里 generator11001 对应 X4X31如果生成多项式是 X4X2X11那就要写成 10111。3.4 接收端校验余数为 0 就没错2009 年 4 月有一道典型的接收端校验题已知发送方采用 CRC 校验生成多项式为 X4X31接收方收到的二进制序列为某串数据判断是否出错。做法是把接收序列直接除以生成多项式如果余数为 0 说明没有错误不为 0 说明出错了。这里需要注意一个易错点接收端不需要在数据后面补 0因为发送端发过来的序列已经包含了校验码。直接拿整个接收序列除以生成多项式即可。2008 年 7 月的答案是最后余数为 110不为零所以判断传输过程中出错。如果余数是 0000那就是接收正确。CRC 的检错能力这块2009 年 4 月考了一道概念题正确的 CRC 校验码检错能力描述是哪个。答案是 C可检测出所有奇数位错。这里要理解原理CRC 的检错能力取决于生成多项式的选取生成多项式对应的码多项式如果能被 X1 整除就能检测所有奇数位错误而三比特错误不一定能检测出来但奇数位错误是可以通过多项式设计保证检测的。4. 流量控制与滑动窗口停等协议、后退 N 帧与时序图题4.1 停等协议最基础也最容易漏细节的机制停等协议在真题中出现频率极高2009 年 4 月的简答题直接要求简述停等协议的实现过程。参考答案给了四个步骤核心是发送方每发送一帧就启动计时器收到确认帧就清零计时器并继续发送下一帧如果计时器超时没收到确认帧就重发。这里有一个隐藏的考点发送方每次只保留当前待确认帧也就是发送窗口1接收窗口1。协议选择题里Go-back-N 窗口规律是反复考的。2008 年 7 月问 Go-back-N 协议中发送窗口和接收窗口的关系答案是发送窗口大于 1、接收窗口等于 1。2010 年 7 月问选择重传协议中的窗口关系答案是发送窗口大于 1、接收窗口大于 1。这两个不要记混我的记忆方法是Go-back-N 接收方只能顺序接收所以接收窗口是 1选择重传允许乱序接收接收窗口可以大于 1。4.2 停等协议计算题信道利用率与帧长2009 年 4 月有一道利用率计算题数据传输速率 4Kbps信道传播时延 20ms采用停等协议帧控制信息和确认帧长忽略不计信道利用率为 50%求数据帧长度。停等协议的发送周期是发送时延 传播时延 确认帧传播时延其中确认帧传播时延等于数据帧传播时延所以一个周期是发送时延 2 倍传播时延。信道利用率是发送时延占总周期的比例即发送时延 /发送时延 2 倍传播时延 50%。代入传播时延 20ms 0.02s2 倍传播时延是 0.04s。利用率为 50%意味着发送时延 2 倍传播时延 0.04s。数据帧长度 速率 × 发送时延 4Kbps × 0.04s 0.16Kbit 160bit 20 字节。注意这道题参考答案里写的方式和上面不太一样它先算出 50% × 0.02 0.01s那个推导其实有瑕疵——它把传播时延和发送时延的关系搞混了。正确的思路应该是从利用率公式反推发送时延而不是拿信道利用率乘传播时延。考试时如果想稳妥建议直接用利用率公式推不要用参考答案的捷径。4.3 顺序接收管道协议卫星信道利用率2009 年 7 月的题比停等协议难一档卫星信道数据传输速率 1Mbps数据帧长 5625bit传播时延 270ms发送窗口尺寸 4求信道利用率。顺序接收管道协议的利用率公式是发送窗口尺寸 × 发送时延 /发送时延 2 倍传播时延。发送时延 5625bit / 1Mbps 5.625ms。2 倍传播时延 540ms。利用率 4 × 5.625 /5.625 540 22.5 / 545.625 ≈ 4.125%。这道题能看出滑动窗口的优势窗口越大利用率越高。但实际场景里卫星信道的传播时延太大窗口尺寸 4 远远不够把信道填满。如果考试遇到类似题可以把发送时延和 2 倍传播时延的数值先算清楚再套公式不要盲目背答案。4.4 滑动窗口时序图题使用 Python 模拟帧序号流转2010 年 7 月的最后一道大题是滑窗时序图题发送 3 个数据帧发送窗口 2接收窗口 1帧号配两位二进制数发送完 1 号帧后收到 0 号帧的确认帧画出发送窗口和接收窗口的变化过程。这类题是很多人的丢分重灾区。原因在于帧号位数与窗口大小的约束关系帧号配 2 位意味着帧号范围是 0 到 3 循环发送窗口 2最大发送未确认帧数是 2。发送完 1 号帧后收到 0 号帧确认说明发送窗口向前滑动一格从包含 0、1 变为包含 1、2接收窗口也从等待 0 变为等待 1。我习惯用 Python 模拟这个滑动过程这样不仅结果可验证还能把每一帧的状态看清楚。# 模拟滑动窗口变化过程 frame_seq [0, 1, 2, 3] # 帧号范围2 位二进制数0~3 循环 send_window_size 2 recv_window_size 1 # 初始状态发送窗口包含 0、1接收窗口等待 0 号帧 send_window [0, 1] recv_window [0] print(f初始状态发送窗口{send_window}接收窗口{recv_window}) # 发送 0 号、1 号帧 print(发送 0 号、1 号帧) # 收到 0 号帧的确认发送窗口滑动一格 send_window [1, 2] recv_window [1] print(f收到 0 号确认后发送窗口{send_window}接收窗口{recv_window}) # 继续发送 2 号帧 print(继续发送 2 号帧) # 收到 1 号帧的确认发送窗口再滑动一格 send_window [2, 3] recv_window [2] print(f收到 1 号确认后发送窗口{send_window}接收窗口{recv_window})这段代码把窗口滑动过程拆成了两步每收到一帧确认发送窗口的起始序号加 1接收窗口的期望序号也加 1。注意帧号只有 2 位所以序号是循环的3 号帧发完后下一个帧号回到 0。画时序图时我习惯先把帧号列出来再标出每个时刻的发送窗口和接收窗口内容这样阅卷老师能一眼看到你的思路。5. 避坑指南数据链路层真题里最常见的四个翻车点5.1 生成多项式与二进制代码的转换出错现象题目给出生成多项式 X4X31学生转成二进制时写成了 1101 或 11010。原因忽略了多项式展开式中系数为 0 的项或者把最高次数误认为二进制的位数。解决先把多项式按 X4、X3、X2、X1、X0 逐项展开系数是 1 的写 1系数是 0 的写 0。X4X31 1X4 1X3 0X2 0X1 1*X0 11001。另外验证一下最高次数和二进制位数最高次数 4 意味着二进制是 5 位如果写出来不是 5 位肯定错了。5.2 停等协议利用率计算时把传播时延当成往返时延现象计算信道利用率时只乘了单程传播时延结果比真实值高一倍。原因停等协议一个完整周期包含数据帧发送时延、数据帧传播时延、确认帧传播时延确认帧传播时延和数据帧传播时延相等所以要乘 2。解决做题时先画出时间轴把数据帧发送、数据帧传播、确认帧传播三段标出来再套利用率公式。这个习惯能避免大部分低级错误。5.3 HDLC 帧类型标识位记混现象I 帧的标识位记成 1S 帧记成 00导致选择题丢分。原因没有理解控制字段的结构。解决控制字段第 1 位为 0 表示 I 帧第 1、2 位为 10 表示 S 帧第 1、2 位为 11 表示 U 帧。再补充一个细节S 帧控制字段的第 3、4 位表示功能00 是接收就绪01 是拒绝10 是接收未就绪。2010 年 4 月那道题问的是不包括哪个组合答案是 11因为 11 是应答这个说法在 S 帧里不存在。5.4 滑动窗口时序图中帧号循环边界出错现象帧号配 2 位二进制数时发送完 3 号帧后不知道下一个帧号是 0直接把 4 写了上去。原因忽略了帧号位数对编号范围的限制。解决帧号占 n 位时编号范围是 0 到 2n-1。2 位帧号范围 0~33 位帧号范围 0~7。做题前先把帧号序列写出来标好循环点再画窗口变化。6. 把真题变成自己的答题模板一份可复用的考前速查单数据链路层的真题翻来覆去就那么几个模型与其考前背教材不如把真题里的固定套路提炼成模板。我自己做这份试题汇总时整理了一个速查单每次考前都过一遍正确率提升最明显的是简答题和计算题。HDLC 帧格式默写模板标志字段 01111110、地址字段 8 位、控制字段 8 位、信息字段可变、FCS 16 位或 32 位。凡是考帧格式的题先画这个结构再写类型标志基本不会扣分。帧类型标识位三行速记I 帧第一位 0S 帧前两位 10U 帧前两位 11。CRC 计算模板按四步走第一步多项式转二进制并确认位数第二步数据后面补 n 个 0n 是多项式最高次数第三步模 2 除法求余数第四步余数拼接在原始数据后。接收端校验就直接拿接收序列除多项式看余数是否为 0。2008 年 4 月的数据 10110011 配生成多项式 11001余数是 1101实际发送序列是 101100111101这个结果可以作为练习时的正确答案对照。停等协议和滑动窗口的公式也建议固定下来。停等协议信道利用率 发送时延 /发送时延 2 × 传播时延。顺序接收管道协议利用率 窗口尺寸 × 发送时延 /发送时延 2 × 传播时延。这两个公式是计算题的核心其他变量都是围绕它们展开的。答题时有一个小技巧选择题里凡是问 HDLC 是什么协议、PPP 是什么协议的答案几乎不用犹豫前者面向比特同步后者面向字符。凡是问窗口大小的先看协议类型停等是 1 和 1Go-back-N 是大于 1 和 1选择重传是大于 1 和大于 1。最后说一个我自己的习惯做完一套真题后我不是对完答案就丢而是把所有计算题重新用 Python 跑一遍。CRC 除法用脚本验证滑动窗口时序图用列表模拟停等协议利用率用公式算一遍。这样能把纸面上容易错的细节全部暴露出来。有一次我发现手算的 CRC 校验码是 1101脚本跑出来也是 1101才彻底放心。从那以后我每次考前都会强制走一遍这个流程——先做真题再脚本验证最后整理出错点。这套流程看起来费时间但比盲目刷十套题都管用希望帮到你。本文还有配套的精品资源点击获取