简介：TCP-RDT2.2.zip 是一份面向计算机网络课程学习者与实验实践者的可靠数据传输协议模拟资源，围绕 RDT 2.2 版本展开，重点解决 RDT 2.0 中 ACK 确认包可能位错、导致确认信息无法正确回传的问题。资源包共 15 个文件，约 1.04MB，以 4 个 java 源文件与 4 个 class 编译文件为核心，辅以 txt 日志与配置说明、prefs、project、classpath、ini 等工程配置文件，构成一个可直接导入运行的完整实验工程。内容涉及累计确认、超时重传以及 ACK 包纠错编码等机制，帮助读者理解发送方与接收方如何通过序列号、校验和与 RTT 超时策略提升传输可靠性。已有 322 人学习关注，适合希望动手模拟 TCP 可靠传输流程、完成课程实验或加深协议设计理解的学生与开发者参考。
1. TCP-RDT2.2.zip 里到底装了什么：从三次握手到可靠传输的最小闭环
很多人第一次看到TCP-RDT2.2.zip这个包名，会下意识以为它是个现成的 TCP 协议栈或者抓包工具。我当初也这么想，解压后才发现它更像一份「可靠数据传输（Reliable Data Transfer，RDT）实验脚手架」——把 TCP 最核心的几件事：三次握手建连、序号与确认、超时重传、滑动窗口，压缩成一个能跑起来、能改参数、能抓日志的最小闭环。它解决的不是「怎么用 socket 发数据」，而是「为什么发出去的数据不会丢、不会乱、不会重复」这个底层问题。适合两类人：一类是刚学完 tcp 三次握手四次挥手、想亲手摸一遍状态机的人；另一类是做嵌入式或物联网通信，被 lwip tcp 断连、c++ tcp 粘包处理折磨过，想回头补可靠传输原理的工程师。这个包的价值不在代码量，而在它把「玄学」变成了可观测的日志和可调的定时器。
2. 拆开 TCP-RDT2.2.zip：先分清哪些是协议、哪些是脚手架
2.1 RDT 2.2 和 TCP 的关系：不是替代，是教学切片
RDT 2.2 是《计算机网络：自顶向下方法》里用来讲可靠传输的一个版本，核心机制是「停等协议 + 序号 + 确认 + 超时重传」。它和真实 TCP 的差别在于：RDT 2.2 一次只发一个包，收到正确 ACK 才发下一个；TCP 则是流水线式发送，靠滑动窗口和累积确认提升吞吐。所以拿到TCP-RDT2.2.zip后，第一件事是分清目录里哪些文件是 RDT 协议逻辑（通常是 sender、receiver、packet 结构定义），哪些是模拟链路层丢包的脚手架（比如随机丢包、延迟注入）。常见做法是：先跑默认配置，观察无丢包时日志里 seq 和 ack 的交替；再手动把丢包率调到 0.3，看发送方如何靠超时重传把数据补上。这一步不做，后面改参数就是盲调。
2.2 环境准备：用最小依赖跑通第一个包
这个包一般不会依赖复杂框架，Python 或 C 都能跑。我一般先用 Python 版本验证逻辑，因为改起来快、日志好读。下面是一个最小可运行的环境准备和启动命令，假设包内有一个rdt_sim.py入口：
# 创建独立环境，避免污染系统 Python python3 -m venv venv_rdt source venv_rdt/bin/activate # 安装常见依赖：只有网络模拟和日志着色会用到 pip install simpy colorlog # 查看包内文件结构，确认入口和配置文件 find TCP-RDT2.2 -maxdepth 2 -type f | sort # 以默认参数启动一次模拟：无丢包、无延迟 python rdt_sim.py --loss 0 --delay 0 --verbose逻辑说明：--loss 0表示链路层不丢包，用来验证协议基本逻辑；--delay 0表示不注入额外延迟，先排除定时器干扰；--verbose打开逐包日志。参数说明：丢包率loss一般取 0 到 0.5，超过 0.5 后停等协议吞吐会低到难以观察；延迟delay单位通常是毫秒，模拟广域网时设 50 到 200。如果启动报缺少模块，先看requirements.txt是否存在，不要急着全局安装。
2.3 抓一次完整交互：seq、ack、超时重传在日志里长什么样
跑起来后，日志里会出现类似SEND seq=0、RCV ack=0、TIMEOUT seq=0、RESEND seq=0的行。你要做的是把一次丢包场景完整截下来。下面这段是典型的发送方状态机伪代码，对照日志看更容易理解：
# 发送方核心循环：停等 + 超时重传 def sender_loop(link, timeout=1.0): seq = 0 while True: pkt = make_packet(seq, data[seq]) link.send(pkt) # 发送当前包 start_timer(timeout) # 启动超时定时器 while True: ack = link.recv_ack() # 等待 ACK if ack is None: if timer_expired(): # 超时：重传同一个 seq link.send(pkt) start_timer(timeout) continue elif ack.seq == seq: # 收到正确 ACK：推进窗口 stop_timer() seq = 1 - seq # RDT 2.2 用 0/1 交替序号 break else: # 收到重复 ACK 或错误 ACK，忽略，继续等 continue逻辑说明：RDT 2.2 的序号只有 0 和 1，因为停等协议一次只有一个未确认包，1 位序号足够区分「新包」和「重传包」。参数说明：timeout是超时时间，设太小会导致无丢包时也频繁重传，设太大则丢包后恢复慢；实际调试时先设 1 秒，再根据delay调整到2 * delay + 处理时间。日志里如果看到RESEND后紧接着RCV ack，说明重传生效；如果一直TIMEOUT没有 ACK，先检查接收方是否因为序号不匹配把包丢了。
3. 把丢包率拉满：RDT 2.2 的边界和 TCP 的差距在哪
3.1 停等协议的吞吐天花板：算一笔账就明白
RDT 2.2 最大的问题是停等：发一个包，等一个 ACK，再发下一个。假设链路往返时间 RTT 是 100ms，包大小 1000 字节，那么理论吞吐只有1000 字节 / 0.1 秒 = 10 KB/s，约 80 kbps。这个数字在今天的网络里几乎不可用。你可以用下面的脚本快速验证不同 RTT 下的吞吐：
# 计算停等协议理论吞吐 def stop_and_wait_throughput(pkt_bytes, rtt_ms): rtt_s = rtt_ms / 1000.0 return pkt_bytes / rtt_s # 字节/秒 for rtt in [10, 50, 100, 200]: tp = stop_and_wait_throughput(1000, rtt) print(f"RTT={rtt}ms, 吞吐={tp/1024:.1f} KB/s")逻辑说明：这个计算假设没有丢包、没有处理延迟，是理论上限。参数说明：pkt_bytes是应用层数据大小，不含头部；rtt_ms是往返时间。跑完你会看到 RTT 从 10ms 涨到 200ms，吞吐掉 20 倍。这就是为什么真实 TCP 必须用滑动窗口——它允许在等待 ACK 的同时继续发后续包，把「等待时间」填满。
3.2 从 RDT 2.2 到 TCP：三个必须补上的机制
如果你打算把这个包改造成更接近 TCP 的东西，下面三个机制是绕不开的。第一是滑动窗口：发送方维护一个窗口，窗口内的包可以连续发，收到累积 ACK 后窗口右移。第二是快速重传：收到三个重复 ACK 就立即重传，不等超时。第三是拥塞控制：慢启动、拥塞避免、快恢复，防止把网络压垮。下面是一个简化滑动窗口发送方的骨架：
# 滑动窗口发送方骨架：窗口大小 N，累积确认 def sliding_window_sender(link, data, N=4, timeout=1.0): base = 0 # 窗口左边界 next_seq = 0 # 下一个待发序号 while base < len(data): # 窗口内且未发送的包，连续发出去 while next_seq < base + N and next_seq < len(data): link.send(make_packet(next_seq, data[next_seq])) next_seq += 1 ack = link.recv_ack() if ack is not None and ack.seq >= base: base = ack.seq + 1 # 累积确认，窗口右移 elif timer_expired(): # 超时：重传窗口内所有未确认包 for s in range(base, next_seq): link.send(make_packet(s, data[s])) start_timer(timeout)逻辑说明：base是窗口左边界，next_seq是下一个可用序号，base + N是窗口右边界。收到ack.seq >= base时，说明该序号及之前的包都被确认，窗口整体右移。参数说明：N是窗口大小，设太小退化成停等，设太大可能压垮接收方缓冲区；常见做法是从 4 开始，观察接收方日志有没有OUT_OF_ORDER或缓冲区溢出。超时重传时重传整个窗口，这是简化处理，真实 TCP 会结合快速重传只重传丢失的那个包。
3.3 用 Wireshark 对照真实 TCP：抓包看 seq 和 ack 的跳变
如果你手边有真实网络环境，可以一边跑模拟，一边用 Wireshark 抓本机回环或局域网流量，对照看真实 TCP 的 seq 和 ack 是怎么跳的。常见做法是：在 Wireshark 过滤tcp.port == 你的端口，然后观察三次握手后第一个数据包的Seq和Ack，再对比 RDT 日志里的seq=0/1。真实 TCP 的序号是字节流序号，不是包序号，所以你会看到Seq每次增加的是 payload 长度，而不是加 1。这个差异是很多人从 RDT 过渡到 TCP 时第一个翻车点：以为序号是包编号，结果算窗口时对不上。参数上，Wireshark 的tcp.analysis.retransmission过滤器能直接标出重传包，和 RDT 日志里的RESEND对应着看，理解会快很多。
4. 避坑与排查：TCP-RDT2.2.zip 跑不通时先看这五条
4.1 现象：启动就报端口被占用，换端口也没用
原因：模拟器可能默认绑定了固定端口，或者上一次进程没退干净，端口还处于 TIME_WAIT。解决：先lsof -i :端口或netstat -ano | findstr 端口找到占用进程，杀掉；如果确认是 TIME_WAIT，在代码里设置SO_REUSEADDR，或者直接换一个不常用端口，比如 18080 而不是 8080。
4.2 现象：日志里一直 TIMEOUT，但接收方说收到了包
原因：ACK 在回程链路上丢了，或者接收方发的 ACK 序号不对，发送方不认。解决：先看接收方日志有没有SEND ack，有的话再看发送方有没有RCV ack；如果发送方没收到，把回程丢包率单独调低验证。另一个常见原因是 ACK 序号比较逻辑写错，比如用了ack.seq == seq + 1而 RDT 2.2 是 0/1 交替，应该比较ack.seq == seq。
4.3 现象：无丢包时吞吐正常，一加丢包就卡死
原因：超时时间设得太短，重传包和原包在链路里撞车，接收方收到重复包后可能反复发同一个 ACK，发送方陷入重传循环。解决：把timeout调到至少2 * delay + 50ms，并在接收方加去重逻辑：如果收到的 seq 和上次相同，只重发 ACK，不重复交付数据。
4.4 现象：接收方日志出现 OUT_OF_ORDER，但发送方说没乱序
原因：发送方窗口滑动逻辑有 bug，比如base更新时用了ack.seq而不是ack.seq + 1，导致窗口左边界少移一位，后续包序号整体错位。解决：在发送方每次更新base后打印base和next_seq，对照接收方期望的序号；RDT 2.2 里序号只有 0/1，窗口滑动后要确保seq = 1 - seq的逻辑和 ACK 匹配。
4.5 现象：改大窗口后程序内存暴涨或崩溃
原因：滑动窗口实现里把未确认包全存在列表里，窗口设成 1000 后列表无限增长，或者接收方缓冲区没做上限。解决：给发送方未确认队列设上限，等于窗口大小；接收方缓冲区也设上限，满了就丢弃并发 NAK 或重复 ACK。参数上，窗口大小不要超过接收方缓冲区能容纳的包数，常见嵌入式场景窗口设 4 到 16 就够。
5. 把 RDT 2.2 当标尺：三个验证技巧和我的调试习惯
第一个技巧是「丢包率扫描」。不要只跑一个丢包率，用脚本从 0 到 0.5 每隔 0.05 跑一次，记录每次的总传输时间和重传次数，画一条曲线。你会看到丢包率超过某个点后，停等协议的重传次数指数上升，传输时间急剧拉长。这个拐点就是停等协议的实用边界，也是你理解 TCP 为什么要做拥塞控制的直观入口。下面是一个批量扫描的脚本骨架：
import subprocess results = [] for loss in [i/20 for i in range(11)]: # 0.00 到 0.50 out = subprocess.run( ["python", "rdt_sim.py", "--loss", str(loss), "--delay", "50"], capture_output=True, text=True ) # 从输出里解析总时间和重传次数 total_time = parse_total_time(out.stdout) resends = parse_resend_count(out.stdout) results.append((loss, total_time, resends)) print(f"loss={loss:.2f} time={total_time:.2f}s resends={resends}") # 找拐点：重传次数突然翻倍的位置 for i in range(1, len(results)): if results[i][2] > 2 * results[i-1][2]: print(f"拐点大约在 loss={results[i][0]:.2f}")逻辑说明：subprocess调用模拟器，capture_output抓日志，然后从日志里正则提取总时间和重传次数。参数说明：loss步长 0.05 足够看出趋势；delay固定 50ms 是为了排除延迟变化干扰。跑完你会得到一张表，比任何教科书上的曲线都直观。
第二个技巧是「序号位宽实验」。RDT 2.2 用 1 位序号，你可以在代码里把序号改成 2 位、3 位，观察在什么丢包模式下会出现序号回绕导致的接收方误判。这个实验能帮你理解 TCP 为什么序号要用 32 位，以及为什么在高带宽延迟积网络里序号回绕是个真实风险。
第三个技巧是「日志时间戳对齐」。把发送方和接收方的日志按时间戳合并，用sort -m或 Python 的heapq.merge排成一条时间线，你会清楚看到「发送 → 丢失 → 超时 → 重传 → ACK」的完整因果链。我一般会把这个合并日志存成 CSV，方便后面用表格工具筛。
最后一个习惯：每次改参数前，先备份一份能跑通的配置和日志。RDT 这类实验最容易出现「改了一个参数，之前能跑的现在跑不通，还不知道改了啥」。我吃过这个亏，后来养成习惯，改之前cp config.yaml config.yaml.bak，日志按loss_delay_时间戳命名，回头对比时省很多事。这个方案值不值得做？如果你只是想调通一个 TCP 通信 demo，它可能偏底层；但如果你想真正搞懂 tcp 协议栈里可靠传输那一层怎么工作，花一个周末把TCP-RDT2.2.zip跑透、改透，比看十篇讲三次握手的文章都管用。希望帮到你。
本文还有配套的精品资源，点击获取
