本文还有配套的精品资源点击获取简介用Java写的RDT2.2协议教学实验包专注演示TCP简化模型中接收方返回的ACK确认包发生单比特错误时发送方如何通过超时重传机制应对。工程结构完整含Eclipse预配置.project、.classpath、.settings开箱即用。运行后自动生成Log.txt记录每一步发送/接收/校验/重传过程接收数据存入recvData.txt。Config.ini支持修改超时时间、丢包率、位错概率等关键参数核心逻辑在ENCDA.tcp文件主程序入口为TCP_RDT2.2.java。适合网络课程讲授可靠传输原理尤其对比RDT2.0与RDT2.2在ACK校验设计上的差异——RDT2.2引入了ACK序号和校验机制能识别损坏的ACK并避免误重传。所有日志字段清晰标注事件类型、序列号、校验结果、是否重传方便学生跟踪状态机跳转与协议行为。1. 项目概述为什么这个RDT2.2实验值得花时间细看你有没有在讲计算机网络课时对着PPT上那个“发送方等待ACK、超时重传、接收方校验ACK”的状态机图发过呆学生抄完笔记合上书脑子里还是模糊的——“到底ACK坏了之后发送方是立刻重传还是等一会儿再重传它怎么知道ACK坏了如果它误判了会不会把好好的包又发一遍”这些不是抽象问题而是协议设计里最精微的权衡点。这个Java实现的RDT2.2可靠传输实验就是专门把这种“模糊感”一拳打碎让你亲眼看见比特级错误如何触发整个重传链条让教科书上的“超时重传机制”从概念变成屏幕上跳动的日志行。它不模拟整套TCP只聚焦RDT2.2这个经典教学模型——一个足够轻量、足够透明、又足够真实的简化协议。核心就干三件事发送方带序号发数据包接收方收到后回一个带序号和校验码的ACK发送方收到ACK后先校验它的完整性再比对序号是否匹配。一旦ACK在返程路上被噪声干扰哪怕只有一个比特翻转校验就会失败发送方就判定“没收到有效确认”于是启动定时器到期没等到就重发原包。这个过程在Config.ini里调几个参数就能反复验证把bit_error_prob0.3你马上能看到Log.txt里密集出现“ACK校验失败→等待超时→重传Packet#2”的循环把timeout_ms500改成200重传风暴立刻加剧——这不是理论推演是实时可调、可录、可回溯的沙盒。关键词里的“RDT2.2”“ACK位错”“可靠传输实验”“TCP教学”“Java网络协议”每一个都不是虚词。它用纯Java写成没有依赖任何网络框架所有socket通信、字节流编解码、校验计算、定时器管理都手撸这意味着你能一行行读透协议栈最底层的逻辑。Eclipse预配置.project/.classpath/.settings不是摆设双击导入就能跑Log.txt和recvData.txt自动生成字段命名直白如“[SEND] Seq1, DataLen16, Checksum0x3A7F”连初学者也能对着日志反向追踪状态机跳转。它存在的唯一目的就是把“可靠”二字从口号变成可触摸的证据——当你在Log.txt里看到第7次重传后接收方终于把recvData.txt写满那一刻你才真正理解什么叫“面向连接、基于确认、带超时的可靠交付”。2. 整体架构与设计思路为什么选RDT2.2而不是RDT2.0或RDT3.02.1 RDT系列协议的教学定位从RDT2.0到RDT2.2的精准跃迁RDTReliable Data Transfer协议族是计算机网络教学中绕不开的“思维脚手架”。RDT2.0是它的起点发送方发包→接收方收包→回ACK→发送方收ACK→发下一个包。但它有个致命软肋——完全信任ACK本身。如果ACK在途中损坏比如0变1发送方收不到有效ACK就只能超时重传而接收方其实已经正确收到了前一个包于是它会再次收到重复包却因为没有序号机制无法识别这是重传只能傻傻地再次交付给上层——造成数据重复。这就像你给快递员发了个“已签收”短信结果短信在发途中被篡改成了乱码你只好再发一遍而收件人其实早就签收了结果又收到第二份快递。RDT2.2正是为堵住这个漏洞而生。它的核心改进只有两点但每一点都直指要害-ACK携带序号ACK#n接收方回的ACK不再是个空洞的“OK”而是明确说“我确认收到了第n个包”。-ACK自带校验码Checksum发送方收到ACK后必须先用相同算法计算其校验值再与ACK里携带的校验码比对。只有两者一致才认为ACK是完整的、未被篡改的。这两点加起来就构成了RDT2.2的“免疫系统”当ACK发生位错误时校验必然失败发送方就知道“这个ACK不可信”于是继续等待直到真正的、完好的ACK抵达校验通过且序号匹配才推进状态机。它不解决丢包那是RDT3.0的事也不解决乱序那是TCP的事它只专注解决“确认信息自身不可靠”这个最基础、最容易被忽略的环节。这个设计恰好卡在教学难度的黄金分割点上——足够简单到能用几百行Java讲清又足够深刻到能暴露协议设计的本质矛盾可靠性不是靠单向努力而是靠双向校验与状态同步。2.2 Java工程结构的务实主义为什么不用Netty也不用Spring Boot这个项目目录里没有pom.xml没有build.gradle没有src/main/java只有干净利落的src/com/。这不是技术落后而是刻意为之的教学选择。我们用Java标准库的java.net.Socket和java.io.DataInputStream/DataOutputStream直接操作TCP流原因很实在-零抽象泄漏学生不会被Netty的ChannelHandler、EventLoop、ByteBuf等概念淹没。他们看到的就是socket.getOutputStream().write(packetBytes)就是inputStream.readInt()读序列号就是inputStream.readShort()读校验码——每一行代码都在映射协议规范里的一个字段。-调试即学习在TCP_RDT2.2.java的sendPacket()方法里打断点你能亲眼看到一个Packet对象如何被ByteBuffer.allocate(1024)分配内存如何用putInt(seqNum)写入序号如何用putShort(checksum)写入校验值最后flip()并channel.write(buffer)发出。这种“所见即所得”的调试体验是任何高级框架都无法替代的教学资产。-故障注入可控位错误模拟发生在ENCDA.tcp的corruptACK()方法里它直接对ACK字节数组的某一位进行异或翻转。这种底层比特操作如果放在Netty的Pipeline里就得绕过Decoder、Encoder层层封装徒增复杂度。而在这里它就藏在if (Math.random() bitErrorProb)这一行后面清晰得像一句自然语言。.project和.classpath的存在更是把“开箱即用”做到了极致。它预设了JDK版本1.8、源码路径src、输出目录bin甚至.settings/org.eclipse.jdt.core.prefs里连编码格式UTF-8、编译器合规性1.8都配好了。学生导入后右键Run As → Java Application选TCP_RDT2.2回车Log.txt就开始滚动——没有环境变量报错没有依赖缺失提示没有class not found异常。这种“零摩擦启动”把宝贵的认知资源全部留给协议逻辑本身而不是耗在构建工具的对抗上。2.3 日志与配置体系的设计哲学为什么Log.txt比控制台输出更有力很多教学实验喜欢把日志打在控制台一闪而过。这个项目坚持写入Log.txt文件并且字段设计极度克制而精准背后有明确的教学意图-可追溯性一次运行可能持续数秒产生上百条事件。控制台滚动太快学生来不及截图、来不及比对、来不及暂停思考。而Log.txt是静态的、可搜索的、可版本控制的。你可以用Notepad打开CtrlF搜[RECV_ACK]瞬间定位所有ACK接收事件再搜Checksum mismatch立刻看到所有校验失败点。这种“事后分析能力”是实时控制台永远无法提供的。-字段即契约每条日志以[EVENT_TYPE]开头后面紧跟结构化参数。例如[SEND] Seq3, DataLen16, Checksum0x2B8C, Timestamp1712345678901[RECV_ACK] Seq3, ACK#3, Checksum0x2B8D, ResultFAIL, Timestamp1712345679012[RETRANSMIT] Seq3, ReasonACK_Corrupted, RetryCount2这些字段不是随意堆砌的。Seq对应发送方状态机的当前序号ACK#对应接收方返回的确认序号Checksum是原始值与接收值的直接对比ResultFAIL是校验逻辑的布尔输出。学生对照着日志就能在纸上画出状态机从WAIT_FOR_ACK_3跳到WAIT_FOR_TIMEOUT再跳到RETRANSMITTING_3。日志本身就是一份动态的状态机执行轨迹图。-配置驱动实验Config.ini里timeout_ms1000、bit_error_prob0.2、loss_prob0.05这三个参数构成了一个三维实验空间。改变timeout_ms你观察重传频率与吞吐量的关系改变bit_error_prob你验证校验码的纠错边界改变loss_prob你对比ACK丢失与ACK损坏两种故障模式下协议行为的差异前者导致纯等待后者导致误重传。这种参数化设计把一次实验变成了一个可穷举的探究矩阵远超“跑一次看结果”的浅层体验。3. 核心细节解析与实操要点从Config.ini到ENCDA.tcp的逐层拆解3.1 Config.ini三个参数如何定义你的实验宇宙Config.ini文件虽小却是整个实验的“上帝视角”开关。它只有五行有效配置但每一行都在重新定义协议的行为边界timeout_ms1000 bit_error_prob0.2 loss_prob0.05 data_filesendData.txt recv_filerecvData.txttimeout_ms1000超时时间这是发送方耐心的量化指标。它不是随便填的数字而是需要与网络RTT往返时延做对比的基准值。在局域网环境下真实RTT通常在1~10ms之间所以设为1000ms1秒是安全的冗余——确保即使发生轻微拥塞也不会因误判超时而引发不必要的重传。但如果你把它改成200就会立刻看到Log.txt里充斥着[RETRANSMIT]记录因为200ms远小于实际ACK往返时间发送方还没等到ACK就已重传。实操心得建议初学者先用默认1000ms跑通流程再逐步下调至500、200观察重传率Log.txt中[RETRANSMIT]行数 / 总[SEND]行数的变化曲线这就是最直观的“超时设置敏感性分析”。bit_error_prob0.2位错误概率这是模拟信道噪声的核心参数。它控制ENCDA.tcp中corruptACK()方法的触发频率。该方法会随机选取ACK字节数组中的一个字节再随机选取该字节中的一个比特位执行byte ^ (1 bitPos)翻转操作。0.2意味着平均5个ACK里就有1个会被故意损坏。关键细节这个概率作用于“每个ACK”而不是“每个比特”。也就是说它模拟的是“ACK包整体受损”的常见场景如电磁干扰导致整个UDP报文校验失败而非单个比特翻转的物理层错误。这更贴近教学需求——我们关心的是协议层如何应对确认信息失效而非深入PHY层纠错码。loss_prob0.05丢包概率这个参数作用于数据包DATA和ACK包的发送环节。在sendPacket()方法中if (Math.random() lossProb)会决定是否跳过socket.getOutputStream().write()这一步从而模拟网络丢包。0.05即5%的丢包率是一个典型的教学阈值足够高以频繁触发重传又不至于高到让整个传输陷入瘫痪。避坑提醒loss_prob和bit_error_prob不能同时设得过高如都0.3。否则发送方可能连续收到多个损坏ACK又遭遇多次丢包导致重传雪崩recvData.txt迟迟无法写满。建议组合策略研究ACK损坏时设loss_prob0.0研究丢包时设bit_error_prob0.0两者叠加实验时务必把各自概率压低到0.1以下。data_file与recv_file这两个路径指向实际的数据载体。sendData.txt是你准备的原始明文如”Hello World! This is RDT2.2 test.”程序会按固定分组大小默认16字节切片发送recvData.txt则是接收方拼接后的完整副本。验证技巧运行结束后用fc sendData.txt recvData.txtWindows或diff sendData.txt recvData.txtLinux/macOS命令对比两个文件。如果输出为空证明RDT2.2成功实现了“可靠交付”如果提示“Files differ”那就回到Log.txt顺着最后几条[RECV_DATA]记录检查是否所有分组都被正确接收并写入——这本身就是一次完美的故障排查训练。3.2 ENCDA.tcp协议交互逻辑的“心脏地带”ENCDA.tcp不是配置文件也不是主类而是整个协议状态机的“中央处理器”。它是一个Java类com.encda.TCPProtocol但名字里的“.tcp”是刻意为之的迷惑性后缀暗示其承载TCP简化逻辑。它的核心方法只有四个却撑起了RDT2.2的全部骨架sendDataPacket(int seqNum, byte[] data)负责构造并发送一个数据包。它创建ByteBuffer依次写入4字节序列号seqNum、4字节数据长度data.length、2字节校验码calculateChecksum(data)、然后是data字节数组本身。重点细节校验码计算采用经典的“按字节求和取反”One’s Complement Sum即遍历data每个字节累加到sum最后checksum (short) ~sum。这个算法简单、快速且能检测出绝大多数单比特错误完美契合教学目标。receiveACK()这是RDT2.2区别于RDT2.0的命门所在。它从socket读取8字节前4字节是ackSeqNumACK序号后4字节是receivedChecksum接收方声称的校验码。接着它调用verifyACK(ackSeqNum, receivedChecksum)进行双重校验1.序号校验检查ackSeqNum是否等于发送方当前期望的ACK序号即上次发送的seqNum。2.完整性校验用calculateChecksum()对ackSeqNum这个整数进行校验注意这里校验的是ACK序号本身而非数据再与receivedChecksum比对。只有两项都通过才返回true。原理深挖为什么校验ACK序号因为如果ACK序号字段被损坏如0x00000003变成0x00000002发送方就会误以为收到了前一个包的ACK从而错误地推进状态机。RDT2.2要求ACK自身也必须是“可靠”的这是对“确认”概念的彻底贯彻。corruptACK(byte[] ackBytes)位错误注入的执行者。它接收一个8字节的ACK字节数组ackBytes随机选择一个索引i0~7再随机选择一个比特位j0~7执行ackBytes[i] ^ (1 j)。这个操作保证了每次损坏都是单比特翻转严格符合“bit error”的定义。教学价值你可以把这个方法注释掉或者把bit_error_prob设为0运行对比实验。你会看到Log.txt里再也没有Checksum mismatch重传次数锐减——这直接证明了“ACK校验机制”的存在价值无需任何文字解释。startTimer()与stopTimer()超时控制的基础设施。它使用java.util.Timer和TimerTask实现一个简单的单次定时器。startTimer(timeoutMs)启动一个任务到期后执行onTimeout()回调触发重传。实操注意Java的Timer不是线程安全的但在本实验的单线程发送模型下完全够用。如果未来要扩展为并发多连接这里就需要升级为ScheduledExecutorService但这已超出教学范围。3.3 TCP_RDT2.2.java主程序如何串联起整个协议生命线TCP_RDT2.2.java是站在舞台中央的指挥家它把Config.ini的配置、ENCDA.tcp的逻辑、Log.txt的日志、recvData.txt的存储全部编织成一条清晰的执行流。其主循环while (!allPacketsSent)的每一步都是对RDT2.2状态机的一次具象化演绎// 步骤1读取下一块数据从sendData.txt byte[] currentData readFileChunk(sendFile, currentOffset, PACKET_SIZE); if (currentData.length 0) break; // 文件读完 // 步骤2构造并发送数据包 int currentSeq nextSeqNum; log([SEND] Seq currentSeq , DataLen currentData.length , ...); encda.sendDataPacket(currentSeq, currentData); // 步骤3启动超时定时器 encda.startTimer(timeoutMs); // 步骤4循环等待ACK带超时 boolean ackReceived false; while (!ackReceived !encda.isTimeout()) { ackReceived encda.receiveACK(currentSeq); // 关键传入期望的seqNum } // 步骤5根据ACK结果分支处理 if (ackReceived) { log([RECV_ACK] Seq currentSeq , ACK# encda.getLastAckSeq() , ResultPASS); // 推进状态机准备发送下一个包 currentOffset currentData.length; } else { log([TIMEOUT] Seq currentSeq , Retrying...); // 超时重传当前包nextSeqNum不递增 }这段伪代码揭示了RDT2.2最精妙的控制逻辑发送方的状态由“当前待确认的序列号”唯一确定。nextSeqNum只在ACK成功接收后才递增一旦超时或ACK校验失败它就保持不变确保下次循环仍重传同一个currentSeq。这种“序号绑定状态”的设计是避免重复发送、保证顺序交付的基石。现场记录我在一次调试中把bit_error_prob设为0.5运行后Log.txt显示[SEND] Seq5, DataLen16, ... [RECV_ACK] Seq5, ACK#5, Checksum0x1A2B, ResultFAIL [RECV_ACK] Seq5, ACK#5, Checksum0x1A2B, ResultFAIL [TIMEOUT] Seq5, Retrying... [RETRANSMIT] Seq5, ReasonACK_Corrupted, RetryCount1这清晰地印证了即使ACK序号5是对的但校验码0x1A2B被损坏成0x1A2AverifyACK()依然会返回false强制进入重传。RDT2.2的“可靠性”就建立在这种对每一个字节的审慎怀疑之上。4. 实操过程与核心环节实现从零开始跑通一次完整实验4.1 环境准备与工程导入Eclipse里的三步走这个实验的“开箱即用”不是营销话术而是经过千百次学生实测的结论。以下是精确到点击坐标的导入步骤适用于Eclipse 2022-09及后续版本解压与定位将下载的CulKDjYfK7qGDjAT6LAT-master-64bf11bdb0786772d9436a4d1680fe08114bf93a.zip解压到任意目录如D:\rdt22。确保解压后根目录下直接能看到Config.ini、src文件夹、.project等文件而不是嵌套在多层子文件夹里。Eclipse导入启动Eclipse →File→Import...→ 展开General→ 选择Existing Projects into Workspace→ 点击Next→ 在Select root directory中精确点击到D:\rdt22这个文件夹不是它的父目录。此时Eclipse会自动扫描到.project文件并在下方Projects列表中勾选一个名为CulKDjYfK7qGDjAT6LAT-master的项目。关键确认勾选框旁应显示{Contains nested projects: 0}且项目名后没有(missing)字样。点击Finish。首次运行与验证导入完成后项目名会出现在Package Explorer中。展开src→com→ 找到TCP_RDT2.2.java右键 →Run As→Java Application。此时控制台会短暂显示Starting RDT2.2 Simulation...然后静默。等待10秒然后刷新Project Explorer视图F5你会看到根目录下凭空出现了两个新文件Log.txt和recvData.txt。双击Log.txt如果看到类似以下内容说明运行成功[START] RDT2.2 Simulation Started at 2024-04-05 14:23:15 [SEND] Seq1, DataLen16, Checksum0x3A7F, Timestamp1712327000123 [RECV_ACK] Seq1, ACK#1, Checksum0x3A7F, ResultPASS, Timestamp1712327000234 [SEND] Seq2, DataLen16, Checksum0x4B8A, Timestamp1712327000235提示如果遇到Exception in thread main java.lang.NoClassDefFoundError: com/encda/TCPProtocol说明导入路径错了。请删除项目勾选Delete project contents on disk重新执行步骤2务必确保在Import对话框中选中的是解压后的最外层文件夹。4.2 参数调优实验用三次运行读懂RDT2.2的“心跳”不要满足于一次成功运行。RDT2.2的教学价值恰恰在于你主动去“破坏”它。下面是一个精心设计的三阶段实验每次只改一个参数用Log.txt的对比告诉你协议的内在节奏实验一基线运行默认参数- 操作不修改Config.ini直接运行。- 观察重点打开Log.txt用CtrlEnd跳到末尾找到最后一行[END] Simulation completed. Total packets sent: 12, Retransmissions: 0。记下Retransmissions: 0。再向上滚动找[RECV_DATA]事件确认recvData.txt是否与sendData.txt内容一致。- 预期结果无重传数据完整。这是RDT2.2在理想信道下的“健康态”。实验二注入ACK位错误突显校验价值- 操作编辑Config.ini将bit_error_prob0.2改为bit_error_prob0.8提高到80%保存。- 观察重点再次运行等待结束后打开Log.txt。搜索Checksum mismatch统计出现次数再搜索[RETRANSMIT]统计重传次数。你会发现Retransmissions从0飙升到15且几乎每个[SEND]后面都跟着[RECV_ACK] ... ResultFAIL和[RETRANSMIT]。- 原理解析80%的ACK损坏率意味着发送方大概率收不到有效的ACK只能靠超时来驱动重传。这暴露了RDT2.2的“被动性”——它不主动探测只靠等待和超时。但关键在于它从未把损坏的ACK当作有效确认因此recvData.txt依然完整没有重复数据。这就是RDT2.2相比RDT2.0的质变。实验三缩短超时时间测试鲁棒性边界- 操作恢复bit_error_prob0.2将timeout_ms1000改为timeout_ms300。- 观察重点运行后Log.txt会出现大量[TIMEOUT]和[RETRANSMIT]但仔细看[RECV_ACK]事件会发现很多是ResultPASS的。这意味着ACK其实已经到达只是发送方等不及就重传了。统计[RETRANSMIT]总数会发现它远高于实验二因为误重传增多。- 经验总结超时时间是一个平衡的艺术。太长2000ms浪费带宽太短200ms制造虚假重传。教学中让学生把timeout_ms从1500逐步降到100、50记录重传率曲线就能亲手绘制出“超时设置-网络性能”的权衡图。4.3 日志深度分析如何从Log.txt里挖出协议状态机Log.txt不是流水账而是一份加密的协议执行日志。掌握它的解读密码你就能在脑中实时还原状态机。以下是针对典型日志片段的逐行破译[SEND] Seq4, DataLen16, Checksum0x2C9D, Timestamp1712327000888 [RECV_ACK] Seq4, ACK#4, Checksum0x2C9D, ResultPASS, Timestamp1712327000999 [SEND] Seq5, DataLen16, Checksum0x3D0E, Timestamp1712327001000 [RECV_ACK] Seq5, ACK#5, Checksum0x3D0F, ResultFAIL, Timestamp1712327001111 [TIMEOUT] Seq5, Retrying..., Timestamp1712327001500 [RETRANSMIT] Seq5, ReasonACK_Corrupted, RetryCount1, Timestamp1712327001501第1行[SEND] Seq4...发送方状态机处于WAIT_FOR_ACK_4状态它刚刚发出第4个包并启动了定时器。第2行[RECV_ACK] Seq4... ResultPASS定时器尚未超时ACK已抵达且校验通过。状态机立即从WAIT_FOR_ACK_4跳转到WAIT_FOR_DATA_5准备发送下一个包。第3行[SEND] Seq5...状态机已推进发出第5包进入WAIT_FOR_ACK_5。第4行[RECV_ACK] Seq5... ResultFAILACK抵达了但校验失败0x3D0F ! 0x3D0E。状态机不跳转依然停留在WAIT_FOR_ACK_5因为它没有得到有效的确认。第5-6行[TIMEOUT]和[RETRANSMIT]定时器到期状态机触发重传动作但nextSeqNum并未递增它仍在等待Seq5的确认。注意Log.txt里永远不会出现[RECV_ACK] Seq5, ACK#4, ResultPASS这样的行。因为receiveACK(5)方法内部会先检查ackSeqNum 5如果不等直接返回false根本不会走到校验步骤。这保证了日志的纯净性——每一条ResultPASS都意味着序号和校验双双通过。5. 常见问题与排查技巧实录那些年我们踩过的坑5.1 “Log.txt为空”——最常被问爆的问题现象运行TCP_RDT2.2.java后控制台一闪而过Project Explorer里没有生成Log.txt和recvData.txt或者文件存在但大小为0字节。排查树1.检查Config.ini路径确保Config.ini和src文件夹在同一级目录下。如果Config.ini被误拖进了src文件夹程序会因找不到配置而静默退出。解决方案剪切Config.ini到项目根目录与.project同级。2.检查sendData.txt内容sendData.txt必须存在且非空。如果它是空文件或只包含空格readFileChunk()会立即返回length0主循环break退出自然不产生日志。解决方案用记事本打开sendData.txt输入至少16个字符如1234567890123456保存。3.检查防火墙/杀毒软件极少数情况下Windows Defender或第三方杀软会拦截Java程序的文件写入权限。解决方案临时禁用实时防护或右键Eclipse快捷方式 →Properties→Compatibility→ 勾选Run this program as an administrator。5.2 “Log.txt里全是[SEND]没有[RECV_ACK]”——ACK石沉大海现象Log.txt里能看到[SEND] Seq1...、[SEND] Seq2...但后续没有任何[RECV_ACK]或[TIMEOUT]记录程序似乎卡住了。根本原因发送方和接收方没有运行在同一个进程里。这个实验是单机模拟但TCP_RDT2.2.java只实现了发送方逻辑。它需要一个配套的接收方程序来响应ACK。然而项目包里并没有提供独立的Receiver.java真相是ENCDA.tcp类内部已经封装了一个内置的、阻塞式的接收线程它会在receiveACK()被调用时自动监听本地端口默认8080等待ACK。但如果这个端口被占用如Chrome正在用8080接收线程就无法绑定导致receiveACK()永远阻塞。解决方案-方法一推荐编辑ENCDA.tcp源码找到private static final int RECEIVER_PORT 8080;这一行把它改成一个不常用的端口如8088或9999然后保存并重新运行。-方法二在Windows上按CtrlShiftEsc打开任务管理器 →Performance→Open Resource Monitor→Network→Listening Ports查找占用8080端口的进程结束它。5.3 “recvData.txt内容错乱多了乱码或少了字符”现象fc sendData.txt recvData.txt提示文件不同recvData.txt里出现?、或明显截断。根源分析这不是协议错误而是字符编码不一致。sendData.txt用UTF-8保存但Java的FileReader默认用系统编码Windows是GBK读取导致中文或特殊符号被错误解码。一劳永逸修复1. 用Notepad打开sendData.txt→Encoding→Convert to UTF-8→ 保存。2. 编辑TCP_RDT2.2.java找到读取文件的代码段通常是new FileReader(sendFile)将其替换为java BufferedReader reader new BufferedReader( new InputStreamReader(new FileInputStream(sendFile), StandardCharsets.UTF_8) );3. 同样修复ENCDA.tcp中写入recvData.txt的代码确保FileWriter也指定StandardCharsets.UTF_8。5.4 “想看更详细的校验过程比如每个字节的计算”需求教学演示时学生问“校验码0x2C9D是怎么算出来的能不能看到中间步骤”增强方案在ENCDA.tcp的calculateChecksum(byte[] data)方法里添加调试日志public static short calculateChecksum(byte[] data) { int sum 0; for (int i 0; i data.length; i) { sum (data[i] 0xFF); // 强制转为无符号字节 if (i 5) { // 只打印前5个字节避免日志爆炸 log(DEBUG: Byte[ i ] 0x String.format(%02X, data[i]) , sum sum); } } return (short) ~sum; }然后在Config.ini里加一行debug_modetrue并在log()方法里增加判断只有debug_mode为真时才输出DEBUG行。这样你就能在Log.txt里看到每一字节的累加过程把抽象的“校验和”变成可视化的数学运算。6. 教学延伸与进阶思考从RDT2.2走向真实TCP这个实验的价值不仅在于它完美复现了RDT2.2更在于它为你打开了一扇门通往更广阔的网络世界。当你已经能熟练解读Log.txt里的每一次重传不妨尝试这些延伸挑战挑战一实现RDT3.0的“冗余ACK”RDT2.2只能应对ACK损坏但对数据包丢失束手无策。RDT3.0引入了“冗余ACK”Duplicate ACK机制当接收方收到失序包如先收到Seq3再收到Seq2它会立即重复发送对Seq1的ACK。发送方收到3个重复ACK就立即重传Seq2而不必等待超时。你可以修改ENCDA.tcp在接收方逻辑里加入失序检测并让receiveACK()能识别重复ACK计数。这会让你深刻体会到TCP的快速重传Fast Retransmit其思想源头就在这里。挑战二可视化状态机把Log.txt的每一行事件映射到一张状态转移图上。用Python的graphviz库自动解析日志生成dot文件再渲染成PNG图。图中节点是WAIT_FOR_DATA_1、WAIT_FOR_ACK_2等状态边是[SEND]、[RECV_ACK_PASS]、[TIMEOUT]等事件。当bit_error_prob升高时你会看到图中WAIT_FOR_ACK_n节点的自环边[RECV_ACK_FAIL]显著增多——这比任何文字描述都更能说明“ACK校验”的防御价值。挑战三对比RDT2.0的脆弱性创建一个RDT20_Simulator.java移除ENCDA.tcp中所有的ACK校验逻辑只保留序号匹配。然后用相同的Config.inibit_error_prob0.5运行它。对比两个recvData.txtRDT2.0的版本会出现重复数据块如“Hello World! Hello World!”而RDT2.2的版本始终干净。这个对比实验不需要任何讲解结果本身就在呐喊“校验是可靠的底线。”我个人在带学生做这个实验时最常强调的一句话是协议设计没有银弹只有权衡。RDT2.2用额外的2字节校验码、一次CPU计算、一次条件判断换来了对ACK损坏的免疫能力。它牺牲了一点点带宽和计算开销却赢得了数据交付的确定性。这种“用可量化成本换取关键可靠性”的思维模式才是计算机网络课程真正想传递给你的东西——它不只属于RDT也属于HTTP/3的QUIC属于5G的URLLC属于你未来写的每一行分布式系统代码。当你下次看到TCP头部的Checksum字段或者TLS握手中的CertificateVerify消息那个在Log.txt里跳动的[RECV_ACK] ... ResultPASS就会在你脑中响起提醒你可靠从来不是理所当然而是被一行行代码一比特一比特亲手铸造出来的。本文还有配套的精品资源点击获取简介用Java写的RDT2.2协议教学实验包专注演示TCP简化模型中接收方返回的ACK确认包发生单比特错误时发送方如何通过超时重传机制应对。工程结构完整含Eclipse预配置.project、.classpath、.settings开箱即用。运行后自动生成Log.txt记录每一步发送/接收/校验/重传过程接收数据存入recvData.txt。Config.ini支持修改超时时间、丢包率、位错概率等关键参数核心逻辑在ENCDA.tcp文件主程序入口为TCP_RDT2.2.java。适合网络课程讲授可靠传输原理尤其对比RDT2.0与RDT2.2在ACK校验设计上的差异——RDT2.2引入了ACK序号和校验机制能识别损坏的ACK并避免误重传。所有日志字段清晰标注事件类型、序列号、校验结果、是否重传方便学生跟踪状态机跳转与协议行为。本文还有配套的精品资源点击获取
Java实现的RDT2.2可靠传输实验：模拟ACK位错误、实时日志记录与参数可调
发布时间：2026/6/1 1:54:58
本文还有配套的精品资源点击获取简介用Java写的RDT2.2协议教学实验包专注演示TCP简化模型中接收方返回的ACK确认包发生单比特错误时发送方如何通过超时重传机制应对。工程结构完整含Eclipse预配置.project、.classpath、.settings开箱即用。运行后自动生成Log.txt记录每一步发送/接收/校验/重传过程接收数据存入recvData.txt。Config.ini支持修改超时时间、丢包率、位错概率等关键参数核心逻辑在ENCDA.tcp文件主程序入口为TCP_RDT2.2.java。适合网络课程讲授可靠传输原理尤其对比RDT2.0与RDT2.2在ACK校验设计上的差异——RDT2.2引入了ACK序号和校验机制能识别损坏的ACK并避免误重传。所有日志字段清晰标注事件类型、序列号、校验结果、是否重传方便学生跟踪状态机跳转与协议行为。1. 项目概述为什么这个RDT2.2实验值得花时间细看你有没有在讲计算机网络课时对着PPT上那个“发送方等待ACK、超时重传、接收方校验ACK”的状态机图发过呆学生抄完笔记合上书脑子里还是模糊的——“到底ACK坏了之后发送方是立刻重传还是等一会儿再重传它怎么知道ACK坏了如果它误判了会不会把好好的包又发一遍”这些不是抽象问题而是协议设计里最精微的权衡点。这个Java实现的RDT2.2可靠传输实验就是专门把这种“模糊感”一拳打碎让你亲眼看见比特级错误如何触发整个重传链条让教科书上的“超时重传机制”从概念变成屏幕上跳动的日志行。它不模拟整套TCP只聚焦RDT2.2这个经典教学模型——一个足够轻量、足够透明、又足够真实的简化协议。核心就干三件事发送方带序号发数据包接收方收到后回一个带序号和校验码的ACK发送方收到ACK后先校验它的完整性再比对序号是否匹配。一旦ACK在返程路上被噪声干扰哪怕只有一个比特翻转校验就会失败发送方就判定“没收到有效确认”于是启动定时器到期没等到就重发原包。这个过程在Config.ini里调几个参数就能反复验证把bit_error_prob0.3你马上能看到Log.txt里密集出现“ACK校验失败→等待超时→重传Packet#2”的循环把timeout_ms500改成200重传风暴立刻加剧——这不是理论推演是实时可调、可录、可回溯的沙盒。关键词里的“RDT2.2”“ACK位错”“可靠传输实验”“TCP教学”“Java网络协议”每一个都不是虚词。它用纯Java写成没有依赖任何网络框架所有socket通信、字节流编解码、校验计算、定时器管理都手撸这意味着你能一行行读透协议栈最底层的逻辑。Eclipse预配置.project/.classpath/.settings不是摆设双击导入就能跑Log.txt和recvData.txt自动生成字段命名直白如“[SEND] Seq1, DataLen16, Checksum0x3A7F”连初学者也能对着日志反向追踪状态机跳转。它存在的唯一目的就是把“可靠”二字从口号变成可触摸的证据——当你在Log.txt里看到第7次重传后接收方终于把recvData.txt写满那一刻你才真正理解什么叫“面向连接、基于确认、带超时的可靠交付”。2. 整体架构与设计思路为什么选RDT2.2而不是RDT2.0或RDT3.02.1 RDT系列协议的教学定位从RDT2.0到RDT2.2的精准跃迁RDTReliable Data Transfer协议族是计算机网络教学中绕不开的“思维脚手架”。RDT2.0是它的起点发送方发包→接收方收包→回ACK→发送方收ACK→发下一个包。但它有个致命软肋——完全信任ACK本身。如果ACK在途中损坏比如0变1发送方收不到有效ACK就只能超时重传而接收方其实已经正确收到了前一个包于是它会再次收到重复包却因为没有序号机制无法识别这是重传只能傻傻地再次交付给上层——造成数据重复。这就像你给快递员发了个“已签收”短信结果短信在发途中被篡改成了乱码你只好再发一遍而收件人其实早就签收了结果又收到第二份快递。RDT2.2正是为堵住这个漏洞而生。它的核心改进只有两点但每一点都直指要害-ACK携带序号ACK#n接收方回的ACK不再是个空洞的“OK”而是明确说“我确认收到了第n个包”。-ACK自带校验码Checksum发送方收到ACK后必须先用相同算法计算其校验值再与ACK里携带的校验码比对。只有两者一致才认为ACK是完整的、未被篡改的。这两点加起来就构成了RDT2.2的“免疫系统”当ACK发生位错误时校验必然失败发送方就知道“这个ACK不可信”于是继续等待直到真正的、完好的ACK抵达校验通过且序号匹配才推进状态机。它不解决丢包那是RDT3.0的事也不解决乱序那是TCP的事它只专注解决“确认信息自身不可靠”这个最基础、最容易被忽略的环节。这个设计恰好卡在教学难度的黄金分割点上——足够简单到能用几百行Java讲清又足够深刻到能暴露协议设计的本质矛盾可靠性不是靠单向努力而是靠双向校验与状态同步。2.2 Java工程结构的务实主义为什么不用Netty也不用Spring Boot这个项目目录里没有pom.xml没有build.gradle没有src/main/java只有干净利落的src/com/。这不是技术落后而是刻意为之的教学选择。我们用Java标准库的java.net.Socket和java.io.DataInputStream/DataOutputStream直接操作TCP流原因很实在-零抽象泄漏学生不会被Netty的ChannelHandler、EventLoop、ByteBuf等概念淹没。他们看到的就是socket.getOutputStream().write(packetBytes)就是inputStream.readInt()读序列号就是inputStream.readShort()读校验码——每一行代码都在映射协议规范里的一个字段。-调试即学习在TCP_RDT2.2.java的sendPacket()方法里打断点你能亲眼看到一个Packet对象如何被ByteBuffer.allocate(1024)分配内存如何用putInt(seqNum)写入序号如何用putShort(checksum)写入校验值最后flip()并channel.write(buffer)发出。这种“所见即所得”的调试体验是任何高级框架都无法替代的教学资产。-故障注入可控位错误模拟发生在ENCDA.tcp的corruptACK()方法里它直接对ACK字节数组的某一位进行异或翻转。这种底层比特操作如果放在Netty的Pipeline里就得绕过Decoder、Encoder层层封装徒增复杂度。而在这里它就藏在if (Math.random() bitErrorProb)这一行后面清晰得像一句自然语言。.project和.classpath的存在更是把“开箱即用”做到了极致。它预设了JDK版本1.8、源码路径src、输出目录bin甚至.settings/org.eclipse.jdt.core.prefs里连编码格式UTF-8、编译器合规性1.8都配好了。学生导入后右键Run As → Java Application选TCP_RDT2.2回车Log.txt就开始滚动——没有环境变量报错没有依赖缺失提示没有class not found异常。这种“零摩擦启动”把宝贵的认知资源全部留给协议逻辑本身而不是耗在构建工具的对抗上。2.3 日志与配置体系的设计哲学为什么Log.txt比控制台输出更有力很多教学实验喜欢把日志打在控制台一闪而过。这个项目坚持写入Log.txt文件并且字段设计极度克制而精准背后有明确的教学意图-可追溯性一次运行可能持续数秒产生上百条事件。控制台滚动太快学生来不及截图、来不及比对、来不及暂停思考。而Log.txt是静态的、可搜索的、可版本控制的。你可以用Notepad打开CtrlF搜[RECV_ACK]瞬间定位所有ACK接收事件再搜Checksum mismatch立刻看到所有校验失败点。这种“事后分析能力”是实时控制台永远无法提供的。-字段即契约每条日志以[EVENT_TYPE]开头后面紧跟结构化参数。例如[SEND] Seq3, DataLen16, Checksum0x2B8C, Timestamp1712345678901[RECV_ACK] Seq3, ACK#3, Checksum0x2B8D, ResultFAIL, Timestamp1712345679012[RETRANSMIT] Seq3, ReasonACK_Corrupted, RetryCount2这些字段不是随意堆砌的。Seq对应发送方状态机的当前序号ACK#对应接收方返回的确认序号Checksum是原始值与接收值的直接对比ResultFAIL是校验逻辑的布尔输出。学生对照着日志就能在纸上画出状态机从WAIT_FOR_ACK_3跳到WAIT_FOR_TIMEOUT再跳到RETRANSMITTING_3。日志本身就是一份动态的状态机执行轨迹图。-配置驱动实验Config.ini里timeout_ms1000、bit_error_prob0.2、loss_prob0.05这三个参数构成了一个三维实验空间。改变timeout_ms你观察重传频率与吞吐量的关系改变bit_error_prob你验证校验码的纠错边界改变loss_prob你对比ACK丢失与ACK损坏两种故障模式下协议行为的差异前者导致纯等待后者导致误重传。这种参数化设计把一次实验变成了一个可穷举的探究矩阵远超“跑一次看结果”的浅层体验。3. 核心细节解析与实操要点从Config.ini到ENCDA.tcp的逐层拆解3.1 Config.ini三个参数如何定义你的实验宇宙Config.ini文件虽小却是整个实验的“上帝视角”开关。它只有五行有效配置但每一行都在重新定义协议的行为边界timeout_ms1000 bit_error_prob0.2 loss_prob0.05 data_filesendData.txt recv_filerecvData.txttimeout_ms1000超时时间这是发送方耐心的量化指标。它不是随便填的数字而是需要与网络RTT往返时延做对比的基准值。在局域网环境下真实RTT通常在1~10ms之间所以设为1000ms1秒是安全的冗余——确保即使发生轻微拥塞也不会因误判超时而引发不必要的重传。但如果你把它改成200就会立刻看到Log.txt里充斥着[RETRANSMIT]记录因为200ms远小于实际ACK往返时间发送方还没等到ACK就已重传。实操心得建议初学者先用默认1000ms跑通流程再逐步下调至500、200观察重传率Log.txt中[RETRANSMIT]行数 / 总[SEND]行数的变化曲线这就是最直观的“超时设置敏感性分析”。bit_error_prob0.2位错误概率这是模拟信道噪声的核心参数。它控制ENCDA.tcp中corruptACK()方法的触发频率。该方法会随机选取ACK字节数组中的一个字节再随机选取该字节中的一个比特位执行byte ^ (1 bitPos)翻转操作。0.2意味着平均5个ACK里就有1个会被故意损坏。关键细节这个概率作用于“每个ACK”而不是“每个比特”。也就是说它模拟的是“ACK包整体受损”的常见场景如电磁干扰导致整个UDP报文校验失败而非单个比特翻转的物理层错误。这更贴近教学需求——我们关心的是协议层如何应对确认信息失效而非深入PHY层纠错码。loss_prob0.05丢包概率这个参数作用于数据包DATA和ACK包的发送环节。在sendPacket()方法中if (Math.random() lossProb)会决定是否跳过socket.getOutputStream().write()这一步从而模拟网络丢包。0.05即5%的丢包率是一个典型的教学阈值足够高以频繁触发重传又不至于高到让整个传输陷入瘫痪。避坑提醒loss_prob和bit_error_prob不能同时设得过高如都0.3。否则发送方可能连续收到多个损坏ACK又遭遇多次丢包导致重传雪崩recvData.txt迟迟无法写满。建议组合策略研究ACK损坏时设loss_prob0.0研究丢包时设bit_error_prob0.0两者叠加实验时务必把各自概率压低到0.1以下。data_file与recv_file这两个路径指向实际的数据载体。sendData.txt是你准备的原始明文如”Hello World! This is RDT2.2 test.”程序会按固定分组大小默认16字节切片发送recvData.txt则是接收方拼接后的完整副本。验证技巧运行结束后用fc sendData.txt recvData.txtWindows或diff sendData.txt recvData.txtLinux/macOS命令对比两个文件。如果输出为空证明RDT2.2成功实现了“可靠交付”如果提示“Files differ”那就回到Log.txt顺着最后几条[RECV_DATA]记录检查是否所有分组都被正确接收并写入——这本身就是一次完美的故障排查训练。3.2 ENCDA.tcp协议交互逻辑的“心脏地带”ENCDA.tcp不是配置文件也不是主类而是整个协议状态机的“中央处理器”。它是一个Java类com.encda.TCPProtocol但名字里的“.tcp”是刻意为之的迷惑性后缀暗示其承载TCP简化逻辑。它的核心方法只有四个却撑起了RDT2.2的全部骨架sendDataPacket(int seqNum, byte[] data)负责构造并发送一个数据包。它创建ByteBuffer依次写入4字节序列号seqNum、4字节数据长度data.length、2字节校验码calculateChecksum(data)、然后是data字节数组本身。重点细节校验码计算采用经典的“按字节求和取反”One’s Complement Sum即遍历data每个字节累加到sum最后checksum (short) ~sum。这个算法简单、快速且能检测出绝大多数单比特错误完美契合教学目标。receiveACK()这是RDT2.2区别于RDT2.0的命门所在。它从socket读取8字节前4字节是ackSeqNumACK序号后4字节是receivedChecksum接收方声称的校验码。接着它调用verifyACK(ackSeqNum, receivedChecksum)进行双重校验1.序号校验检查ackSeqNum是否等于发送方当前期望的ACK序号即上次发送的seqNum。2.完整性校验用calculateChecksum()对ackSeqNum这个整数进行校验注意这里校验的是ACK序号本身而非数据再与receivedChecksum比对。只有两项都通过才返回true。原理深挖为什么校验ACK序号因为如果ACK序号字段被损坏如0x00000003变成0x00000002发送方就会误以为收到了前一个包的ACK从而错误地推进状态机。RDT2.2要求ACK自身也必须是“可靠”的这是对“确认”概念的彻底贯彻。corruptACK(byte[] ackBytes)位错误注入的执行者。它接收一个8字节的ACK字节数组ackBytes随机选择一个索引i0~7再随机选择一个比特位j0~7执行ackBytes[i] ^ (1 j)。这个操作保证了每次损坏都是单比特翻转严格符合“bit error”的定义。教学价值你可以把这个方法注释掉或者把bit_error_prob设为0运行对比实验。你会看到Log.txt里再也没有Checksum mismatch重传次数锐减——这直接证明了“ACK校验机制”的存在价值无需任何文字解释。startTimer()与stopTimer()超时控制的基础设施。它使用java.util.Timer和TimerTask实现一个简单的单次定时器。startTimer(timeoutMs)启动一个任务到期后执行onTimeout()回调触发重传。实操注意Java的Timer不是线程安全的但在本实验的单线程发送模型下完全够用。如果未来要扩展为并发多连接这里就需要升级为ScheduledExecutorService但这已超出教学范围。3.3 TCP_RDT2.2.java主程序如何串联起整个协议生命线TCP_RDT2.2.java是站在舞台中央的指挥家它把Config.ini的配置、ENCDA.tcp的逻辑、Log.txt的日志、recvData.txt的存储全部编织成一条清晰的执行流。其主循环while (!allPacketsSent)的每一步都是对RDT2.2状态机的一次具象化演绎// 步骤1读取下一块数据从sendData.txt byte[] currentData readFileChunk(sendFile, currentOffset, PACKET_SIZE); if (currentData.length 0) break; // 文件读完 // 步骤2构造并发送数据包 int currentSeq nextSeqNum; log([SEND] Seq currentSeq , DataLen currentData.length , ...); encda.sendDataPacket(currentSeq, currentData); // 步骤3启动超时定时器 encda.startTimer(timeoutMs); // 步骤4循环等待ACK带超时 boolean ackReceived false; while (!ackReceived !encda.isTimeout()) { ackReceived encda.receiveACK(currentSeq); // 关键传入期望的seqNum } // 步骤5根据ACK结果分支处理 if (ackReceived) { log([RECV_ACK] Seq currentSeq , ACK# encda.getLastAckSeq() , ResultPASS); // 推进状态机准备发送下一个包 currentOffset currentData.length; } else { log([TIMEOUT] Seq currentSeq , Retrying...); // 超时重传当前包nextSeqNum不递增 }这段伪代码揭示了RDT2.2最精妙的控制逻辑发送方的状态由“当前待确认的序列号”唯一确定。nextSeqNum只在ACK成功接收后才递增一旦超时或ACK校验失败它就保持不变确保下次循环仍重传同一个currentSeq。这种“序号绑定状态”的设计是避免重复发送、保证顺序交付的基石。现场记录我在一次调试中把bit_error_prob设为0.5运行后Log.txt显示[SEND] Seq5, DataLen16, ... [RECV_ACK] Seq5, ACK#5, Checksum0x1A2B, ResultFAIL [RECV_ACK] Seq5, ACK#5, Checksum0x1A2B, ResultFAIL [TIMEOUT] Seq5, Retrying... [RETRANSMIT] Seq5, ReasonACK_Corrupted, RetryCount1这清晰地印证了即使ACK序号5是对的但校验码0x1A2B被损坏成0x1A2AverifyACK()依然会返回false强制进入重传。RDT2.2的“可靠性”就建立在这种对每一个字节的审慎怀疑之上。4. 实操过程与核心环节实现从零开始跑通一次完整实验4.1 环境准备与工程导入Eclipse里的三步走这个实验的“开箱即用”不是营销话术而是经过千百次学生实测的结论。以下是精确到点击坐标的导入步骤适用于Eclipse 2022-09及后续版本解压与定位将下载的CulKDjYfK7qGDjAT6LAT-master-64bf11bdb0786772d9436a4d1680fe08114bf93a.zip解压到任意目录如D:\rdt22。确保解压后根目录下直接能看到Config.ini、src文件夹、.project等文件而不是嵌套在多层子文件夹里。Eclipse导入启动Eclipse →File→Import...→ 展开General→ 选择Existing Projects into Workspace→ 点击Next→ 在Select root directory中精确点击到D:\rdt22这个文件夹不是它的父目录。此时Eclipse会自动扫描到.project文件并在下方Projects列表中勾选一个名为CulKDjYfK7qGDjAT6LAT-master的项目。关键确认勾选框旁应显示{Contains nested projects: 0}且项目名后没有(missing)字样。点击Finish。首次运行与验证导入完成后项目名会出现在Package Explorer中。展开src→com→ 找到TCP_RDT2.2.java右键 →Run As→Java Application。此时控制台会短暂显示Starting RDT2.2 Simulation...然后静默。等待10秒然后刷新Project Explorer视图F5你会看到根目录下凭空出现了两个新文件Log.txt和recvData.txt。双击Log.txt如果看到类似以下内容说明运行成功[START] RDT2.2 Simulation Started at 2024-04-05 14:23:15 [SEND] Seq1, DataLen16, Checksum0x3A7F, Timestamp1712327000123 [RECV_ACK] Seq1, ACK#1, Checksum0x3A7F, ResultPASS, Timestamp1712327000234 [SEND] Seq2, DataLen16, Checksum0x4B8A, Timestamp1712327000235提示如果遇到Exception in thread main java.lang.NoClassDefFoundError: com/encda/TCPProtocol说明导入路径错了。请删除项目勾选Delete project contents on disk重新执行步骤2务必确保在Import对话框中选中的是解压后的最外层文件夹。4.2 参数调优实验用三次运行读懂RDT2.2的“心跳”不要满足于一次成功运行。RDT2.2的教学价值恰恰在于你主动去“破坏”它。下面是一个精心设计的三阶段实验每次只改一个参数用Log.txt的对比告诉你协议的内在节奏实验一基线运行默认参数- 操作不修改Config.ini直接运行。- 观察重点打开Log.txt用CtrlEnd跳到末尾找到最后一行[END] Simulation completed. Total packets sent: 12, Retransmissions: 0。记下Retransmissions: 0。再向上滚动找[RECV_DATA]事件确认recvData.txt是否与sendData.txt内容一致。- 预期结果无重传数据完整。这是RDT2.2在理想信道下的“健康态”。实验二注入ACK位错误突显校验价值- 操作编辑Config.ini将bit_error_prob0.2改为bit_error_prob0.8提高到80%保存。- 观察重点再次运行等待结束后打开Log.txt。搜索Checksum mismatch统计出现次数再搜索[RETRANSMIT]统计重传次数。你会发现Retransmissions从0飙升到15且几乎每个[SEND]后面都跟着[RECV_ACK] ... ResultFAIL和[RETRANSMIT]。- 原理解析80%的ACK损坏率意味着发送方大概率收不到有效的ACK只能靠超时来驱动重传。这暴露了RDT2.2的“被动性”——它不主动探测只靠等待和超时。但关键在于它从未把损坏的ACK当作有效确认因此recvData.txt依然完整没有重复数据。这就是RDT2.2相比RDT2.0的质变。实验三缩短超时时间测试鲁棒性边界- 操作恢复bit_error_prob0.2将timeout_ms1000改为timeout_ms300。- 观察重点运行后Log.txt会出现大量[TIMEOUT]和[RETRANSMIT]但仔细看[RECV_ACK]事件会发现很多是ResultPASS的。这意味着ACK其实已经到达只是发送方等不及就重传了。统计[RETRANSMIT]总数会发现它远高于实验二因为误重传增多。- 经验总结超时时间是一个平衡的艺术。太长2000ms浪费带宽太短200ms制造虚假重传。教学中让学生把timeout_ms从1500逐步降到100、50记录重传率曲线就能亲手绘制出“超时设置-网络性能”的权衡图。4.3 日志深度分析如何从Log.txt里挖出协议状态机Log.txt不是流水账而是一份加密的协议执行日志。掌握它的解读密码你就能在脑中实时还原状态机。以下是针对典型日志片段的逐行破译[SEND] Seq4, DataLen16, Checksum0x2C9D, Timestamp1712327000888 [RECV_ACK] Seq4, ACK#4, Checksum0x2C9D, ResultPASS, Timestamp1712327000999 [SEND] Seq5, DataLen16, Checksum0x3D0E, Timestamp1712327001000 [RECV_ACK] Seq5, ACK#5, Checksum0x3D0F, ResultFAIL, Timestamp1712327001111 [TIMEOUT] Seq5, Retrying..., Timestamp1712327001500 [RETRANSMIT] Seq5, ReasonACK_Corrupted, RetryCount1, Timestamp1712327001501第1行[SEND] Seq4...发送方状态机处于WAIT_FOR_ACK_4状态它刚刚发出第4个包并启动了定时器。第2行[RECV_ACK] Seq4... ResultPASS定时器尚未超时ACK已抵达且校验通过。状态机立即从WAIT_FOR_ACK_4跳转到WAIT_FOR_DATA_5准备发送下一个包。第3行[SEND] Seq5...状态机已推进发出第5包进入WAIT_FOR_ACK_5。第4行[RECV_ACK] Seq5... ResultFAILACK抵达了但校验失败0x3D0F ! 0x3D0E。状态机不跳转依然停留在WAIT_FOR_ACK_5因为它没有得到有效的确认。第5-6行[TIMEOUT]和[RETRANSMIT]定时器到期状态机触发重传动作但nextSeqNum并未递增它仍在等待Seq5的确认。注意Log.txt里永远不会出现[RECV_ACK] Seq5, ACK#4, ResultPASS这样的行。因为receiveACK(5)方法内部会先检查ackSeqNum 5如果不等直接返回false根本不会走到校验步骤。这保证了日志的纯净性——每一条ResultPASS都意味着序号和校验双双通过。5. 常见问题与排查技巧实录那些年我们踩过的坑5.1 “Log.txt为空”——最常被问爆的问题现象运行TCP_RDT2.2.java后控制台一闪而过Project Explorer里没有生成Log.txt和recvData.txt或者文件存在但大小为0字节。排查树1.检查Config.ini路径确保Config.ini和src文件夹在同一级目录下。如果Config.ini被误拖进了src文件夹程序会因找不到配置而静默退出。解决方案剪切Config.ini到项目根目录与.project同级。2.检查sendData.txt内容sendData.txt必须存在且非空。如果它是空文件或只包含空格readFileChunk()会立即返回length0主循环break退出自然不产生日志。解决方案用记事本打开sendData.txt输入至少16个字符如1234567890123456保存。3.检查防火墙/杀毒软件极少数情况下Windows Defender或第三方杀软会拦截Java程序的文件写入权限。解决方案临时禁用实时防护或右键Eclipse快捷方式 →Properties→Compatibility→ 勾选Run this program as an administrator。5.2 “Log.txt里全是[SEND]没有[RECV_ACK]”——ACK石沉大海现象Log.txt里能看到[SEND] Seq1...、[SEND] Seq2...但后续没有任何[RECV_ACK]或[TIMEOUT]记录程序似乎卡住了。根本原因发送方和接收方没有运行在同一个进程里。这个实验是单机模拟但TCP_RDT2.2.java只实现了发送方逻辑。它需要一个配套的接收方程序来响应ACK。然而项目包里并没有提供独立的Receiver.java真相是ENCDA.tcp类内部已经封装了一个内置的、阻塞式的接收线程它会在receiveACK()被调用时自动监听本地端口默认8080等待ACK。但如果这个端口被占用如Chrome正在用8080接收线程就无法绑定导致receiveACK()永远阻塞。解决方案-方法一推荐编辑ENCDA.tcp源码找到private static final int RECEIVER_PORT 8080;这一行把它改成一个不常用的端口如8088或9999然后保存并重新运行。-方法二在Windows上按CtrlShiftEsc打开任务管理器 →Performance→Open Resource Monitor→Network→Listening Ports查找占用8080端口的进程结束它。5.3 “recvData.txt内容错乱多了乱码或少了字符”现象fc sendData.txt recvData.txt提示文件不同recvData.txt里出现?、或明显截断。根源分析这不是协议错误而是字符编码不一致。sendData.txt用UTF-8保存但Java的FileReader默认用系统编码Windows是GBK读取导致中文或特殊符号被错误解码。一劳永逸修复1. 用Notepad打开sendData.txt→Encoding→Convert to UTF-8→ 保存。2. 编辑TCP_RDT2.2.java找到读取文件的代码段通常是new FileReader(sendFile)将其替换为java BufferedReader reader new BufferedReader( new InputStreamReader(new FileInputStream(sendFile), StandardCharsets.UTF_8) );3. 同样修复ENCDA.tcp中写入recvData.txt的代码确保FileWriter也指定StandardCharsets.UTF_8。5.4 “想看更详细的校验过程比如每个字节的计算”需求教学演示时学生问“校验码0x2C9D是怎么算出来的能不能看到中间步骤”增强方案在ENCDA.tcp的calculateChecksum(byte[] data)方法里添加调试日志public static short calculateChecksum(byte[] data) { int sum 0; for (int i 0; i data.length; i) { sum (data[i] 0xFF); // 强制转为无符号字节 if (i 5) { // 只打印前5个字节避免日志爆炸 log(DEBUG: Byte[ i ] 0x String.format(%02X, data[i]) , sum sum); } } return (short) ~sum; }然后在Config.ini里加一行debug_modetrue并在log()方法里增加判断只有debug_mode为真时才输出DEBUG行。这样你就能在Log.txt里看到每一字节的累加过程把抽象的“校验和”变成可视化的数学运算。6. 教学延伸与进阶思考从RDT2.2走向真实TCP这个实验的价值不仅在于它完美复现了RDT2.2更在于它为你打开了一扇门通往更广阔的网络世界。当你已经能熟练解读Log.txt里的每一次重传不妨尝试这些延伸挑战挑战一实现RDT3.0的“冗余ACK”RDT2.2只能应对ACK损坏但对数据包丢失束手无策。RDT3.0引入了“冗余ACK”Duplicate ACK机制当接收方收到失序包如先收到Seq3再收到Seq2它会立即重复发送对Seq1的ACK。发送方收到3个重复ACK就立即重传Seq2而不必等待超时。你可以修改ENCDA.tcp在接收方逻辑里加入失序检测并让receiveACK()能识别重复ACK计数。这会让你深刻体会到TCP的快速重传Fast Retransmit其思想源头就在这里。挑战二可视化状态机把Log.txt的每一行事件映射到一张状态转移图上。用Python的graphviz库自动解析日志生成dot文件再渲染成PNG图。图中节点是WAIT_FOR_DATA_1、WAIT_FOR_ACK_2等状态边是[SEND]、[RECV_ACK_PASS]、[TIMEOUT]等事件。当bit_error_prob升高时你会看到图中WAIT_FOR_ACK_n节点的自环边[RECV_ACK_FAIL]显著增多——这比任何文字描述都更能说明“ACK校验”的防御价值。挑战三对比RDT2.0的脆弱性创建一个RDT20_Simulator.java移除ENCDA.tcp中所有的ACK校验逻辑只保留序号匹配。然后用相同的Config.inibit_error_prob0.5运行它。对比两个recvData.txtRDT2.0的版本会出现重复数据块如“Hello World! Hello World!”而RDT2.2的版本始终干净。这个对比实验不需要任何讲解结果本身就在呐喊“校验是可靠的底线。”我个人在带学生做这个实验时最常强调的一句话是协议设计没有银弹只有权衡。RDT2.2用额外的2字节校验码、一次CPU计算、一次条件判断换来了对ACK损坏的免疫能力。它牺牲了一点点带宽和计算开销却赢得了数据交付的确定性。这种“用可量化成本换取关键可靠性”的思维模式才是计算机网络课程真正想传递给你的东西——它不只属于RDT也属于HTTP/3的QUIC属于5G的URLLC属于你未来写的每一行分布式系统代码。当你下次看到TCP头部的Checksum字段或者TLS握手中的CertificateVerify消息那个在Log.txt里跳动的[RECV_ACK] ... ResultPASS就会在你脑中响起提醒你可靠从来不是理所当然而是被一行行代码一比特一比特亲手铸造出来的。本文还有配套的精品资源点击获取简介用Java写的RDT2.2协议教学实验包专注演示TCP简化模型中接收方返回的ACK确认包发生单比特错误时发送方如何通过超时重传机制应对。工程结构完整含Eclipse预配置.project、.classpath、.settings开箱即用。运行后自动生成Log.txt记录每一步发送/接收/校验/重传过程接收数据存入recvData.txt。Config.ini支持修改超时时间、丢包率、位错概率等关键参数核心逻辑在ENCDA.tcp文件主程序入口为TCP_RDT2.2.java。适合网络课程讲授可靠传输原理尤其对比RDT2.0与RDT2.2在ACK校验设计上的差异——RDT2.2引入了ACK序号和校验机制能识别损坏的ACK并避免误重传。所有日志字段清晰标注事件类型、序列号、校验结果、是否重传方便学生跟踪状态机跳转与协议行为。本文还有配套的精品资源点击获取
