简介这份资源是燕山大学计算机网络课程三级项目的TCP传输数据包实践工程面向正在学习计算机网络、需要动手实现可靠传输协议的高校学生与网络编程初学者。项目围绕TCP连接建立、数据分片重组、流量控制、拥塞控制、数据确认与连接释放等核心机制展开要求通过socket接口编程实现客户端与服务器之间的完整通信流程并模拟不同网络环境测试协议性能。压缩包共60个文件约27.88MB包含cpp源码、h头文件、sln解决方案与vcxproj工程文件、exe可执行程序以及pdb、obj、ipch、ilk等编译调试中间产物和tlog、log运行日志覆盖从源码到可运行程序的完整链路。目前已有1354人学习下载。读者可直接运行工程观察三次握手、四次挥手及慢启动、快速重传等算法的实际表现也可基于现有代码修改窗口参数、注入丢包场景深入理解TCP在不可靠网络中的可靠性保障思路适合作为课程设计参考与网络编程练手素材。1. 从抓包到重传一份能跑通的 TCP 数据包传输项目长什么样很多人学完计算机网络TCP 三次握手、滑动窗口、拥塞控制背得滚瓜烂熟真让你写一个能收发数据包、能处理丢包重传的程序立马卡壳。这份「计算机网络三级项目」就是冲着这个痛点来的——它把 TCP 传输数据包这件事从课本概念拽到了可运行的代码层面。项目面向的是计算机相关专业做课程设计的学生以及想补网络编程实战的开发者。核心工作围绕数据包的封装、发送、接收、确认、超时重传这条链路展开技术栈以 C/C 或 Python 的 socket 编程为主配合原始套接字或传输层接口来模拟 TCP 的可靠传输机制。你拿到手能直接编译运行看到数据从一端发出、在另一端被正确重组中间还能人为制造丢包来观察重传逻辑。这不是一个调库就完事的 Demo而是需要你理解每一个字节怎么流动的工程练习。2. 项目架构拆解发送端、接收端与可靠传输层怎么分工2.1 整体模块划分与数据流向这个项目的架构并不复杂但分工很清晰。典型做法是拆成三个层次应用层负责产生和消费数据可靠传输层负责把不可靠的字节流变成可靠的报文序列底层网络接口负责实际的 sendto 和 recvfrom。发送端和接收端各自独立运行通过 UDP socket 或原始套接字通信在用户态自己实现 TCP 的确认、重传、排序机制。数据流向是这样的应用层调用 send 接口写入一块数据传输层把它切成固定大小的段给每个段编号序列号然后封装成自定义的报文头加数据载荷通过底层 socket 发出去。接收端收到后先校验再按序列号排序把有序数据交给应用层同时回一个 ACK 告诉发送端「我收到了哪些」。发送端维护一个发送窗口窗口内的段发出去后启动定时器超时没收到 ACK 就重传。我一般会把报文头设计成定长结构包含序列号、确认号、标志位、窗口大小、校验和这几个字段。这样解析起来简单也方便调试时用十六进制工具直接看。// packet.h - 自定义报文头结构 typedef struct { uint32_t seq_num; // 序列号标识当前段第一个字节的编号 uint32_t ack_num; // 确认号期望收到的下一个字节编号 uint16_t flags; // 标志位SYN/FIN/ACK/DATA uint16_t window; // 接收窗口大小用于流量控制 uint16_t checksum; // 校验和检测数据是否损坏 uint16_t data_len; // 数据载荷长度 } PacketHeader;这个结构体是整个项目的核心数据结构。seq_num 和 ack_num 各占 4 字节和真实 TCP 头保持一致的设计思路方便你对照课本理解。flags 用位掩码表示不同类型的报文比如 0x01 表示数据包、0x02 表示 ACK、0x04 表示 SYN。window 字段让接收端能告诉发送端自己还能吃下多少数据这就是滑动窗口的落地。checksum 用简单的累加取反实现即可重点是让你理解校验的流程不必追求工业级强度。2.2 发送端的状态机与超时管理发送端不是简单地「发出去就完事」它需要维护一个状态机来跟踪每个已发送但未确认的段。常见做法是用一个数组或链表保存窗口内所有在途段的信息包括序列号、发送时间、重传次数。// sender.c - 发送窗口条目 typedef struct { uint32_t seq; // 该段的起始序列号 uint32_t len; // 数据长度 time_t send_time; // 发送时刻用于计算 RTT int retries; // 已重传次数 int acked; // 是否已被确认 } WindowEntry; WindowEntry window[MAX_WINDOW]; // 发送窗口 int window_base 0; // 窗口左边界 int window_next 0; // 下一个可用序列号发送端主循环的逻辑是只要窗口没满就从应用层缓冲区取数据、封装、发送、记录到窗口里。然后检查窗口内每个条目如果当前时间减去 send_time 超过了 RTO重传超时时间就重传该段并增加 retries 计数。如果 retries 超过上限比如 10 次就认为连接断了报错退出。RTO 的计算是这里的玄学点。最简单的做法是固定一个值比如 500ms。但更合理的做法是参考 Jacobson 算法根据 RTT 的平滑值和偏差动态调整。课程项目里用固定值也能跑但如果你想拿高分建议实现自适应 RTO。// 自适应 RTO 计算简化版 Jacobson 算法 double srtt 0.0; // 平滑 RTT double rttvar 0.0; // RTT 偏差 double rto 1.0; // 初始 RTO 设为 1 秒 void update_rto(double measured_rtt) { double alpha 0.125, beta 0.25; rttvar (1 - beta) * rttvar beta * fabs(srtt - measured_rtt); srtt (1 - alpha) * srtt alpha * measured_rtt; rto srtt 4 * rttvar; // RTO SRTT 4 * RTTVAR if (rto 0.1) rto 0.1; // 下限保护 }这段代码是发送端可靠性的关键。measured_rtt 通过记录发送时刻和收到 ACK 的时刻相减得到。srtt 是 RTT 的指数加权移动平均rttvar 是偏差的移动平均。最终 RTO 取 srtt 加四倍偏差这样在网络抖动时能自动拉长超时时间避免不必要的重传。参数 alpha 和 beta 是经验值alpha 控制平滑程度beta 控制偏差响应速度一般不用改。2.3 接收端的排序与确认策略接收端要做的事情比发送端琐碎收到包先校验校验不过直接丢校验过了看序列号如果是期望的序号就交给应用层并推进期望序号如果不是就缓存起来等缺失的段到达。# receiver.py - 接收端核心逻辑 expected_seq 0 buffer {} # 乱序缓存 {seq: data} def on_packet_received(pkt): global expected_seq if not verify_checksum(pkt): return # 校验失败静默丢弃 if pkt.seq expected_seq: deliver_to_app(pkt.data) expected_seq len(pkt.data) # 检查缓存里有没有后续的段可以连续交付 while expected_seq in buffer: deliver_to_app(buffer.pop(expected_seq)) expected_seq len(buffer[expected_seq - len(buffer[expected_seq])]) elif pkt.seq expected_seq: buffer[pkt.seq] pkt.data # 乱序到达先缓存 # 无论哪种情况都要回 ACK告诉发送端当前期望的序号 send_ack(expected_seq)接收端的确认策略是累积确认ACK 里的 ack_num 表示「我期望收到的下一个字节编号」隐含意思是这个编号之前的所有数据都收到了。这种设计简化了发送端的窗口管理一个 ACK 可以确认多个段。但缺点是如果中间丢了一个段后面的段即使收到了也只能缓存不能交付给应用层这就是所谓的队头阻塞。接收窗口的大小决定了缓存能有多大。如果窗口设得太小发送端频繁等待吞吐量上不去设得太大内存占用高而且丢包后重传的代价更大。课程项目里窗口设成 8 到 16 个段比较合适既能演示滑动效果又不会让调试变得太复杂。3. 环境搭建与运行从编译到看到第一个数据包3.1 依赖安装与编译步骤这个项目对环境的依赖很少核心就是 C 编译器或 Python 运行时加上标准网络库。如果你走 C 路线Linux 下需要 gcc 和 makeWindows 下可以用 MinGW 或 WSL。Python 路线更简单标准库里的 socket、struct、threading 就够了不需要额外装包。# Linux 下编译 C 版本 sudo apt update sudo apt install build-essential cd tcp-packet-project make clean make # 生成 sender 和 receiver 两个可执行文件编译时注意看 Makefile 里的链接选项。如果用了 pthread 做多线程需要加 -lpthread如果用了数学库计算 RTO需要加 -lm。常见翻车点是忘了链接这些库报一堆 undefined reference新手容易在这里卡住。Python 版本不需要编译但要注意版本。代码里如果用了 f-string 或者类型注解需要 Python 3.6 以上。我一般会在项目根目录放一个 requirements.txt虽然标准库不需要 pip 安装但写上 python_requires3.6 能避免别人用老版本跑出语法错误。3.2 启动接收端与发送端的正确姿势运行顺序很重要先启动接收端再启动发送端。接收端绑定一个本地端口比如 8888然后进入循环等待数据。发送端指定目标 IP 和端口开始发送。# 终端 1启动接收端 ./receiver --port 8888 --output received_file.bin # 终端 2启动发送端 ./sender --host 127.0.0.1 --port 8888 --input test_data.bin --window 8参数说明--port 是接收端监听的端口--output 指定接收到的数据写到哪里--host 是目标地址本机测试用 127.0.0.1--input 是要发送的文件--window 是发送窗口大小单位是段数。如果你想模拟丢包可以加一个 --loss-rate 0.1 参数让发送端随机丢弃 10% 的包观察重传是否正常工作。启动后你应该能看到类似这样的输出[SENDER] Sending file test_data.bin (10240 bytes) [SENDER] Window size: 8 segments, Segment size: 1024 bytes [SENDER] Sent segment 0 (seq0, len1024) [SENDER] Sent segment 1 (seq1024, len1024) ... [RECEIVER] Received segment 0 (seq0), delivering to app [RECEIVER] Sent ACK for seq1024 [SENDER] Received ACK for seq1024, window base moved to 1如果只看到发送没有接收先检查防火墙是不是拦了 UDP 包。Linux 下用sudo ufw status看一眼Windows 下检查入站规则。另一个常见问题是绑定了 127.0.0.1 却想跨机通信那肯定收不到得绑 0.0.0.0。3.3 用抓包工具验证传输过程代码跑通了不代表逻辑对了。我强烈建议开一个 Wireshark 或者 tcpdump 抓包亲眼看看你自定义的报文长什么样。因为用的是非标准协议Wireshark 默认解析不了但你可以看原始十六进制对照你的 PacketHeader 结构逐字段核对。# 用 tcpdump 抓取 8888 端口的 UDP 包 sudo tcpdump -i lo port 8888 -X -c 20-X 参数会把每个包以十六进制加 ASCII 的形式打印出来。你重点看前 16 个字节那应该正好是你的 PacketHeader。序列号是不是递增的、ACK 号是不是符合预期、校验和字段是不是在变一目了然。这个步骤能帮你快速定位「代码逻辑看起来对但实际发出去的包不对」这类问题。4. 核心机制实现序列号、确认与重传的代码级细节4.1 序列号分配与字节流语义TCP 的序列号不是按段编号的而是按字节编号。第一个字节的序列号是初始序列号ISN第二个段的序列号等于 ISN 加上第一个段的数据长度。这个设计让接收端可以用累积确认一个 ACK 确认一大片数据。// 发送端序列号分配 uint32_t next_seq ISN; // 初始序列号通常随机生成 for (int i 0; i data_len; i SEGMENT_SIZE) { int seg_len min(SEGMENT_SIZE, data_len - i); PacketHeader hdr; hdr.seq_num next_seq; hdr.data_len seg_len; // ... 填充其他字段 send_packet(hdr, data i, seg_len); next_seq seg_len; // 序列号按字节递增 }注意 next_seq 每次增加的是 seg_len 而不是 1。如果你写成 next_seq接收端会认为每个段只包含一个字节数据全乱套。这是新手最容易犯的错误之一而且症状很隐蔽——程序不报错但接收到的文件大小不对或者内容错位。ISN 的选择也有讲究。真实 TCP 用随机 ISN 是为了安全防止序列号预测攻击。课程项目里你可以固定一个值方便调试但更好的做法是用时间戳或者随机数生成这样更贴近真实实现。4.2 超时重传的定时器管理发送端需要为每个在途段维护一个定时器。最朴素的做法是每次主循环遍历整个窗口检查每个段的发送时间。这种轮询方式实现简单但窗口大了之后效率低。更优雅的做法是用最小堆或者时间轮来管理定时器不过课程项目里轮询足够了。// 轮询检查超时并重传 void check_retransmit(WindowEntry *window, int base, int next) { time_t now time(NULL); for (int i base; i next; i) { if (window[i].acked) continue; double elapsed difftime(now, window[i].send_time); if (elapsed current_rto) { if (window[i].retries MAX_RETRIES) { fprintf(stderr, Segment %u failed after %d retries\n, window[i].seq, MAX_RETRIES); exit(1); } printf([SENDER] Timeout for seq%u, retransmitting (attempt %d)\n, window[i].seq, window[i].retries 1); resend_segment(window[i]); window[i].send_time now; window[i].retries; } } }这段代码里 current_rto 是动态更新的每次收到 ACK 后调用 update_rto 重新计算。MAX_RETRIES 一般设 10 到 15 次超过就认为网络不可恢复。重传时不要重置 retries 计数否则会无限重传。另外注意重传的段序列号不变数据也不变只是重新发一遍。有个细节容易忽略重传时 RTO 应该翻倍指数退避避免网络拥塞时疯狂重传加剧拥塞。你可以在 retries 增加的同时把 current_rto 乘以 2收到新 ACK 后再恢复。4.3 接收窗口与流量控制接收端不是无限缓冲的它需要告诉发送端自己还能接收多少数据。这就是窗口字段的作用。接收端在每次回 ACK 时把当前剩余缓冲区大小填进 window 字段。# 接收端窗口更新 RECV_BUFFER_SIZE 65536 # 64KB 接收缓冲区 used_buffer len(buffer) * SEGMENT_SIZE (expected_seq - last_delivered_seq) advertised_window RECV_BUFFER_SIZE - used_buffer ack_pkt.window max(0, advertised_window // SEGMENT_SIZE) # 以段为单位发送端收到 ACK 后取 min(自己的拥塞窗口, 接收端通告的窗口) 作为实际可发送窗口。如果接收端通告窗口为 0发送端就停止发送启动一个坚持定时器persist timer定期发一个探测包询问接收端窗口是否恢复。这个机制防止了死锁接收端缓冲区满了发不出 ACK发送端等 ACK 不敢发数据两边干等。课程项目里如果只做单向传输流量控制可以简化。但如果你想拿高分把零窗口探测也实现了答辩时能讲出东西来。5. 避坑与排查那些让我熬夜的报错和异常5.1 现象发送端显示发送成功接收端一个包都没收到原因通常有三个一是地址绑错了发送端往 127.0.0.1 发但接收端绑的是实际网卡 IP二是防火墙拦截尤其是 Windows 下首次运行会弹窗询问是否允许网络访问点了拒绝就静默丢包三是端口被占用接收端 bind 失败但没检查返回值程序继续跑但实际没绑定成功。解决接收端 bind 后检查返回值失败就打印 errno。Linux 下用ss -ulnp | grep 8888确认端口监听状态。跨机测试时发送端和接收端要互相 ping 通且接收端绑 0.0.0.0 而不是 127.0.0.1。5.2 现象文件传完了但大小对不上或者内容错乱原因多半是序列号计算错误。比如发送端按段递增序列号而不是按字节递增或者接收端交付数据时没有按序列号排序直接把到达顺序当成了正确顺序。另一个可能是缓冲区溢出接收端缓存乱序包的数组开太小后面的包覆盖了前面的。解决在发送端和接收端都加日志打印每个包的 seq 和 len。传输完成后对比发送的总字节数和接收的总字节数。如果接收端有乱序缓存确保缓存的数据结构是字典或哈希表而不是固定数组避免覆盖。5.3 现象重传风暴同一个包被反复发送几十次原因是 ACK 丢失或者 ACK 处理逻辑有 bug。发送端发了包接收端回了 ACK但 ACK 在路上丢了发送端超时重传。接收端收到重复包后又回 ACK但如果接收端的 ACK 发送逻辑有问题比如只在收到新数据时才回 ACK重复包就被静默丢弃发送端永远等不到 ACK。解决接收端收到重复包seq 小于 expected_seq时也要回 ACKACK 号填当前的 expected_seq。这是 TCP 的规矩只要收到包就回 ACK不管是不是重复的。另外检查发送端的 ACK 处理确保收到 ACK 后正确滑动窗口不要把已确认的段又标记为未确认。5.4 现象程序跑一会儿就卡死没有任何输出原因是死锁。常见场景是发送端和接收端在同一个进程里用多线程实现发送线程持有窗口锁等待 ACK接收线程持有 ACK 锁等待窗口更新互相等。另一个场景是接收端缓冲区满了不再回 ACK发送端窗口耗尽停止发送两边僵住。解决多线程版本里锁的粒度要小不要在持锁期间做网络 IO。接收端要定期检查缓冲区即使没有新数据到达也要回 ACK 通告窗口。加一个看门狗线程如果超过一定时间没有任何进展就打印当前状态并退出方便定位。5.5 现象本机测试正常跨机测试大量丢包原因是 MTU 不匹配或者网络路径上的 MTU 更小。你发的包如果超过路径 MTU会被分片分片后任何一个片段丢失整个包就废了。本机回环 MTU 很大通常 65536跨机可能只有 1500。解决把段大小控制在 1400 字节以内留出头部的空间。或者实现路径 MTU 发现但这对于课程项目来说过于复杂。简单粗暴的做法是段大小设 1024基本不会触发分片。6. 二次开发与调试技巧从能跑到能讲清楚拿到这个项目跑通只是第一步。真正让它变成你的东西得动手改几个地方。我一般会从三个方向入手加日志、改参数、扩功能。加日志是最快见效的。在发送端和接收端的每个关键路径上打时间戳和序列号输出成 CSV 格式然后用 Python 画个图横轴是时间纵轴是序列号你就能看到数据包的发送轨迹和重传点。这个图往报告里一放比任何文字描述都有说服力。# 解析日志并绘制序列号-时间图 import matplotlib.pyplot as plt import csv times, seqs, types [], [], [] with open(sender_log.csv) as f: for row in csv.DictReader(f): times.append(float(row[timestamp])) seqs.append(int(row[seq])) types.append(row[type]) # send or retransmit plt.figure(figsize(12, 6)) for t, s, tp in zip(times, seqs, types): color blue if tp send else red plt.scatter(t, s, ccolor, s10) plt.xlabel(Time (s)) plt.ylabel(Sequence Number) plt.title(TCP Packet Transmission Trace) plt.savefig(trace.png, dpi150)这张图能直观暴露很多问题如果红线密集出现说明重传频繁RTO 可能设小了如果序列号增长呈阶梯状说明窗口经常满吞吐量受限于窗口大小如果序列号长时间不增长说明卡住了可能是死锁或者 ACK 丢失。改参数是第二个方向。把窗口大小从 8 改成 1、4、16、64各跑一遍记录完成时间。你会看到窗口越大吞吐越高但到一定程度后收益递减因为带宽或者 RTO 成了瓶颈。把 RTO 从固定值改成自适应对比重传次数通常能减少 30% 以上的无效重传。这些对比数据是报告里最值钱的部分。扩功能是第三个方向也是区分「抄了一遍」和「真懂了」的分水岭。我建议加一个简单的拥塞控制维护一个拥塞窗口 cwnd初始为 1每收到一个 ACK 就 cwnd慢启动直到达到阈值 ssthresh 后改为每 RTT 加一拥塞避免。如果发生超时ssthresh 设为 cwnd 的一半cwnd 重置为 1。这个逻辑不到 50 行代码但能让你的项目从「模拟 TCP」变成「实现了 TCP 的核心机制」。// 简化的拥塞控制 int cwnd 1; // 拥塞窗口单位是段 int ssthresh 16; // 慢启动阈值 void on_ack_received() { if (cwnd ssthresh) { cwnd * 2; // 慢启动指数增长 } else { cwnd 1; // 拥塞避免线性增长 } if (cwnd MAX_CWND) cwnd MAX_CWND; } void on_timeout() { ssthresh cwnd / 2; // 阈值减半 cwnd 1; // 窗口重置 }实际发送时取 min(cwnd, advertised_window) 作为可发送的段数。这样在网络状况好时窗口快速打开遇到丢包时迅速收缩避免加剧拥塞。你可以在丢包率 5% 的环境下对比开和关拥塞控制的吞吐量差距会非常明显。最后说一个调试习惯每次改完代码先在本机用 --loss-rate 0 跑一遍确认基本功能没坏再用 --loss-rate 0.1 跑一遍看重传逻辑最后跨机跑一遍看真实网络下的表现。这三步走完基本能覆盖 90% 的问题。从那以后我每次提交代码前都强制走一遍这个流程省下了大量回头排查的时间。希望帮到你。本文还有配套的精品资源点击获取