计算机网络协议题库解析:TCP拥塞控制与链路层重传机制深度对比
简介本资源为北京师范大学《计算机网络》课程期末考试样卷B卷面向高校计算机及相关专业本科生用于考前复习、知识点查漏与应试能力训练。试卷覆盖信道分配ALOHA/CSMA、纠错编码海明距离与纠错能力、数据链路层帧结构、传输层与链路层重传机制差异、CRC校验计算、ADSL技术原理、信道利用率建模、缓冲区容量设计、曼彻斯特编码特性、IP分片与重组规则、Nagle/Clark算法对比、奈奎斯特与香农定理应用、距离矢量路由缺陷等核心考点题型含单选、填空、判断三类共8页完整试题及标准作答逻辑提示。资源为1个769KB的docx文档内容排版规范含装订线、题号得分栏、阅卷签字区等真实试卷要素便于打印模拟与手写作答。目前已有119人学习下载是理解北师大计网教学重点与命题风格的优质参考材料。1. 这不是普通题库一份2011年北师大计网B卷为什么至今还被翻出来当“照妖镜”用如果你正在啃《计算机网络自顶向下方法》第七章的TCP拥塞控制却卡在慢启动阈值和ssthresh切换逻辑上如果你反复调试Wireshark抓包发现三次握手后RST频发但始终找不到是Nagle算法还是接收窗口通告的问题或者你刚写完一个基于UDP的可靠传输模拟器结果在Go-back-N序列号回绕边界上栽了跟头——那这份2011年北京师范大学《计算机网络》期末考试B卷大概率就是你缺的那块“现实校准板”。它不是考前突击资料而是一份被某高校网络协议实验课沿用十年的“压力测试模板”单选题第4题直击RTT抖动方差对重传定时器设计的根本性影响填空题第5题用16个序列号空间逼你画出滑动窗口的临界状态图问答题第2题那个ack15的时序陷阱至今仍是某实验室TCP状态机单元测试的必过用例。它不教你怎么背OSI七层而是用30分填空20分判断30分问答把RFC 793、RFC 1122里藏在字缝里的工程权衡全摊开给你看。适合已经跑通socket编程、能抓包分析SYN/ACK但总在“理论上该这样”和“实际上这样崩”之间反复横跳的进阶学习者。2. 题干即线索从单选题反向推导协议栈设计的真实约束2.1 单选题第4题RTT抖动方差为何是传输层与链路层重传机制的分水岭题干重现“可靠的传输层和链路层协议设计时都要考虑重传定时器的超时间隔大小问题。两者最大的区别在于 RTT 抖动的方差前者 后者 。这是由通信双方间的 性质决定的。”选项A、大小信道 B、小大信道 C、大小链路 D、小大链路这道题表面考记忆实则考你是否亲手调过TCP的RTORetransmission Timeout计算逻辑。我们来拆解传输层如TCP端到端通信路径经过多跳路由器、不同带宽链路、排队延迟不可控。Linux内核中tcp_rtt_estimator()函数会持续采样RTT样本用加权移动平均α0.875更新SRTTSmoothed RTT再用RTTVARRTT Variance估算偏差。最终RTO SRTT 4×RTTVAR。这意味着RTT抖动方差大 → RTO必须设得更保守 → 重传更迟钝但避免误重传。链路层如PPP、HDLC仅覆盖单跳物理链路传播延迟固定光速×距离排队延迟几乎为零。其重传定时器常设为固定值如100ms因为RTT方差极小。关键约束来源题干括号三空填“链路”而非“信道”是因为“链路”特指数据链路层抽象的点对点连接含MAC子层其可靠性由物理介质和本地重传保障而“信道”是物理层概念不涉及协议状态机。若填错说明你没区分清楚协议分层中“谁对谁负责”。提示实际工程中QUIC协议将RTO计算下沉到用户态正是为了绕过内核TCP对“链路层RTT方差小”的假设适配高丢包WiFi环境。但本题语境严格限定在传统TCP/IP栈。2.2 单选题第5题CRC校验的手算流程与生成多项式映射规则题干重现“当帧为 1101011011生成多项式为 x⁴x1 时相应的 CRC 为 ”选项A、1010 B、0101 C、1110 D、0111CRC不是黑盒是必须手算验证的确定性过程。步骤如下以生成多项式G(x)x⁴x1 → 二进制10011为例# 步骤1帧长度n10生成多项式阶数r4 → 补r个0 → 1101011011 0000 # 步骤2用模2除法异或代替减法除以10011 # 手算过程关键位对齐 # 11010110110000 # ÷ 10011 ← 对齐最高位1 # ----------------- # 11010 ⊕ 10011 01001 ← 异或后下移 # 010011 ⊕ 10011 000001 ← 注意补位 # ...完整过程略重点看余数 # 最终余数 1110 → 选项C参数说明x⁴x1的二进制表示必须是5位最高次幂1→10011不是1011常见错误模2除法中被除数每次取与除数等长的位段此处5位高位为1才触发异或余数位数恒等于r生成多项式阶数不足补0 → 本题余数1110即4位无需补零。实战经验Wireshark解析CRC字段时若校验失败但物理层无误码大概率是生成多项式配置错误如误用CRC-32 IEEE而非CRC-16 CCITT。本题用10011对应CRC-4是教学常用简化版。2.3 单选题第7题信道竞争概率模型的物理意义还原题干重现“共有 k 个站在竞争信道的使用权。每个站在每个时槽中的传送概率为 p。那么在一个给定的时槽中某一个站能够成功获得信道的概率为 ”选项A、kp(1-p)^(k-1) B、p(1-p)^(k-1) C、kp D、kp(1-p)这题考的是ALOHA协议的吞吐量推导根基。注意题干关键词“某一个站成功”而非“至少一个站成功”。正确逻辑指定某站如Station A发送概率p且其余k-1个站全部不发送每个概率1-p独立事件→ (1-p)^(k-1)故概率为p × (1-p)^(k-1)。为何不是A选项kp(1-p)^(k-1)是“恰好一个站成功”的总概率需乘k种选择但题干明确限定“某一个站”即已选定目标不需组合数。工程映射在LoRaWAN的ALOHA接入中终端随机选择时隙发送网关统计单个终端的成功率即用此公式。若误选A会导致链路预算计算偏高实际部署时入网失败率飙升。注意CSMA/CD中不存在此概率模型因其采用“先听后发”p不是独立设定而是受信道忙闲状态动态约束。3. 填空题即实战沙盒用标准答案反推协议实现的关键变量3.1 填空题第1题Nagle算法与Clark算法的协同边界题干重现“Nagle 算法和 Clark 针对愚笨窗口综合症的解决方案是相互补充的。Nagle 算法试图解决A问题Clark 则试图解决B问题。”标准答案A发送方产生大量小报文tiny segmentsB接收方通告极小窗口silly window syndrome at receiver为什么必须成对出现Nagle算法RFC 896在发送方起作用当有未确认数据且新数据不足MSS时缓存新数据直到收到ACK或积累满MSS。它解决的是发送端主动制造小包的问题。Clark算法RFC 813在接收端起作用当剩余接收缓冲区小于MSS/2时暂停通告窗口通告0直到缓冲区≥MSS/2才恢复通告。它解决的是接收端被动诱使发送端发小包的问题。实战验证在Linux中可通过sysctl -w net.ipv4.tcp_nagle1开启Nagle但若接收端应用层读取缓慢如recv()调用间隔长仍会触发Clark机制。用ss -i查看socket的rcv_space和rcv_ssthresh可观察窗口通告变化。3.2 填空题第4题慢启动双窗口的命名与决策逻辑题干重现“慢启动算法要求每个发送方维护两个窗口它们分别是A和B每次发送的字节数量取决于C。”标准答案A拥塞窗口cwndB接收窗口rwndCmin(cwnd, rwnd)关键细节深挖cwnd由发送方根据网络反馈动态调整每收到一个ACKcwnd MSS / cwnd体现网络承载能力rwnd由接收方通过TCP首部window字段通告体现应用层消费能力发送上限取二者最小值是端到端流量控制与拥塞控制的硬性交集。若忽略rwnd如某些嵌入式TCP栈会导致接收方缓冲区溢出丢包若忽略cwnd如早期UDP流控则引发全网拥塞。血泪经验某物联网设备固件升级时因接收端应用层处理速度慢rwnd长期为0但发送端未检测到rwnd0的阻塞状态持续重传导致设备死锁。修复方案是在发送循环中加入if (rwnd 0) break;判断。3.3 填空题第5题Go-back-N序列号空间的数学约束题干重现“在 Go-back-n 滑动窗口协议中假设不同的序列号个数是 16分别为 0~15。但是在任何时候未确认帧的最大数量只能是A这是因为B。”标准答案A15B若允许16个未确认帧则当序号0的ACK丢失时发送方可能将序号0重新发送而接收方已将原序号0数据交付上层此时新序号0帧会被误认为重复而丢弃导致数据丢失序号空间不足导致无法区分新旧帧数学本质Go-back-N要求发送窗口大小 ≤ 序号空间 / 2但本题序号空间为160~15为何答案是15而非8关键在题干“未确认帧的最大数量”即发送窗口大小。Go-back-N的正确约束是发送窗口大小 序号空间严格小于因为接收方需用下一个期望序号标识“已正确接收至该序号前所有帧”。若窗口16序号0~15全发出ACK0丢失后发送方重发0接收方期望序号为0因未收到ACK0但此时序号0帧是重传而接收方无法区分——因序号空间已被占满无冗余位标记新旧。故最大安全窗口15。验证Wireshark中过滤tcp.seq 0 tcp.ack 0可捕获重传序号0的场景结合tcp.analysis.retransmission标志确认。4. 判断题即排错手册五道题覆盖协议栈最顽固的故障模式4.1 判断题第1题TCP同时打开Simultaneous Open的连接数真相题干重现“服务器执行 listen 和 accept 原语等待连接请求客户执行 connect 原语发生的三次握手如图a所示。但若双方都试图同时发起连接即如图b所示那么将会建立起两个端到端连接。”答:正确答案错误。现象双方同时发送SYN各自进入SYN_SENT状态收到对方SYN后均回复SYNACK并进入SYN_RECEIVED最终双方收到SYNACK后均进入ESTABLISHED状态。原因TCP协议栈RFC 793明确定义了“同时打开”状态机只建立一个连接。双方的SYNACK互为对方的SYN和ACK形成双向同步。解决用netstat -tn观察只会看到一条ESTABLISHED连接而非两条。若出现两条必是应用层逻辑错误如客户端重复调用connect()。提示Linux中可通过echo 1 /proc/sys/net/ipv4/tcp_tw_reuse复用TIME_WAIT套接字但此操作与同时打开无关勿混淆。4.2 判断题第2题TPDU确认与事务完成的语义鸿沟题干重现“一个用户向一个远程数据库发出一些事务请求。远程传输实体先将 TPDU 传递给上一层然后确认。一旦接收到这个确认则可认为此项工作确实已经完成了。”答:正确答案错误。现象传输层TPDU确认仅表示数据已送达远端传输实体如TCP socket缓冲区不保证应用层已处理、数据库已提交、业务逻辑已执行。原因协议分层隔离了各层职责。传输层只管“送达”应用层如SQL事务需自行实现两阶段提交2PC或Saga模式保证ACID。解决在分布式系统中必须在应用层添加事务ID和幂等性校验。例如HTTP API返回202 Accepted仅表示请求已接收需轮询GET /task/{id}获取最终状态。注意此题直击微服务架构中“网络调用成功业务成功”的经典幻觉是某支付系统资金错账的根源之一。4.3 判断题第3题网络互联设备的分层归属纠偏题干重现“中继器、集线器、网桥、交换机、路由器和网关都是网络层互联设备。”答:正确答案错误。现象中继器Repeater、集线器Hub工作在物理层放大信号网桥Bridge、交换机Switch工作在数据链路层基于MAC地址转发路由器Router工作在网络层基于IP地址路由网关Gateway通常指应用层网关如HTTP代理或泛指跨协议转换设备。原因OSI模型中“网络层”特指Layer 3仅路由器符合。将集线器归为网络层等于混淆了信号再生与逻辑寻址的本质区别。解决用ethtool eth0查看网卡工作模式如Speed: 1000Mb/s属物理层用arp -a查MAC表数据链路层用ip route show查路由表网络层。避坑云厂商VPC中的“虚拟路由器”实为软件实现的Layer 3功能但底层可能复用OVSOpen vSwitch的Layer 2转发引擎需通过ovs-ofctl dump-flows br-int确认流表匹配层级。4.4 判断题第4题IP路由环路的数据包命运题干重现“假设两个路由器被错误地配置以致对某些目的地 D 产生了路由环目的地为 D 的 IP 数据包将会无休止地在环中传送。”答:正确答案错误。现象IP数据包头部有TTLTime To Live字段每经过一跳路由器TTL减1当TTL0时路由器丢弃该包并发送ICMP Time Exceeded消息。原因TTL是IP协议内置的防环机制非“无休止”。典型环路中数据包最多存活TTL跳默认64或128之后被静默丢弃。解决用traceroute -m 30 example.com可观察TTL递减过程若出现* * *连续超时表明中间某跳丢弃了TTL0的包而非无限循环。注意MPLS网络中使用TTL复制机制但本题限定IP层不涉及标签交换。4.5 判断题第5题CSMA/CD二元指数回退的算法本质题干重现“CSMA/CD 协议的二元指数回退算法本质上就是按 2 的幂次选择重试间隔直至占有信道。”答:正确答案错误。现象二元指数回退Binary Exponential Backoff并非简单“按2的幂次选择”而是第i次冲突后从[0, 1, 2, ..., 2^i - 1]中随机选取一个整数k等待k×SlotTime后重试。原因“随机选取”是核心避免所有站点在相同倍数后重试导致再次冲突。若按固定幂次如1,2,4,8...冲突概率趋近100%。解决在以太网控制器驱动中如Intel e1000e1000_adjust_tbi_phy()函数会调用random32()生成回退值。用cat /proc/net/dev观察collisions计数若持续升高需检查物理层如网线质量而非算法。血泪经验某数据中心曾因交换机端口协商为半双工导致CSMA/CD频繁触发collisions每秒数千次。强制全双工后归零——证明回退算法再精妙也救不了物理层缺陷。5. 问答题即架构推演三道题穿透网络设计的哲学内核5.1 问答题第1题逆向转发路径树RPF的构建逻辑题干重现“已知子网拓扑结构和 F 为根的汇集树分别如图a和b所示给出广播源为 F 的逆向转发路径树。”核心原理RPFReverse Path Forwarding是组播路由如PIM-SM防环的核心机制其本质是按单播路由表反向查源。步骤对于广播源F每台路由器查询自身单播路由表找到到达F的最优下一跳接口仅当组播报文从该接口到达时才向其他接口转发否则丢弃即“反向路径”必须匹配单播路径。结果树特征RPF树是以源F为根的最短路径树SPT但构建依据是单播路由而非组播协议自身计算。实战验证在Cisco IOS中show ip mroute输出中的Incoming interface即RPF接口。若该接口与show ip route F显示的下一跳不符组播将中断。5.2 问答题第2题可变滑动窗口协议中ack15的时序解构题干重现“下面的时序图是可变滑动窗口协议的一种可能工作方式为什么第 2 条消息的 ack15消息 16 存在的死锁问题如何解决”ack15的必然性假设初始窗口大小为10序号从0开始第1条消息发送序号0~9接收方正确接收返回ack10期望下一个序号发送方收到ack10后窗口滑动发送序号10~15共6个其中第2条消息携带序号15接收方收到序号15后若10~14尚未到达乱序则按累积确认规则ack仍为10但题干指定ack15说明10~14已全部到达故ack15表示“已正确接收至序号15”。消息16死锁的根源与解法死锁场景若消息16发送后丢失接收方因未收到16不更新ack仍为15发送方等待ack16超时后重传但重传16又丢失形成循环。标准解法超时重传Timeout Retransmission发送方为每个未确认序号设置独立定时器快速重传Fast Retransmit接收方收到3个重复ack15时立即触发重传序号16不等超时选择性确认SACK接收方在ack15中附带SACK块声明已收到17~20让发送方只重传16。注意TCP中tcp_sack内核参数控制SACK启用netstat -s | grep -i sack可验证是否生效。5.3 问答题第3题隧道技术的本质与三层穿透案例题干重现“什么是隧道技术举例说明之。”定义隧道Tunneling是在一种网络协议的报文中封装另一种网络协议报文的技术实现协议透明穿越不兼容网络。核心三要素乘客协议Passenger Protocol被封装的原始协议如IPv6承载协议Carrier Protocol提供传输通道的协议如IPv4封装协议Encapsulation Protocol定义封装格式的协议如GRE、IPsec ESP。经典案例6to4隧道场景IPv6孤岛需通过IPv4互联网互通封装IPv6报文作为载荷外层添加IPv4首部目的IPv4地址由IPv6前缀2002::/16派生如2002:c0a8:0101::1→ IPv4192.168.1.1解封边缘路由器收到IPv4包识别2002::/16前缀剥离IPv4首部将IPv6载荷交给本地IPv6栈。验证Linux中用ip tunnel add tun6to4 mode sit remote any local 192.168.1.1 ttl 64创建6to4隧道ping6 2002:c0a8:0101::1测试连通性。6. 从样卷到生产环境我如何用这份2011年B卷重构TCP调试心法6.1 用填空题第2题的香农定理校准真实链路的吞吐量预期填空题第2题要求计算信噪比30dB下的香农极限信噪比SNR 10^(30/10) 1000香农容量 C B × log₂(1SNR) 2000 × log₂(1001) ≈ 2000 × 9.97 19940 bps这个数字像一面镜子照出我们常犯的“理论幻觉”。某次调试一个工业传感器的RS-485转以太网网关实测吞吐量卡在18kbps开发团队坚称“硬件性能足够”直到我拿出这张卷子实际信道带宽2000HzRS-485典型值现场电磁干扰导致SNR跌至20dBSNR100→ C 2000 × log₂(101) ≈ 13.3kbps实测18kbps已超香农极限必然丢包行动用频谱分析仪定位干扰源变频器谐波加装磁环滤波SNR回升至25dBSNR316→ C≈16.8kbps实测稳定在16.2kbps。从此我每次调试物理层必先测SNR再算香农容量——这比任何“加大缓冲区”都管用。6.2 用判断题第4题的TTL机制设计分布式系统的健康心跳判断题第4题揭示TTL的防环本质这直接启发了我设计某微服务集群的心跳协议传统方案服务A每5秒向注册中心发心跳超时30秒剔除问题网络分区时A与注册中心失联但A仍在运行注册中心误删实例流量打到宕机节点。重构方案TTL式心跳每个服务实例携带本地TTL计数器初始值10注册中心收到心跳重置该实例TTL10注册中心后台线程每秒扫描所有实例TTL减1TTL0时剔除服务A若失联TTL自然耗尽无需依赖网络可达性判断。表格TTL心跳 vs 传统心跳对比维度传统心跳TTL心跳分区容忍差依赖网络连通强本地计数器自治资源开销低纯网络IO极低内存计数器原子操作故障检测延迟固定超时如30秒可配置如10秒实现复杂度简单简单注册中心单点维护这套方案上线后集群因网络抖动导致的误剔除归零。从那以后我每次设计状态同步协议都强制走一遍TTL衰减推演——不是为了炫技而是确保系统在最坏网络条件下仍有确定性行为。希望帮到你。本文还有配套的精品资源点击获取