简介：TCP-RDT3.0.zip 是一份面向计算机网络课程学习者与实验教学场景的配套资料，围绕可靠数据传输协议 RDT 3.0 展开，适合正在理解 TCP 底层机制、需要动手实现停等 ARQ 与差错恢复逻辑的学生或教师使用。压缩包共 16 个文件，约 1.04MB，以 java 源码与 class 编译文件为主体，辅以 txt 日志、tcp 配置、project 与 classpath 等工程文件，整体构成一个可直接导入 IDE 运行的实验工程。资源中涉及序号管理、校验检测、超时重传等核心环节，并预留了错误注入与性能分析的操作空间，便于读者在丢包、乱序、数据篡改等条件下观察协议行为。目前已有 442 人学习下载，可作为课程实验的参考实现，帮助读者从代码层面吃透 RDT 3.0 的发送与接收流程，为后续深入理解 TCP 协议打下基础。
1. 从 TCP-RDT3.0.zip 说起：一个把可靠传输讲透的仿真工程
第一次看到TCP-RDT3.0.zip这个包名，很多人会以为它只是某门课的第三次作业压缩包，解压完交完报告就删。但真正做过网络协议实现的人会盯住RDT这三个字母——Reliable Data Transfer，可靠数据传输。它不是一个能直接跑在公网上的协议栈，而是一套把「不可靠信道之上如何做到不丢、不重、不乱」拆到最小可运行单元的仿真工程。TCP-RDT3.0 通常出现在计算机网络课程的协议实现环节，用模拟的丢包、乱序、超时来逼你亲手写出滑动窗口、确认应答、重传定时器这些平时被内核封装成黑匣子的东西。它适合两类人：一类是刚学完 TCP 理论、想验证自己到底懂没懂的在校生；另一类是工作几年、天天调 socket 却说不清拥塞窗口怎么变的工程师。这个包的价值不在于代码多优雅，而在于它把可靠传输的每个决策点都暴露给你，让你在本地就能复现丢包重传的全过程。
2. TCP-RDT3.0 的协议骨架：从停等协议到滑动窗口的演进逻辑
2.1 为什么 RDT3.0 是理解 TCP 的最小切口
可靠传输这件事，理论上有三个绕不开的敌人：比特差错、丢包、乱序。RDT1.0 假设信道完美，RDT2.0 引入校验和与 ACK/NAK 处理比特差错，RDT2.1 加上序号解决 ACK 丢失导致的重复，RDT2.2 去掉 NAK 只用 ACK，RDT3.0 才引入超时重传——因为信道可能整个把包吞掉，接收方根本没收到，自然不会回 NAK。到了这一步，发送方必须自己设一个定时器，超时没收到 ACK 就重发。这就是 TCP-RDT3.0 的核心：停等协议 + 超时重传。
停等协议的效率极低，发一个包等一个 ACK，链路利用率约等于(L/R) / (RTT + L/R)，在长肥管道上惨不忍睹。所以真实的 TCP 不会用停等，而是用流水线：滑动窗口。TCP-RDT3.0 这个包名里的 3.0 通常指停等版本，但很多实现会在此基础上让你扩展成 GBN（Go-Back-N）或 SR（Selective Repeat）。理解这个演进链条，比死记 TCP 头部字段有用得多，因为你能看到每个机制是被什么具体问题逼出来的。
我一般建议先跑通停等版本，再动手改窗口。直接上滑动窗口，很容易在序号回绕和缓冲区管理上翻车。
2.2 解压后先看什么：目录结构与关键文件定位
拿到TCP-RDT3.0.zip，不要急着编译。先解压，用tree或find把结构看清楚。典型布局大致是这样：
unzip TCP-RDT3.0.zip -d tcp-rdt3 cd tcp-rdt3 find . -maxdepth 2 -type f | sort常见会看到几类文件：sender和receiver两个主程序，一个network_simulator或channel模块负责制造丢包和延迟，若干.h头文件定义报文结构和常量，可能还有Makefile或CMakeLists.txt。先读头文件里的报文格式定义，这是整个协议的契约。
/* packet.h 典型结构，字段名以实际包为准 */ #define PKT_SIZE 512 typedef struct { int seq; /* 序号，停等协议下只有 0/1 */ int ack; /* 确认号 */ int checksum; /* 校验和，用于检测比特差错 */ char data[PKT_SIZE]; } Packet;序号字段是理解一切的关键。停等协议下序号只需 1 位（0 和 1 交替），因为发送方在收到当前包的 ACK 前不会发下一个。校验和字段决定你能不能检测出比特翻转。ack 字段在停等里通常用标志位表示，在滑动窗口里才承载累积确认的含义。把这些字段和教材上的状态机对应起来，代码就不再是天书。
2.3 编译与最小可运行验证
定位到构建文件后，先做一次干净编译，确认工具链没问题：
make clean && make # 若用 CMake # mkdir build && cd build && cmake .. && make编译通过后，不要直接开两个终端对跑。先看有没有自带的测试脚本或README里的运行示例。典型启动方式是先起接收方，再起发送方，中间挂一个模拟信道：
# 终端 1：接收方监听 ./receiver -p 9000 -o output.txt # 终端 2：发送方，指定目标地址和要传的文件 ./sender -h 127.0.0.1 -p 9000 -f input.txt如果包里有信道模拟参数，通常通过环境变量或命令行传入，比如丢包率-l 0.1、延迟-d 50。第一次跑，把丢包率设为 0，确认数据能完整传过去，输出文件和输入文件diff一致。这一步是基线，基线不通，后面所有调试都是白费。
提示：先确认
diff input.txt output.txt无差异，再开始加丢包。基线不干净，后面分不清是协议 bug 还是环境问题。
3. 亲手实现超时重传与滑动窗口：参数怎么设、代码怎么写
3.1 超时定时器：RTT 估计与 RTO 的计算
超时重传的成败几乎全在 RTO（Retransmission Timeout）这一个参数上。设太短，ACK 还没回来就重发，网络里塞满重复包；设太长，丢包后干等，吞吐量塌方。TCP 用的是 Jacobson/Karels 算法，动态估计 RTT：
# RTO 动态估计，RFC 6298 简化版 ALPHA = 0.125 # RTT 平滑因子 BETA = 0.25 # 偏差平滑因子 MIN_RTO = 0.2 # 最小 RTO，秒 MAX_RTO = 60.0 # 最大 RTO，秒 class RTOEstimator: def __init__(self): self.srtt = None # 平滑 RTT self.rttvar = None # RTT 偏差 self.rto = 1.0 # 初始 RTO 保守取 1 秒 def update(self, measured_rtt): if self.srtt is None: # 第一个样本：SRTT 直接取测量值，偏差取一半 self.srtt = measured_rtt self.rttvar = measured_rtt / 2 else: self.rttvar = (1 - BETA) * self.rttvar + BETA * abs(self.srtt - measured_rtt) self.srtt = (1 - ALPHA) * self.srtt + ALPHA * measured_rtt self.rto = self.srtt + 4 * self.rttvar # 夹在上下限之间，防止极端值 self.rto = max(MIN_RTO, min(MAX_RTO, self.rto)) return self.rtoALPHA和BETA是经验值，别乱改。4 * rttvar里的 4 是让 RTO 覆盖大部分 RTT 波动。MIN_RTO防止在低延迟局域网里 RTO 小到误判，MAX_RTO防止彻底卡死。关键坑在于：重传的包不能用它自己的 ACK 来更新 RTT，否则会把 RTT 估大，因为重传的 ACK 分不清是原始包还是重传包回的。Karn 算法就是干这个的——重传样本直接丢弃，不参与估计。
3.2 滑动窗口：发送窗口与接收窗口的配合
停等协议窗口大小为 1，滑动窗口把它放大到 N。发送方维护send_base（最早未确认序号）和next_seq（下一个可用序号），接收方维护rcv_base。GBN 的接收方只按序收，乱序直接丢；SR 的接收方有缓冲区，乱序先存着。
# GBN 发送方核心逻辑，窗口大小 N N = 4 # 窗口大小，序号空间需 >= N+1 class GBNSender: def __init__(self, n): self.N = n self.send_base = 0 self.next_seq = 0 self.buffer = {} # 已发送未确认的包 def can_send(self): # 窗口未满才能发新包 return self.next_seq < self.send_base + self.N def send(self, data): if self.can_send(): pkt = make_packet(self.next_seq, data) self.buffer[self.next_seq] = pkt self.next_seq += 1 channel.send(pkt) if self.send_base == self.next_seq - 1: start_timer() # 只为最早的未确认包起定时器 def on_ack(self, ack_num): # 累积确认：ack_num 之前的所有包都确认了 self.send_base = ack_num + 1 if self.send_base == self.next_seq: stop_timer() else: restart_timer() # 还有未确认包，重启定时器 def on_timeout(self): # 超时：回退重发所有未确认包 for seq in range(self.send_base, self.next_seq): channel.send(self.buffer[seq]) restart_timer()窗口大小N的选择直接决定吞吐量上限。理论上N >= (RTT * 带宽) / 包大小才能填满管道。序号空间必须大于窗口大小，GBN 要求序号空间 >= N + 1，否则新旧包序号混淆，接收方分不清是重传还是新数据。这是最经典的翻车点：窗口开 8，序号只用 0-7，重传时接收方把旧包当新包收，数据错乱还查不出来。
3.3 用丢包率参数做压力测试
协议写完了，得用不同丢包率验证。把信道模拟的丢包率从 0 逐步加到 0.3，观察吞吐量和重传次数：
for loss in 0 0.05 0.1 0.2 0.3; do echo "=== loss rate: $loss ===" ./sender -h 127.0.0.1 -p 9000 -f input.txt -l $loss -t 30 done重点看两个指标：传输完成时间和重传包占比。丢包率 0.1 时，GBN 的重传占比会明显高于 SR，因为一个包丢了后面全得重发。如果丢包率 0.3 时程序直接卡死，大概率是 RTO 没退避——连续超时应该把 RTO 翻倍（指数退避），而不是死守一个值。TCP 的 RTO 在连续超时时会rto = rto * 2，上限MAX_RTO，这个机制在 RDT3.0 里经常被漏掉。
注意：丢包率超过 0.2 后，停等协议的吞吐量会掉到理论值的 20% 以下，这不是 bug，是协议本身的效率上限。要对比就对比 GBN 和 SR 在同一丢包率下的差异。
4. 调试 TCP-RDT3.0 时最容易踩的五个坑
4.1 现象：数据传完了但文件末尾多出几个字节
原因通常是接收方在最后一个包之后没有正确判断文件结束。停等协议里，发送方发完最后一个数据包后，可能还需要发一个长度为 0 的结束包，或者用标志位标记 EOF。如果接收方只按包计数写文件，最后一个包的填充字节会被写进去。
解决：在报文头里加一个data_len字段，接收方按实际长度写，不按固定包大小写。或者约定一个特殊序号表示结束。
4.2 现象：丢包率一高就死锁，双方都在等
原因是 ACK 丢失后发送方超时重传，但接收方已经收到过这个包，回了一个重复 ACK，发送方没正确处理。停等协议下，接收方收到重复序号应该重发上一个 ACK，而不是丢弃。如果接收方直接丢，发送方永远等不到确认。
解决：接收方维护expected_seq，收到序号不等于期望值的包时，重发对上一个正确包的 ACK。这是 RDT2.1 就解决的问题，但手写时容易忘。
4.3 现象：校验和永远算不对
原因多半是校验和的计算范围搞错了。有的实现把校验和字段本身也算进去，有的用网络字节序有的用主机字节序。发送方算的时候把校验和字段置 0，接收方验证时把收到的校验和字段也置 0 再算一遍，两边必须一致。
解决：统一用uint16_t按 16 位累加，最后取反码。发送前把 checksum 字段清零再计算，接收方同样清零后计算再比对。
4.4 现象：窗口开大后传输速度反而变慢
原因是序号空间不够，导致接收方无法区分新旧包，大量重传。GBN 要求序号空间至少是窗口大小加一。如果窗口开 16，序号只有 0-15，第 16 个包发出去时序号回绕到 0，接收方以为是最早那个包的重传。
解决：把序号空间设为窗口大小的两倍以上，或者直接用 32 位序号。仿真里用seq % (2 * N)做回绕，确保任意时刻窗口内的序号不重复。
4.5 现象：程序跑一会儿就内存暴涨
原因是发送缓冲区只增不减。每次发送都把包存进 buffer，但收到 ACK 后没有清理已确认的包。长时间传输后 buffer 里堆了几万个已经确认的包。
解决：收到累积 ACK 后，把send_base之前的 buffer 条目全部删除。用字典的话del buffer[seq]，用列表的话移动起始索引。这个清理动作要放在每次 ACK 处理里，不能只在超时时做。
5. 从仿真到真实网络：把 RDT3.0 的认知迁移到 socket 编程
仿真跑通只是第一步，真正有价值的是把里面学到的参数直觉带到真实 socket 编程里。真实 TCP 的SO_RCVBUF和SO_SNDBUF就是接收窗口和发送窗口的物理体现，TCP_NODELAY关掉 Nagle 算法相当于让发送方不等累积数据直接发，TCP_QUICKACK控制 ACK 的延迟行为。这些选项在仿真里都有对应物。
一个具体的验证方法：用ss -i看真实连接的 RTT 和 cwnd，和你在仿真里估的 RTO 对比。
# 查看当前 TCP 连接的详细统计 ss -ti dst 10.0.0.1 # 输出里的 rtt、rto、cwnd、retrans 字段就是仿真里那几个变量的真实值如果仿真里你的 RTO 估计在 200ms 左右，真实连接的rto字段也应该在同一量级。差太多，说明 RTT 估计逻辑有问题。另一个技巧：把仿真里的丢包率设成和真实网络ss -ti里看到的retrans比例接近，再跑一遍，看吞吐量曲线是否吻合。吻合了，说明你的协议实现和内核 TCP 的行为逻辑一致。
我自己的习惯是，每写完一个协议版本，先不急着加功能，而是把丢包率从 0 到 0.5 扫一遍，记录每个点的完成时间，画一条曲线。这条曲线就是协议的性能指纹。下次改代码，曲线形状变了，立刻知道改对了还是改坏了。这个习惯帮我省了无数次「改了半天不知道有没有变好」的纠结。TCP-RDT3.0 这个包本身不大，但把它吃透，再去看真实 TCP 的拥塞控制、快速重传、SACK，会发现全是同一套逻辑的延伸。希望帮到你。
本文还有配套的精品资源，点击获取
