简介本资源是面向计算机网络课程学习者与教学实践者的RDT 3.0协议仿真实验包聚焦可靠数据传输核心机制的教学理解与代码实现。资源完整呈现停等ARQ协议的关键逻辑含序号管理、CRC校验、超时重传与确认应答等模块适用于高校网络原理实验、协议编程实训及TCP底层机制深度剖析场景。压缩包共16个文件主体为5个Java类文件含发送端、接收端及协议核心逻辑、4个Java源码.java用于编译运行辅以2个说明/日志文本txt、Eclipse项目配置文件.project、.classpath、.prefs、TCP协议配置模板ENCDA.tcp及INI初始化配置总大小1.04MB结构清晰、开箱即用。目前已有442人学习下载读者可直接导入IDE运行调试结合recvData.txt等日志观察数据流与错误恢复过程掌握RDT 3.0在丢包、校验失败等异常下的行为响应夯实传输层协议设计与实现能力。1. RDT 3.0 不是玩具协议它用停等ARQ把「丢包、错包、乱序」全兜住但真实跑起来会卡死、重传爆炸、校验失效——这份 TCP-RDT3.0.zip 是教学级可调试源码不是 demo 演示包适合网络协议课设、毕设底层协议复现、Wireshark 抓包对照验证者尤其适合被「为什么 ACK 没回来」「重发了三次还卡住」逼到崩溃的本科生和刚转岗的嵌入式/协议栈工程师你写完 RDT 2.0以为加个序号校验就稳了RDT 3.0 的真实门槛根本不在逻辑图上——它强制你直面「超时判定不准」带来的雪崩重传、「ACK 丢失后发送方疯发」导致的接收方状态错乱、「校验位被篡改却未触发重传」这类玄学问题。这个TCP-RDT3.0.zip不是 PPT 里的流程图而是 Eclipse 工程结构完整的 Java 实现含.project和.classpathsrc/com/下分层封装了Sender、Receiver、UDPSocket、Packet四大核心类bin/里有编译好的 class 文件recvData.txt是接收端落地数据Log.txt记录每帧收发时间戳与校验结果Config.ini控制超时阈值、丢包率、错误注入开关。它不依赖任何第三方网络库纯 JDK 1.8 UDP socket 手动序列化 CRC-8 校验所有协议状态机WAIT_FOR_CALL_0、WAIT_FOR_ACK_0、WAIT_FOR_CALL_1、WAIT_FOR_ACK_1全部显式编码连org.eclipse.jdt.core.prefs都保留着原始编码设置。这不是让你“跑通就行”的玩具而是能进 debugger 单步跟踪 ACK 超时分支、修改Config.ini注入 15% 丢包、对比Log.txt与 Wireshark 抓包时间线的硬核实验基座。1.1 它解决的不是「理论对不对」而是「为什么我写的 RDT 总在第 7 帧卡死」很多同学实现 RDT 3.0 后发现前 6 帧正常第 7 帧突然停住Log.txt显示Sent PKT#7, timeout500ms但recvData.txt空空如也。这不是代码漏写了而是 RDT 3.0 的停等本质决定了它对「超时精度」极度敏感——当网络延迟抖动超过设定 timeout就会误判丢包并触发重传而重传又可能撞上原包迟到造成接收方重复 ACK 或状态错乱。这个压缩包的价值在于它的Config.ini允许你把timeout_ms500改成1200再配合Log.txt中精确到毫秒的时间戳格式[2024-03-15 14:22:03.872] SENT PKT#7 SEQ7 CHK0x3A你能肉眼比对「发送时刻 vs ACK 到达时刻 vs timeout 触发时刻」从而定位到底是网络抖动、JVM GC 暂停还是你自己的 CRC 计算逻辑偏差。它不教你怎么背 ARQ 定义它逼你亲手调参、看日志、改代码、验证结论。1.2 为什么必须用 Java Eclipse 工程结构因为你要 debug 状态机跳转RDT 3.0 的灵魂是四个状态之间的严格转换WAIT_FOR_CALL_0 → WAIT_FOR_ACK_0 → WAIT_FOR_CALL_1 → WAIT_FOR_ACK_1 → WAIT_FOR_CALL_0。C 语言实现容易把状态藏在 if-else 里Java 这份代码则用enum RDTState { WAIT_FOR_CALL_0, WAIT_FOR_ACK_0, ... }显式声明并在Sender.java的send()方法中用switch(state)分支控制行为。这意味着你可以在 Eclipse 里对state WAIT_FOR_ACK_0打断点观察「发送后是否真的进入等待 ACK 状态」「收到 ACK 后是否正确切回 WAIT_FOR_CALL_1」。.project文件里还定义了org.eclipse.jdt.core.javabuilder构建器确保你改完Packet.java的 CRC 计算逻辑后bin/com/下 class 文件自动更新——这种「改一行代码、debug 一次状态跳转」的闭环是 Python 脚本或 CMake 工程难以提供的教学穿透力。1.3 它不是 TCP 替代品而是 TCP 的「解剖标本」别被名字误导TCP-RDT3.0.zip里的TCP_RDT3.0是项目名不是实现了 TCP。它用 UDP socket 模拟不可靠信道自己实现序号、校验、超时、重传——这恰恰是理解真实 TCP 的起点。当你用 Wireshark 抓到tcpdump -i lo port 9999该工程默认监听 UDP 9999 端口看到的是 raw UDP 包 payload 里明文的SEQ7 DATAHelloWorld CHK0x3A而不是 TCP header 里的 sequence number。这种「剥离 TCP 协议栈只留可靠传输内核」的设计让你能专注验证CRC-8 算法是否真能检出单比特翻转Config.ini里corrupt_rate0.1是否真让 10% 的包校验失败Log.txt中RECV PKT#7 CORRUPTED!是否触发了预期的无 ACK 行为这才是协议学习从「纸上谈兵」到「肌肉记忆」的关键跃迁。2. 从解压到可调试Eclipse 工程导入、关键类职责拆解与 Config.ini 参数实战指南2.1 解压即用四步完成 Eclipse 工程导入跳过 Maven、Gradle 等干扰项这个工程是纯 Java SE 项目不依赖任何构建工具。解压后直接导入 Eclipse无需额外配置# 1. 解压到工作目录例如 ~/network-lab/ unzip TCP-RDT3.0.zip -d ~/network-lab/ cd ~/network-lab/TCP_RDT3.0 # 2. 确认关键文件存在这是工程合法性的物理证据 ls -F .project .classpath src/com/ bin/ Config.ini Log.txt recvData.txt # 3. Eclipse 导入路径File → Import → General → Existing Projects into Workspace # → Select root directory: ~/network-lab/TCP_RDT3.0 # → 勾选 TCP_RDT3.0 项目 → Finish # 4. 编译检查Project → Properties → Java Build Path → Libraries 标签页 # 应显示 JRE System Library [JavaSE-1.8]无红色叉号提示如果 Eclipse 提示The project cannot be built until build path errors are resolved请右键项目 → Properties → Java Build Path → Libraries → RemoveJRE System Library→ Add Library → JRE System Library → Execution environment:JavaSE-1.8。这是因 JDK 版本不匹配导致的常见问题不是代码缺陷。2.2 四大核心类职责与调用链Sender 是大脑Receiver 是哨兵Packet 是信使UDPSocket 是管道整个协议运行依赖四个 Java 类的协同它们的职责边界必须清晰类名路径核心职责关键方法调试切入点Sendersrc/com/Sender.java协议发起者管理发送状态机、维护当前序号、启动超时定时器、处理 ACKsend(),handleAck(),timeoutHandler()在send()开头打断点观察nextSeqNum如何递增在timeoutHandler()里看重传逻辑Receiversrc/com/Receiver.java协议守门人校验包完整性、按序缓存数据、生成 ACK、处理重复包receive(),checkChecksum(),sendAck()在checkChecksum()内部打断点手动修改packet.data观察校验失败路径Packetsrc/com/Packet.java数据载体序列化 SEQ/DATA/CHK 字段提供 CRC-8 计算与验证serialize(),deserialize(),computeChecksum()修改computeChecksum()算法如改成 CRC-16验证Log.txt中 CHK 值变化UDPSocketsrc/com/UDPSocket.java通信管道封装 DatagramSocket提供 sendTo()/receiveFrom() 接口sendTo(),receiveFrom(),close()在receiveFrom()返回前打断点模拟网络丢包注释掉socket.receive()调用链非常线性Sender.send()→UDPSocket.sendTo()→ 网络 →UDPSocket.receiveFrom()→Receiver.receive()→Receiver.sendAck()→UDPSocket.sendTo()→Sender.handleAck()。这种扁平结构让你能用 Eclipse 的 Debug → Step Into 逐层下钻而不是在回调地狱里迷失。2.3 Config.ini 参数详解超时、丢包、错误注入——三把钥匙打开协议鲁棒性测试Config.ini是控制实验行为的总开关共 6 个参数每个都直接影响协议表现。不要跳过这一步直接 run# Config.ini # 协议基础参数 port9999 timeout_ms500 max_retransmit3 # 错误注入参数仅用于测试 drop_rate0.0 corrupt_rate0.0 delay_ms0 # 日志与输出 log_fileLog.txt recv_filerecvData.txttimeout_ms500最关键参数。它定义 Sender 等待 ACK 的毫秒数。设得太小如 100ms会导致频繁误重传设得太大如 2000ms会让吞吐量暴跌。真实网络中RTT往返时延应是 timeout 的 2~4 倍此处timeout_ms应 ≥ 2× 实际 RTT。drop_rate0.0丢包率0.0 表示 0%0.1 表示 10%。启用后UDPSocket.sendTo()内部会以该概率丢弃包。注意丢包发生在发送端所以Log.txt仍会记录SENT PKT#X但recvData.txt不会出现对应数据。corrupt_rate0.0数据篡改率。启用后Packet.serialize()输出的 byte[] 中会随机翻转一个 bit导致Receiver.checkChecksum()失败。此时Log.txt会记录RECV PKT#X CORRUPTED!且 Receiver 不发 ACK。delay_ms0人为增加网络延迟。设为 300则每个包在UDPSocket.sendTo()后 sleep 300ms 再真正发送。这会直接拉长 RTT考验timeout_ms设置是否合理。注意drop_rate和corrupt_rate是互斥的——一个包不会既被丢弃又被篡改。delay_ms对所有包生效包括 ACK。2.4 第一次运行验证环境、观察 Log.txt、确认 recvData.txt 写入成功导入工程后右键Sender.java→ Run As → Java Application。几秒后控制台应输出[INFO] Sender started on port 9999 [INFO] Sending packet #0... [INFO] Sending packet #1... ... [INFO] All packets sent. Waiting for final ACK... [INFO] Sender terminated.同时检查三个文件# 查看 Log.txt —— 应有至少 10 行包含 SENT/RECV/ACK/CORRUPTED 记录 tail -n 10 Log.txt # 示例输出 # [2024-03-15 14:22:03.872] SENT PKT#0 SEQ0 CHK0x1F # [2024-03-15 14:22:03.875] RECV PKT#0 SEQ0 CHK0x1F # [2024-03-15 14:22:03.876] SEND ACK#0 # 查看 recvData.txt —— 应为明文内容与发送数据一致 cat recvData.txt # 示例输出 # Hello World! This is RDT 3.0 test data. # 查看 bin/ 目录 —— 确认 class 文件已编译 ls -l bin/com/*.class | head -5如果recvData.txt为空或Log.txt只有SENT没有RECV说明 Receiver 未启动或端口冲突。此时需手动启动 Receiver右键Receiver.java→ Run As → Java Application先启 Receiver再启 Sender。3. 协议状态机深度解析WAIT_FOR_CALL_0 到 WAIT_FOR_ACK_1 的四态跳转与超时陷阱3.1 RDT 3.0 状态机本质两个序号0/1 两个等待CALL/ACK 四个原子状态RDT 3.0 的核心创新是引入「交替位协议Alternating Bit Protocol」用 1 bit 序号0 或 1解决停等协议的效率瓶颈。其状态机不是抽象概念而是Sender.java中RDTStateenum 的四个实例// src/com/Sender.java public enum RDTState { WAIT_FOR_CALL_0, // 等待上层应用调用 send() 发送 SEQ0 的包 WAIT_FOR_ACK_0, // 已发 SEQ0等待 ACK#0 WAIT_FOR_CALL_1, // 等待上层应用调用 send() 发送 SEQ1 的包 WAIT_FOR_ACK_1 // 已发 SEQ1等待 ACK#1 }状态跳转由三个事件驱动上层调用send()触发WAIT_FOR_CALL_X → WAIT_FOR_ACK_X收到 ACK#X触发WAIT_FOR_ACK_X → WAIT_FOR_CALL_(1-X)超时发生触发WAIT_FOR_ACK_X → WAIT_FOR_ACK_X重传状态不变关键洞察WAIT_FOR_CALL_X状态下nextSeqNum必须等于 XWAIT_FOR_ACK_X状态下nextSeqNum仍为 X直到收到 ACK#X 才翻转。这个细节决定了重传时序号绝不会错。3.2 从代码看状态跳转Sender.send() 中的 switch-case 是状态机执行引擎Sender.send()方法是状态机的中枢其逻辑完全由switch(state)控制// src/com/Sender.java public void send(byte[] data) throws IOException { switch (state) { case WAIT_FOR_CALL_0: // 构造 SEQ0 的包启动超时定时器发送 Packet pkt new Packet(0, data); startTimer(); udpSocket.sendTo(pkt.serialize(), receiverAddress); state RDTState.WAIT_FOR_ACK_0; // 状态跳转 break; case WAIT_FOR_CALL_1: // 构造 SEQ1 的包启动超时定时器发送 pkt new Packet(1, data); startTimer(); udpSocket.sendTo(pkt.serialize(), receiverAddress); state RDTState.WAIT_FOR_ACK_1; // 状态跳转 break; default: // WAIT_FOR_ACK_0 or WAIT_FOR_ACK_1不允许上层再次 send() throw new IllegalStateException(Cannot send when waiting for ACK); } }血泪经验初学者常在此处犯错——忘记state RDTState.WAIT_FOR_ACK_X这行赋值导致状态永远卡在WAIT_FOR_CALL_Xsend()被反复调用却无实际发送。Eclipse 调试时在state RDTState.WAIT_FOR_ACK_0;这行打条件断点state WAIT_FOR_CALL_0即可验证跳转是否发生。3.3 超时定时器实现Timer TimerTask 的精确控制与内存泄漏风险超时机制不是Thread.sleep()而是java.util.Timer的异步回调// src/com/Sender.java private Timer timer; private TimerTask timeoutTask; private void startTimer() { if (timer ! null) timer.cancel(); // 防止重复启动 timer new Timer(true); // daemon thread timeoutTask new TimerTask() { Override public void run() { timeoutHandler(); // 执行重传逻辑 } }; timer.schedule(timeoutTask, timeout_ms); // 在 timeout_ms 毫秒后触发 } private void timeoutHandler() { // 重传当前序号的包注意nextSeqNum 未变 Packet retransmitPkt new Packet(nextSeqNum, lastData); udpSocket.sendTo(retransmitPkt.serialize(), receiverAddress); // 重置定时器为下次超时准备 startTimer(); }避坑点timer.cancel()必须在startTimer()开头调用否则多次send()会创建多个 Timer导致内存泄漏。Timer(true)创建守护线程避免 JVM 无法退出。timeoutHandler()中startTimer()是关键——它让重传后继续等待 ACK形成「重传→再等→再重传」循环直到max_retransmit达到上限。3.4 ACK 处理逻辑handleAck() 如何安全地翻转状态与序号handleAck()方法负责解析 ACK 并推进状态// src/com/Sender.java public void handleAck(int ackNum) { if (ackNum nextSeqNum) { // ACK#X 匹配当前期望的 SEQX // 状态翻转WAIT_FOR_ACK_X → WAIT_FOR_CALL_(1-X) if (state RDTState.WAIT_FOR_ACK_0) { state RDTState.WAIT_FOR_CALL_1; nextSeqNum 1; } else if (state RDTState.WAIT_FOR_ACK_1) { state RDTState.WAIT_FOR_CALL_0; nextSeqNum 0; } // 取消定时器ACK 到达无需重传 if (timer ! null) { timer.cancel(); timer null; } System.out.println([INFO] Received ACK# ackNum); } else { // ACK#Y 不匹配当前期望Y ! X可能是旧 ACK 迟到 System.out.println([WARN] Unexpected ACK# ackNum , ignoring); } }玄学问题根源当网络严重抖动ACK#0迟到到达时Sender 可能已重传PKT#0并进入WAIT_FOR_ACK_1状态。此时handleAck(0)会因ackNum ! nextSeqNum此时 nextSeqNum1而忽略该 ACK这是协议设计的容错机制不是 bug。Log.txt中若出现[WARN] Unexpected ACK#0, ignoring说明网络存在乱序RDT 3.0 正在按设计工作。4. 避坑 / 常见问题 / 排查五条真实踩坑记录每条附现象、原因、解决4.1 现象Log.txt显示SENT PKT#0但recvData.txt为空Receiver 控制台无输出原因Receiver 未启动或 Sender 与 Receiver 使用不同端口Config.ini中port值不一致或防火墙拦截 UDP 9999 端口。解决确保先运行Receiver.java再运行Sender.java检查双方Config.ini的port值是否均为9999Linux/macOS 执行sudo lsof -i :9999查看端口占用Windows 执行netstat -ano | findstr :9999临时关闭防火墙测试sudo ufw disableUbuntu或 Windows Defender 防火墙设置中允许 UDP 9999。4.2 现象Log.txt中RECV PKT#X CORRUPTED!频繁出现但corrupt_rate0.0原因Packet.computeChecksum()计算逻辑与Receiver.checkChecksum()验证逻辑不一致或serialize()/deserialize()字节序处理错误导致校验值天然不匹配。解决在Packet.java的computeChecksum()和Receiver.java的checkChecksum()中分别添加System.out.println(CHK calc: chk);对比两处输出值——若不等检查computeChecksum()是否对data字节数组做了非预期修改如Arrays.copyOf()未复制完整确认serialize()将seq、data、chk按固定顺序写入 byte[]deserialize()按相同顺序读取。4.3 现象Sender 发送PKT#0后卡死Log.txt无后续SENT PKT#1timeout_ms设为 500 但未触发重传原因startTimer()中timer.schedule(timeoutTask, timeout_ms)的timeout_ms为 0 或负数导致Timer立即触发timeoutHandler()但此时lastData为空重传失败。解决在startTimer()开头添加校验if (timeout_ms 0) throw new IllegalArgumentException(timeout_ms must be 0);检查Config.ini中timeout_ms是否被误写为0或-500在timeoutHandler()开头添加if (lastData null) { System.err.println([ERROR] lastData is null, cannot retransmit); return; }。4.4 现象启用drop_rate0.1后Log.txt显示SENT PKT#0但RECV PKT#0消失且 Sender 在WAIT_FOR_ACK_0状态无限等待原因drop_rate仅作用于UDPSocket.sendTo()但 Sender 的超时定时器未被正确重置——重传后startTimer()未被调用导致第一次超时后无后续重传。解决检查timeoutHandler()方法末尾是否调用了startTimer()确认startTimer()内部timer.cancel()后重新创建了Timer实例在timeoutHandler()中添加日志System.out.println([INFO] Retransmitting PKT# nextSeqNum);验证重传是否执行。4.5 现象recvData.txt中数据乱序如PKT#1内容出现在PKT#0之前原因Receiver 未按序缓存数据。RDT 3.0 要求 Receiver 只接收SEQexpectedSeqNum的包其他包丢弃。但代码中Receiver.receive()可能直接将PKT#1写入recvData.txt未检查pkt.seq expectedSeqNum。解决在Receiver.receive()中添加序号校验if (pkt.seq ! expectedSeqNum) { System.out.println([WARN] Out-of-order PKT# pkt.seq , expected expectedSeqNum , dropping); return; // 丢弃乱序包 }expectedSeqNum初始为 0每次成功接收并写入后翻转expectedSeqNum 1 - expectedSeqNumrecvData.txt应只在pkt.seq expectedSeqNum时追加pkt.data。5. CRC-8 校验实战手撕算法、注入单比特错误、对比 Log.txt 与 Wireshark 抓包验证5.1 CRC-8 算法实现多项式 0x07 的字节查表法与在线计算验证Packet.java中的computeChecksum()使用 CRC-8-ITU 标准多项式 x⁸ x² x 1即 0x07采用查表法提升性能// src/com/Packet.java private static final byte[] CRC8_TABLE { 0x00, 0x07, 0x0E, 0x09, 0x1C, 0x1B, 0x12, 0x15, 0x38, 0x3F, 0x36, 0x31, 0x24, 0x23, 0x2A, 0x2D, // ... 共 256 项此处省略 }; public static byte computeChecksum(byte[] data) { byte crc 0x00; for (byte b : data) { crc CRC8_TABLE[crc ^ (b 0xFF)]; } return crc; }验证方法取data Hello.getBytes()手动计算 CRC-8在线工具输入48 65 6C 6C 6FHello 的 hex选择 CRC-8/ITU得到0x3F运行代码System.out.println(Integer.toHexString(Packet.computeChecksum(Hello.getBytes())));输出应为3f。若不一致检查CRC8_TABLE是否完整必须 256 项或b 0xFF是否缺失Java byte 为 signed需转为 unsigned int。5.2 注入单比特错误用十六进制编辑器篡改 recvData.txt触发校验失败链路要验证 CRC-8 是否真能检出单比特错误不能只靠corrupt_rate正常运行一次获取recvData.txt假设内容为HelloWorld用xxd或 HxD 编辑器打开recvData.txt找到W字符ASCII 0x57将其改为VASCII 0x56——即翻转 bit 3将篡改后的recvData.txt重命名为recvData_corrupted.txt修改Receiver.java在receive()中读取recvData_corrupted.txt作为模拟接收数据或直接在checkChecksum()前data[5] ^ 0x08翻转 bit运行 ReceiverLog.txt应出现RECV PKT#X CORRUPTED!且无SEND ACK#X记录。提示data[5] ^ 0x08是最直接的单比特翻转0x08 0b00001000比改字符更精准。5.3 Wireshark 抓包对照UDP payload 解析与 CRC 字段定位Wireshark 是验证协议行为的终极手段。抓包命令# Linux/macOS sudo tcpdump -i any -w rdt3.pcap port 9999 # Windows需 WinPcap/Npcap # tshark -i Ethernet -w rdt3.pcap port 9999在 Wireshark 中打开rdt3.pcap找到 UDP 包展开UDP → Data右键Data→Export Packet Bytes保存为pkt_raw.bin。用xxd pkt_raw.bin查看00000000: 00 48 65 6c 6c 6f 57 6f 72 6c 64 21 3f .HelloWorld!?00是 SEQ 字段1 byte48 65 6c 6c 6f 57 6f 72 6c 64 21是 DATAHelloWorld! 的 ASCII3f是 CHK 字段1 byte。对比Log.txt中SENT PKT#0 SEQ0 CHK0x3F确认 CRC 值一致。若chk字段被篡改如3f→3eWireshark 显示的 payload 会变化Receiver.checkChecksum()必然失败。5.4 性能瓶颈实测吞吐量TPS与超时阈值的量化关系RDT 3.0 的吞吐量受timeout_ms严格制约。理论最大 TPS 1000 / (2 × RTT processing_time)。实测步骤设Config.initimeout_ms1000,drop_rate0.0,corrupt_rate0.0修改Sender.java在send()循环外记录开始时间long start System.currentTimeMillis()在Sender结束时记录long end System.currentTimeMillis()发送 100 个包计算 TPS 100 / ((end - start) / 1000.0)逐步降低timeout_ms至 200重测 TPS绘制曲线X 轴timeout_msY 轴TPS会发现 TPS 在timeout_ms ≈ 2×RTT时达到峰值之后下降因超时重传增多。真实数据参考在本地 loopbackRTT≈1mstimeout_ms10时 TPS≈80timeout_ms100时 TPS≈50timeout_ms1000时 TPS≈10。这印证了「超时不是越大越好」的工程直觉。6. 进阶技巧用 Log.txt 时间戳反推网络 RTT、构建自动化测试脚本、将 RDT 3.0 移植到 ESP326.1 从 Log.txt 提取 RTT用 awk 一行命令计算平均往返时延Log.txt的时间戳精确到毫秒是反推网络性能的金矿。提取SENT PKT#X与对应RECV PKT#X的时间差# 提取所有 PKT#X 的 SENT 和 RECV 时间戳格式[YYYY-MM-DD HH:MM:SS.mmm] grep -E (SENT PKT#[0-9]|RECV PKT#[0-9]) Log.txt | \ awk { # 提取时间字符串如 [2024-03-15 14:22:03.872] time_str substr($1, 2, length($1)-2) # 提取序号和事件类型 if ($2 SENT) { seq $3; event[seq] SENT; time[seq] time_str } else if ($2 RECV) { seq $3; event[seq] RECV; time[seq] time_str } } END { # 计算每个序号的 RTT毫秒 for (i in event) { if (event[i] SENT event[i] RECV) { # 这里需要将 time_str 转为毫秒数简化版假设同秒内 split(time[i], t, /[ :.]/) sent_ms t[4]*3600000 t[5]*60000 t[6]*1000 t[7] # 实际需解析完整时间此处用 sed 预处理更可靠 } } } Log.txt更可靠方案用 Python 脚本解析# parse_rtt.py import re from datetime import datetime log_lines open(Log.txt).readlines() sent_times {} recv_times {} for line in log_lines: # 匹配 [2024-03-15 14:22:03.872] SENT PKT#0 ... match re.match(r\[(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3})\] (SENT|RECV) PKT#(\d), line) if match: timestamp, event, seq match.groups() dt datetime.strptime(timestamp, %Y-%m-%d %H:%M p a hrefhttps://download.csdn.net/download/Lovejmy/64126610 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p