简介中国海洋大学计算机网络课程的传输控制协议Reno版本实验资源包面向网络协议学习者与高校学生主要用于理解TCP拥塞控制中快速重传与快速恢复的算法原理。整份资源共一百三十五个文件压缩包仅1.48MB以HTML讲解文档和Java源码为主同时包含编译后的class文件、工程配置文件及少量jar包和文本说明便于直接对照源码阅读、编译调试和运行验证。目前已有七百九十九人学习下载。内容紧密围绕Reno拥塞控制机制展开涵盖实验环境搭建、发送端与接收端核心实现、拥塞窗口和慢启动阈值的动态调整、重复确认触发快速重传等关键环节通过模拟不同网络延迟与丢包条件可观察传输速率和窗口变化直观掌握快速恢复策略以及防止中间窗口收缩的设计思路。资源包可帮助学生在完成课程实验的同时系统梳理Reno与标准TCP的差异提升协议分析与编程实现能力也适合作为相关课程报告的参考资料。 最近刚把海大的计算机网络实验做完其中最有代表性、也是让我折腾最久的一个就是基于Reno版本的TCP拥塞控制仿真。这个实验在计算机网络课程里属于“必做且必须吃透”的项目——它不光是验证一下AIMD机制那么简单而是把慢启动、拥塞避免、快速重传、快速恢复这一整套拥塞控制流程全部串起来跑一遍。对准备期末复习的同学来说这篇博文也可以当一份带实操的复习资料用。这个实验适合三类人正在做海大计网实验、需要写实验报告的学生正在复习TCP拥塞控制、被“快重传和快恢复到底怎么触发”绕晕的备考党以及想搞明白Reno、Tahoe、NewReno这几个拥塞控制算法差异的技术爱好者。文章里我会把实验的整体设计思路、NS2脚本的关键参数、trace文件的分析方法以及我踩过的坑全部展开讲清楚。1. Reno为什么是计算机网络实验的“常客”1.1 TCP拥塞控制解决什么问题先从一个最实际的问题切入为什么TCP需要拥塞控制想象一下如果网络中所有发送方都按自己的最大速率发包路由器缓存很快会被填满之后到达的数据包只能被丢弃。TCP为了感知网络状况引入了拥塞窗口cwnd, congestion window这个概念它决定了发送方在未收到ACK的情况下最多能发送多少数据。但问题来了发送方并不知道网络的真实可用带宽是多少。所以TCP必须一边探测一边调整。Reno算法是这一领域的经典方案也是RFC 2581推荐的拥塞控制基础实现。它最核心的思想可以用一句话概括加性增乘性减AIMD——没有拥塞时缓慢增加发送速率检测到丢包时立刻大幅降低。这个算法在计算机网络教材里是必考内容也是最容易在实验里直观验证的内容。做这个实验你能看到cwnd随时间的变化曲线真实地看到“慢启动指数增长—拥塞避免线性增长—检测到丢包窗口减半”这个循环过程。这比死记硬背“ssthresh等于cwnd一半”要有用得多。1.2 Reno的四个阶段到底在做什么Reno算法的工作过程可以拆成四个状态它们在NS2的仿真里对应着不同的代码路径。理解这四个阶段是做实验报告前必须完成的功课。慢启动连接建立后cwnd从初始值通常是1个MSS即最大报文段长度开始每收到一个ACKcwnd增加一个MSS。这样cwnd会呈指数增长。慢启动不是真的“慢”它是在快速探测网络的可用带宽。拥塞避免当cwnd达到慢启动阈值ssthresh后进入线性增长阶段。每经过一个RTT往返时间cwnd增加一个MSS。这一步是为了避免cwnd增长过快导致网络突发拥塞。快速重传当发送方连续收到3个重复ACK时认为某个报文段丢失立即重传该报文段不必等待超时定时器到期。这一步是Reno相对于Tahoe的重要改进之一。快速恢复重传丢失报文段后ssthresh被设置为当前cwnd的一半cwnd也减半但不会回落到1而是从这个减半后的值继续执行拥塞避免。这样能保持较高的链路利用率。这里有一个很容易弄混的点Reno和Tahoe的最大区别就在于丢包之后cwnd是减半还是归1。Tahoe一旦检测到丢包cwnd直接回到1重新慢启动Reno则只减半然后进入拥塞避免。这个差异直接体现在仿真曲线里Tahoe的锯齿图波动非常剧烈Reno则平滑很多。2. 实验环境搭建与仿真脚本设计2.1 环境准备NS2还是ns-3海大的计算机网络实验对这个项目的默认要求是使用NS2来完成仿真但不同学期可能会允许用ns-3。我建议首次做这个实验的同学直接用NS2原因有两点一是网上Reno实验的参考脚本基本都是NS2的Tcl脚本遇到问题容易找到答案二是NS2的nam动画演示比较直观做答辩汇报时能直接展示数据包的丢失和重传过程。安装NS2时需要注意版本选择。Ubuntu系统上推荐直接安装ns2 2.35版本安装命令很简单。sudo apt-get update sudo apt-get install ns2 nam安装完成后在终端输入ns如果能看到%提示符就说明安装成功了。这里有个容易踩的坑NS2依赖的OTcl库版本可能和你系统自带的版本冲突如果启动时报错couldnt find libotcl多半是系统缺少了对应依赖建议先安装libtool、autoconf再重新编译。2.2 Tcl脚本关键参数解读很多人拿到实验脚本后第一反应是“看不懂”这里我挑几个关键参数拆开讲。NS2的Tcl脚本本质上是在建立一个虚拟网络拓扑然后定义TCP代理和FTP应用最后设置仿真结束时间。下面是一个简化但完整的Reno仿真脚本主体set ns [new Simulator] set tr [open out.tr w] $ns trace-all $tr set namfile [open out.nam w] $ns namtrace-all $namfile set n0 [$ns node] set n1 [$ns node] set n2 [$ns node] set n3 [$ns node] $ns duplex-link $n0 $n1 10Mb 2ms DropTail $ns duplex-link $n1 $n2 10Mb 2ms DropTail $ns duplex-link $n1 $n3 10Mb 2ms DropTail set tcp [new Agent/TCP/Reno] $ns attach-agent $n0 $tcp set sink [new Agent/TCPSink] $ns attach-agent $n3 $sink $ns connect $tcp $sink $tcp set window_ 100 $tcp set packetSize_ 1000 set ftp [new Application/FTP] $ftp attach-agent $tcp $ns at 0.0 $ftp start $ns at 10.0 $ftp stop $ns at 10.1 finish proc finish {} { global ns tr namfile $ns flush-trace close $tr close $namfile exit 0 } $ns run这几个参数需要在实验报告里重点解释Agent/TCP/Reno指定TCP代理使用Reno版本。这是整个实验的核心换成Agent/TCP/Newreno就是另一个版本。window_ 100接收方通告窗口大小它限制了cwnd的最大值。实验里如果这个值设得太小拥塞控制的行为就不能完整展现。duplex-link $n0 $n1 10Mb 2ms DropTail定义节点n0和n1之间的链路带宽10Mb传播时延2ms队列管理机制是DropTail。队列大小没有在这里指定NS2默认会使用5个数据包的队列缓存这个值对丢包行为影响很大。packetSize_ 1000每个TCP段的大小设为1000字节。2.3 拓扑设计与流量背景实验里最容易被忽视的部分是拓扑结构的选择。单条链路的拓扑只能展示最基本的TCP行为但如果你想让实验报告更有说服力最好加上一个背景TCP流或者UDP流来制造网络拥塞。我用的拓扑是三个节点构成的哑铃结构n0和n1之间是核心瓶颈链路n1到n2是背景流量路径n1到n3是主TCP流路径。这样一来瓶颈链路的带宽会被两个流共享主流的cwnd就会因为竞争而出现周期性的下降Reno的锯齿特征会非常明显。如果你想让结果更接近真实网络可以在n1和n2之间再挂一个UDP代理通过CBR恒定比特率流量占用带宽set udp [new Agent/UDP] $ns attach-agent $n1 $udp set null [new Agent/Null] $ns attach-agent $n2 $null $ns connect $udp $null set cbr [new Application/Traffic/CBR] $cbr attach-agent $udp $cbr set packet_size_ 1000 $cbr set rate_ 5Mb $ns at 0.0 $cbr start $ns at 10.0 $cbr stop这里的rate_ 5Mb很关键。因为瓶颈链路带宽是10MbCBR占掉5Mb后TCP流最多只能用到5Mb这就人为制造了一个“可用带宽上限”。你会在trace文件里看到TCP流的cwnd增长到某个值后开始出现丢包然后迅速减半——这就是Reno对瓶颈带宽的探测过程。3. 跑通实验与Trace文件分析3.1 运行仿真与获取数据执行仿真只需要一行命令ns reno.tcl运行结束后会生成两个文件out.tr是trace文件记录了每一个数据包的详细信息out.nam是动画文件可以用nam播放。trace文件的每一行格式比较固定比如 1.23456 0 1 tcp 1000 ------- 0 0.0 3.0 100 101 - 1.23456 0 1 tcp 1000 ------- 0 0.0 3.0 100 101 r 1.23456 1 3 tcp 1000 ------- 0 0.0 3.0 100 101需要关注的是每行的第一个字符表示数据包进入队列-表示数据包从队列发出r表示数据包被接收方收到d表示数据包被丢弃。你要统计丢包率只需要统计d开头的行数除以总发送包数即可。分析trace文件时我建议先用awk快速看一眼丢包的时间点分布awk $1d {print $2} out.tr | head -20如果丢包集中在某个时间段说明网络拥塞在那个时间段达到峰值。之后结合cwnd曲线图就能判断Reno的“乘性减”是否如预期那样在丢包后立刻生效。3.2 如何生成并解读cwnd曲线图NS2本身不直接输出cwnd你需要从trace文件里提取数据然后用gnuplot画图。提取cwnd的方式比较粗糙但很有效每个r事件里的倒数第二个字段是数据包序号但cwnd需要从TCP代理内部记录所以标准做法是用一个AWK脚本从Agent/TCP/Reno的trace信息中提取。更简单的替代方法是在Tcl脚本里给TCP代理添加一个trace目标在每条ACK到达时记录当前cwndset tcp_file [open cwnd.tr w] $tcp attach $tcp_file $tcp trace cwnd_这样cwnd.tr里会按照时间序列记录cwnd的变化。之后用gnuplot画图gnuplot EOF set terminal png set output cwnd.png plot cwnd.tr using 1:2 with lines title CWND EOF拿到cwnd曲线后怎么判断Reno工作正常关键看三点曲线开头是否有一段指数上升慢启动阶段曲线斜率越来越陡。是否出现锯齿状周期波动上升到顶峰后急剧下降然后再缓慢上升。下降后的回升起点是否等于峰值一半Reno的快速恢复会把cwnd调整到ssthresh附近所以回升不是从0开始而是从峰值一半开始线性爬坡。3.3 吞吐量与RTT的联动分析cwnd曲线能直观体现算法行为但要论证算法性能还需要计算吞吐量。平均吞吐量可以近似用这个公式表示吞吐量 ≈ (发送总字节数) / (仿真总时间)在Linux命令行里统计发送总字节数比较简单。awk $1 $30 {count $6} END {print count} out.tr这里的$6是数据包大小$30表示发送节点是0号节点。把结果除以仿真持续时长10秒就是平均吞吐量。RTT的分析更有意思。从trace文件里对每一个数据包记录它的发送时间和对应ACK的到达时间两者之差就是该包的RTT。在Reno中当网络开始拥塞队列排队延迟增加RTT会随之上升。你会观察到一个典型的因果链条RTT上升 → 丢包发生 → cwnd减半 → RTT下降。这个联动关系在实验报告中是非常加分的观察。4. 常见问题与排查技巧实录4.1 仿真结果不符合预期的排查思路我在实验过程中遇到过一个经典问题无论怎么调整参数cwnd曲线都没有锯齿波动而是一条直线上升到上限后不再变化。后来排查发现是因为瓶颈链路队列长度被设成了无限大——当队列不会丢包时TCP根本不会感知到拥塞自然也不会触发乘性减。如果你遇到同样的情况优先检查以下几点。队列管理机制是否为DropTail队列长度是否有限在duplex-link命令后加上queue-size参数比如$ns duplex-link $n0 $n1 10Mb 2ms DropTail 50限制队列最多放50个包。CBR背景流量是否真的占用了带宽如果背景流量速率太低主流不会经历拥塞就不会出现丢包。仿真时间是否足够长TCP需要经历好几个RTT才能进入拥塞避免阶段如果仿真只跑了2秒可能还没看到完整的锯齿就被强制结束了。接收方通告窗口是否限制了cwnd增长如果window_设置得太小cwnd会直接撞上窗口上限此时会表现为一条水平直线。4.2 Reno和Tahoe、NewReno的对比怎么看做实验报告时导师通常不会只满足于“Reno跑通了”更希望看到不同算法之间的对比。最少要跑三个版本Tahoe、Reno、NewReno。在NS2里改一行就能换算法set tcp [new Agent/TCP/Tahoe] set tcp [new Agent/TCP/Reno] set tcp [new Agent/TCP/Newreno]对比时重点观察两个层面多条cwnd曲线叠加后下降的幅度差异Tahoe在丢包后掉到1重新慢启动Reno掉一半进入拥塞避免NewReno在改进丢包恢复机制后即使在同一个窗口内出现多个丢包也能高效恢复。相同仿真条件下总吞吐量的数值差异这个差异通常不是特别大但在队列较短的场景下Tahoe的吞吐量会明显低于Reno和NewReno。我这里有一个自己实测的数据供参考瓶颈带宽10Mb队列长度50包CBR背景流量5Mb仿真时长30秒算法版本总发送字节数平均吞吐量丢包数Tahoe约18.7 MB约5.0 Mbps约120Reno约19.2 MB约5.1 Mbps约70NewReno约19.5 MB约5.2 Mbps约35数据不用精确到小数关键是趋势要正确NewReno的丢包数明显少于RenoReno好于Tahoe。如果你跑出反向的结果优先检查是不是数据包序号统计口径不一致。4.3 报告写作与验收的注意事项实验报告的价值不在于代码贴得多长而在于你有没有把“现象”和“原理”对应起来。海大计网实验验收时老师喜欢问的几类问题一定要提前准备。第一个高频问题是“为什么慢启动叫慢启动但它的增长是指数增长”回答要点在于这里的“慢”是指TCP从1个MSS开始发送而不是一下把整个窗口都推出去。指数增长是为了快速探测带宽但每轮RTT只翻倍一次所以整体节奏是可控的。第二个高频问题是“为什么收到3个重复ACK就可以触发快速重传”答因为网络不会乱序产生重复ACK只有当后面的数据包到达时才会触发对期望序号的重复确认连续3个重复ACK说明至少有3个后续包到达了网络大概率没有严重拥塞丢包只是偶发所以可以直接重传而不需要等超时。第三个高频问题则是“ssthresh的值是谁定的”初始值由操作系统设置实验里可以手动指定丢包发生后Reno算法会将ssthresh更新为当前cwnd的一半。这个值不是固定的而是随网络状况动态调整的。另外如果实验报告要画图建议用gnuplot生成的矢量图而不是截图。矢量图在缩放后依然清晰老师在看报告时体验会好很多。第一次跑出的图像往往有大量噪声可以先统计一下丢包位置然后xrange限制到丢包附近的时间区间只截取两个锯齿周期内展示这样核心特征会更突出。结语一点个人体会做完这个实验我个人最大的感受是计算机网络这门课里很多概念比如拥塞窗口、慢启动阈值、快速恢复光看教材永远隔着一层真正动手改过参数、盯着cwnd曲线变化之后才明白这些机制为什么被设计成这个样子。网络拥塞控制本质上是在“效率”和“公平”之间反复权衡Reno用简单到极点的一条AIMD规则就实现了这种权衡这是它即使问世几十年后依然是教学和考试核心内容的原因。最后分享一个小技巧实验过程中别只跑一组参数。建议至少做三组对比实验——不同队列长度、不同带宽延迟乘积BDP、不同背景流量带宽。你会发现Reno在面对不同网络条件时的行为差异非常大把这三组结果写进实验报告的分析部分整个报告的深度会提升一个档次。如果后续还有精力也可以试试把Agent/TCP/Reno换成Vegas或CUBIC看看基于时延的拥塞控制和基于丢包的拥塞控制在cwnd曲线上的差异那又是另一个有意思的话题了。本文还有配套的精品资源点击获取