简介中国海洋大学计算机网络实验TCP Reno版本资源包面向计算机网络课程学生与TCP拥塞控制初学者聚焦TCP Reno快速重传与快速恢复算法的实验设计与实现。压缩包内含135个文件约1.48MB以84个HTML实验文档/说明为主辅以Java源码、class字节码、XML配置、jar依赖及txt记录便于直接导入工程查看与运行。已有799人学习浏览是校内实验常用的参考资料。资源内不仅提供可运行的发送端/接收端类、校验和工具及测试运行入口还包含完整的实验环境与结果分析文档。学生可按“环境搭建—算法实现—测试分析—结果讨论”流程复现实验在模拟网络中观察丢包、延迟和吞吐量指标深入理解拥塞窗口与慢启动阈值的调节逻辑为后续网络优化与系统设计打下基础。1. 课程实验为什么要单独指定Reno一次对AIMD机制的回归1.1 从Tahoe到Reno一段TCP演进主线的缩影如果你看过《计算机网络》教材里TCP拥塞控制的章节大概率见过一个曲线图——cwnd先垂直爬升撞到阈值后改成线性爬坡然后突然断崖式下跌再循环。这张图大多数教材都直接标注为Reno或者NewReno的行为。中国海洋大学计算机网络实验指定“reno版本”本质上是让你亲手把这张图跑出来而不是停留在背概念的层面。TCP拥塞控制从Tahoe开始就有了慢启动和拥塞避免但Tahoe丢包后直接回到cwnd1重新慢启动这种做法在带宽已经不算小的链路上浪费严重。Reno在Tahoe基础上加了快速重传和快速恢复收到3个重复确认就认为网络出现拥塞但没有完全断流于是只把ssthresh和cwnd各减半继续在拥塞避免阶段维持发送。Networking课上讲的AIMD加性增、乘性减原则在Reno身上体现得最纯粹。后来的NewReno、Cubic、BBR本质上都是在Reno这个骨架上做修补和优化——NewReno解决了同一个窗口内多个丢包恢复慢的问题Cubic换了一条更适合高带宽长链路的增长曲线但“快恢复后回到拥塞避免”这一核心逻辑至今还在用。1.2 Reno实验真正要验证的三个行为做这个实验之前先想清楚要验证什么。Reno的核心行为可以拆成三条慢启动阶段cwnd每个RTT翻倍指数增长达到ssthresh后进入拥塞避免cwnd每个RTT只加1个MSS线性增长收到3个重复ACK后ssthresh设为当前cwnd的一半cwnd也降为一半进入快速恢复若发生超时则ssthresh减半、cwnd回到1重新慢启动。这三条是实验报告的“灵魂”。如果你的仿真脚本跑完绘制出来的cwnd曲线跟这三条对不上那实验步骤一定有错如果对上了你就把教材上最抽象的一段机制变成了可复现的事实。这也是为什么老师指定“reno版本”而不是直接用默认协议——默认设置往往用了NewReno甚至Cubic它们的行为更复杂反而不方便对照教科书做分析。1.3 为什么不用Linux默认的Cubic很多同学会有疑问现在的Linux服务器上默认拥塞控制算法是Cubic为什么实验不直接做CubicCubic用三次函数描述窗口增长丢包后的窗口恢复更快在高速网络上效率高但它对拥塞的反应不是“减半-线性增加”这种简单规则数学上分析和画图都不直观。Reno的好处在于参数少、行为简单、每一步都对应一个理论值拿它来理解“反馈回路”的概念再合适不过。还有一个隐性原因实验环境往往是小规模的仿真拓扑瓶颈带宽和时延都是自己设的Reno在这种环境下刚好能把各种阶段完整跑出来。Cubic在高带宽下会长时间处于平台期反而看不出慢启动、快速重传这些细节。所以“reno版本”本身就是一个经过权衡的教学选择。2. 仿真环境准备ns-3安装与基线网络拓扑搭建2.1 环境依赖与安装时要注意的版本差异海大这个实验我建议用ns-3来做环境干净、可控性强而且脚本从提交到复现都方便。ns-3的编译体系在新版本里已经从waf切换到了CMake如果你拿到的教程还是./waf configure这种老命令要先确认版本。ns-3.36之后基本都是./ns3 configure --enable-examples --enable-tests ./ns3 buildconfigure阶段最容易被卡的是缺少依赖库。Ubuntu/Debian系可以直接装这一组sudo apt install g python3 python3-dev cmake ninja-build sudo apt install libgsl-dev libsqlite3-dev libxml2-dev装完后跑一下./ns3 build编译时间取决于机器通常10到20分钟。第一次build建议耐住性子不要因为编译输出看起来像卡住就中断等出现“build finished”才算完。编译完成后可以跑一个简单示例验证环境./ns3 run first能正常打印输出说明环境OK。2.2 哑铃拓扑最容易理解拥塞控制的最小网络为了观察Reno的拥塞控制行为网络拓扑不需要复杂一条带瓶颈链路的哑铃状拓扑就够。我用的拓扑是这个发送节点n0 - 路由器r0 - 路由器r1 - 接收节点n1r0到r1之间是瓶颈链路带宽设为1 Mbps单向时延10 msn0到r0、r1到n1的链路带宽设成10 Mbps时延1 ms确保瓶颈只出现在中间链路上队列管理用最简单的DropTail尾部丢弃队列长度设置为关键参数。为什么必须刻意制造瓶颈因为拥塞控制说白了就是对瓶颈链路资源的争抢。如果没有瓶颈TCP发送方永远不会触发拥塞信号cwnd会一直涨到接收窗口上限实验也就没有意义。设置瓶颈之后TCP流量会持续塞满队列并触发丢包进而看到快速重传、快速恢复的完整链条。2.3 队列长度参数直接决定你能看到几次“锯齿”队列长度这个参数特别值得讲。很多同学随便设一个100个包的缓冲区结果cwnd曲线几乎不下降因为缓冲区太大了丢包迟迟不发生。理论上瓶颈链路的带宽时延积BDP约为带宽乘以RTTRTT按两个方向的时延粗算约22 msBDP ≈ 1 Mbps × 22 ms ≈ 22 kbit按每个包约1 KB计算大约就是3到4个包。实际为了模拟真实设备我通常把队列长度设为BDP的数倍比如20个包。如果设成100个包丢包前需要积累大量排队数据整个实验可能要很久才能看到一次窗口减半如果设成2个包又会过于频繁地丢包导致大部分时候都在慢启动。这个参数需要根据你的链路调整。PointToPointHelper bottleNeck; bottleNeck.SetDeviceAttribute(DataRate, StringValue(1Mbps)); bottleNeck.SetChannelAttribute(Delay, StringValue(10ms)); // 瓶颈链路设备 NetDeviceContainer devices bottleNeck.Install(nodeRouter0.Get(0), nodeRouter1.Get(0)); // 设置队列长度 TrafficControlHelper tch; tch.SetRootQueueDisc(ns3::PfifoFastQueueDisc, MaxSize, StringValue(20p)); tch.Install(devices);队列管理这里需要再提一句ns-3中默认的流量控制模块可能会安装CoDel等主动队列管理算法如果你用的是较新版本最好显式指定DropTail/Fifo队列避免CoDel提前丢包干扰了你对Reno行为的观察。这也是很多实验报告里cwnd曲线“不标准”的隐形原因。3. 仿真脚本中的关键配置把TCP协议换成Reno3.1 SocketType的全局替换与生效范围ns-3里TCP协议栈是通过TcpL4Protocol的SocketType属性来指定的。默认情况下会选TcpNewReno要做Reno版本就必须在仿真脚本开头加一行#include ns3/tcp-reno.h Config::SetDefault(ns3::TcpL4Protocol::SocketType, TypeIdValue(TcpReno::GetTypeId()));这里有个容易被忽略的点Config::SetDefault设置的是“所有后续创建的TCP套接字”。如果你的脚本里先后创建了多个应用比如FTP和Web混合流量那么所有TCP连接都会被替换成Reno。只做单条TCP流实验时没问题但如果你比较的是Reno和TcpNewReno的差异就需要在创建Socket后再动态指定类型或者在两次仿真中分别执行不同配置不能在一个脚本里混着来。验证是否设置成功有个土办法在脚本里打印TcpL4Protocol的SocketType值或者直接看最终cwnd曲线的形状。Reno在丢包时cwnd只减半Tahoe会直接跌回1两种曲线一眼可辨。3.2 关闭SACK确保你看到的是“纯Reno”这里有个细节很多人会踩ns-3中TcpSocketBase默认可能开启SACK选项SACK本身不影响快速重传的基本逻辑但在乱序和多次丢包场景下SACK会让恢复过程变得比纯Reno更快导致曲线在某些阶段不够“教科书”。为了实验报告能够严格对应理论建议在脚本里把SACK关掉Config::SetDefault(ns3::TcpSocketBase::Sack, BooleanValue(false));同样的道理如果想让“3个重复ACK触发快速重传”的行为干净可见建议把延迟ACK也做一下处理。接收端的延迟ACK机制会把连续两个包的ACK合并成一个这样收到3个重复ACK需要的乱序报文数量会变化影响观察。可以通过设置接收端应用的PacketSink的属性或者直接用EnbAckDelay为0的配置来消除。关闭SACK和延迟ACK后Reno的行为会更贴近课本描述。3.3 应用层流量设计BulkSendApplication PacketSinkTCP拥塞控制实验的流量最好用长期、饱和的流量来跑不能只发几秒钟就停了。常用组合是发送端用BulkSendApplication持续推流接收端用PacketSink接收BulkSendHelper bulkSend(ns3::TcpSocketFactory, InetSocketAddress(serverAddr, port)); bulkSend.SetAttribute(MaxBytes, UintegerValue(0)); // 0表示无限发送 bulkSend.SetAttribute(SendSize, UintegerValue(1000)); // 1000字节 PacketSinkHelper packetSink(ns3::TcpSocketFactory, InetSocketAddress(Ipv4Address::GetAny(), port));MaxBytes设置为0很关键这样发送方会一直有数据要发拥塞窗口就始终是限制因素。仿真时间一般设成20到60秒。太短跑不出几次拥塞事件太长后面全是重复的锯齿徒增处理时间。3.4 采集cwnd数据连上CongestionWindow这个信号源在ns-3中观察cwnd变化不需要去抓报文再解析TCP协议栈本身就带跟踪源最常用的是TcpSocketState中的CongestionWindow。连接方式可以这样Config::ConnectWithoutContext( /NodeList/0/$ns3::TcpL4Protocol/SocketList/0/CongestionWindow, MakeCallback(CwndTracer));注意路径里的$ns3::TcpL4Protocol是向下类型转换的语法SocketList索引0对应第一个创建的Socket。如果你的脚本里有多个Socket索引可能对不上可以先通过Simulator::Schedule打印所有Socket数量来确认。回调函数里把时间和窗口值写入文件void CwndTracer(uint32_t oldVal, uint32_t newVal) { std::cout Simulator::Now().GetSeconds() newVal std::endl; }拿到这个文件之后用gnuplot一画就是整个实验最核心的交付物。比如gnuplot -e plot cwnd.txt using 1:2 with lines title TCP Reno CWND提示节点编号0和1是创建时Order决定的路由器节点如果先被创建编号会前置Socket路径也会变化。跑不通时先打印NodeList确认编号。4. 运行结果分析与Reno行为验证从锯齿曲线读故事4.1 cwnd曲线的四个阶段识别实验跑完后打开cwnd数据文件用gnuplot绘图。下面这个表格是我自己实验过程中的关键判据时间段/片段曲线特征对应机制连接建立初期陡峭指数上升每RTT翻倍慢启动第一次达到ssthresh转折点斜率变缓进入拥塞避免拥塞避免段斜率接近线性每个RTT增长1个MSSAIMD线性增加突然掉半cwnd骤降到峰值的一半3个重复ACK触发的快速恢复从半山腰重新爬升沿用当前ssthresh线性增长快速恢复后回到拥塞避免cwnd跌到1从1重新陡峭上升超时重传后重新慢启动对照课本里那张AIMD锯齿图你会发现Reno版本几乎能复刻它。区别只在于仿真中的噪音、队列长度、接收窗口上限都会让锯齿的周期和振幅不完全均匀这是正常的不是错误。4.2 用Flow Monitor看吞吐和丢包除了cwnd曲线实验报告通常还需要吞吐率、丢包率或者排队时延。ns-3的Flow Monitor模块可以直接统计这些指标FlowMonitorHelper flowmon; PtrFlowMonitor monitor flowmon.InstallAll(); Simulator::Stop(Seconds(30.0)); Simulator::Run(); monitor-CheckForLostPackets(); monitor-SerializeToXmlFile(result.xml, true, true);运行完后查看result.xml提取出Tx Packets、Rx Packets、Lost Packets、Throughput这些字段。对一个30秒、1 Mbps瓶颈的仿真如果TCP Reno工作正常实际吞吐率应该接近0.95 Mbps以上剩余带宽被协议开销消耗。如果吞吐只有0.5 Mbps说明参数设计有问题大概率是队列太短或时延太大导致TCP频繁进入慢启动链路利用率上不去。4.3 和理论值对照慢启动时间估算实验报告里如果只是粘贴仿真图还缺少“理论验证”的说服力。慢启动阶段有个经典估算方法可用假设初始ssthresh为64个MSS每个RTT约22 ms那么从cwnd1增长到64大约需要6个RTT2的幂次增长即132 ms左右。你在cwnd数据文件里找到从开始到2、4、8、16、32、64的时间点会发现相邻时间差基本都等于一个RTT。把这段代码和理论值对照表写进实验报告比单纯说“符合预期”要扎实得多。需要提醒的是ns-3里慢启动阶段还可能受“初始窗口”设置影响默认初始cwnd可能是1也可能按RFC 6928设置为10。如果曲线第一跳就从1跳到2甚至更高先查初始窗口配置。这不算错误只是理论计算要对齐。5. 踩坑实录为什么我的cwnd曲线不像课本那样5.1 曲线一路陡峭上涨从不回落这是最常遇到的问题。原因通常是瓶颈链路队列太长或者没有设置瓶颈链路。我见过有同学把三条链路带宽都设为100 Mbps队列默认1000包结果整个仿真期间cwnd一路涨到接收窗口上限实验报告里只有一条几乎没有波动的曲线根本没法分析。解决办法先把瓶颈链路明确设置成1 Mbps或2 Mbps队列长度设成20包左右仿真时间拉长到30秒以上。如果还是不出锯齿可以在脚本里打印丢包事件确认有没有发生队列溢出。没有丢包就没有拥塞信号cwnd自然不会下降。5.2 只有超时重传没有快速重传典型现象是cwnd曲线掉到1然后重新陡峭爬升整条曲线找不到“只减半”的步骤。这说明TCP没有触发3个重复ACK而是走了RTO超时路径。可能原因有几个丢包发生得太集中队列一下子把窗口内的大量包全部丢弃接收端无法产生足够的重复ACK瓶颈队列的丢包策略是随机早期检测丢包分布不集中接收端延迟ACK时间太长重复ACK数量不足。这个问题的排查顺序是先用Flow Monitor看丢包数量和时间点再确认队列管理是DropTail还是CoDel。CoDel这类主动队列管理故意让少量包延迟或者丢弃反而不容易凑够3个重复ACK。实验里严格保持DropTail队列是保证快速重传可复现的前提。5.3 曲线减半了但只有一次后面全是超时Reno的一个经典局限是同一窗口内多个丢包时恢复效率差。如果瓶颈队列设置了20个包的缓冲区而一个窗口内突然涌入超过20个包就会造成多个包同时被丢弃。Reno收到3个重复ACK后只恢复一个丢包其他丢包只能靠超时触发于是曲线表现为“减半一次紧接着掉回1”。这实际上是Reno机制的正确表现不算bug但会让实验图看起来不干净。想验证纯粹的Reno行为可以把瓶颈队列缓冲区设大一些使单次拥塞事件中只丢1到2个包比如队列长度20p、带宽1 Mbps、时延10ms发送窗口初始适中这种配置下大概率能看到漂亮的“减半-爬升-再减半”锯齿。另外可以在仿真脚本里适当降低接收端发送窗口的上限来减少突发性。5.4 排查链路总结我在帮同学排查这个问题时总结了一个顺序照着走基本都能定位看拓扑参数瓶颈链路是否真的存在带宽和时延是否设置正确看队列管理方式DropTail还是主动队列管理队列长度是否远大于BDP看TCP协议类型确认SocketType确实为TcpReno而不是默认的NewReno看SACK和延迟ACK是否关闭是否影响了重复ACK的触发看发送应用MaxBytes是否为0流量是否饱和看数据文件从第一次丢包时间点反查那一时刻的cwnd值对比是超时还是重复ACK触发。这套流程本身比实验结果更有价值。以后你换到BBR、Cubic或者Veno排查思路是一样的。6. 一点个人体会Reno之外的那些事这个实验做完后我对“默认值”这个词变得很敏感。教材里讲TCP演进往往一条线走下来但真实网络里算法选择和参数调优永远是跟场景绑定的。Reno简单所以适合教学Cubic、BBR鲁棒所以适合真实海量网络。实验报告的最后我写了一段总结把TCP拥塞控制机制抽象成的这些模块并不是互相替代的版本号而是在不同带宽、时延、丢包条件下的工程选择。如果学有余力可以让实验更完整一些把脚本里的SocketType改成TcpNewReno对比同一拓扑下两条曲线的差别或者改一下瓶颈队列长度看不同缓冲区下Reno的吞吐变化再进阶一步可以引入Veno或者Westwood观察它们在高丢包链路下的表现。这些都是在海大实验“reno版本”基础上自然延伸的方向。最后分享一个小技巧跑完实验后把cwnd数据文件保留好画图的时候不要只画一条线把ssthresh的变化曲线也画在同一张图上。这样可以看出每次快速恢复后ssthresh如何更新也方便回答实验指导书里“为什么拥塞避免阶段的斜率在不同周期内不一样”这类思考题。一张图两条线报告的说服力会提升不少。本文还有配套的精品资源点击获取