简介面向计算机网络课程学习者与计网实验设计者这份参考实现围绕“用UDP实现可靠传输”这一核心问题给出了完整的期中作业解决方案。项目以中山大学2021年计网期中大作业为背景覆盖UDP报头理解、错误检测、序列号与确认机制、超时重传、滑动窗口、流量控制乃至拥塞控制等关键点适合正在完成类似实验、需要参考C套接字编程或想深入理解ARQ协议落地方式的读者。压缩包共4个文件包含2个C源码文件服务端与客户端、1份PDF实验报告和1份Markdown说明文档整体大小466KB结构紧凑便于对照源码阅读实验报告。目前已有626人学习浏览代码配合报告可帮助快速理清停等ARQ、Go-Back-N、选择重传等策略在真实网络编程中的实现思路也为自定义可靠UDP方案提供了可扩展的起点。1. 用 UDP 实现可靠传输一份计网期中作业的 C 拆解很多人在学计算机网络时第一次真正动手写传输层逻辑并不是去改 TCP而是被要求用 UDP 实现可靠传输。这件事听起来很矛盾因为 UDP 本身就不可靠但中山大学 2021 年计网期中大作业就是这么出的用 C 写一个基于 UDP 的可靠传输程序。压缩包里的 Server_final.cpp、Client_final.cpp 和实验报告把序列号、ACK、超时重传、流量控制全都在 socket 层做了出来。跑通这套代码之后你对 TCP 里每个机制为什么存在会有一个非常具体的答案。这个项目适合正在做同类课程作业的学生也适合已经会写 UDP 聊天室、想补上可靠传输实现细节的开发者。我会从协议设计一路拆到代码细节和实测踩坑尽量让你照着能复现。2. 核心机制与选型ARQ、滑动窗口以及协议头设计2.1 UDP 不可靠的根源没有状态没有人通知你先看传输层协议本身的差异。UDP 报头只有 8 个字节包含源端口、目的端口、报文长度和校验和四个字段。它没有序列号没有确认序号没有任何标志位来表示 SYN、ACK、FIN 这类控制信息。发送端调用 sendto 之后内核把报文交给 IP 层就完事了既不会保存副本用于重传也不会等到对端确认后才释放资源。UDP 协议栈不维护任何连接状态自然也就不知道哪些包丢了、哪些包重复了、哪些包乱序了。接收端的处理链路同样简单。内核根据目的端口找到对应 socket把报文交给应用如果校验和错误就把包丢掉不通知发送端。这个丢包行为是静默的发送端的 recvfrom 永远不会知道你某条报文已经被接收端丢弃了。所以“UDP 不可靠”并不只体现在丢包上更核心的是它缺少一个反馈循环。TCP 里可靠传输依赖的确认号、累计确认、超时重传、滑动窗口在 UDP 里都要从零自己重建。因此基于 UDP 实现可靠传输本质上要做的事情是闭环发送方给每个包编序列号接收方收到后回 ACK发送方在超时时间内没收到 ACK 就重传接收方按序列号对数据包排序去重。单看每一项都不复杂但组合起来就需要你理解 ARQ 的状态机和时序边界。2.2 三种 ARQ 策略对比以及作业该选哪一种ARQ 家族里有三个经典成员停等 ARQStop-and-Wait、回退 N 协议Go-Back-NGBN和选择重传Selective RepeatSR。三者区别在于发送窗口大小和重传粒度代码复杂度差异非常大。停等 ARQ 是最符合直觉的方案发送方发一个包停下来等 ACK收到合法 ACK 后再发下一个。全程窗口大小为 1接收方不需要乱序缓冲区实现起来几行代码就能跑通。缺点是链路利用率低在网络往返时间 RTT 较大时大部分时间都花在等待 ACK 上。回退 N 协议允许发送窗口大于 1发送方可以连续发多个包但一旦某个序号超时就要回退到该序号并重传它之后的所有包接收方无需缓冲乱序数据。选择重传更进一步只重传真正丢失的包但接收方要为乱序包维护一个缓冲区发送方也要为每个在窗口内的包维护独立的超时定时器状态机复杂度是三者中最高的。方案发送窗口接收方缓冲重传单位代码量适用场景停等 ARQ1不需要单包最小教学演示、RTT 短回退 N大于 1不需要从丢包序号开始全部重传中等局域网、丢包率低选择重传大于 1需要只重传丢失的包较大丢包率高、窗口大这个作业包里的 Server_final.cpp 和 Client_final.cpp 没有直接上完整的选择重传而是用了停等加简单滑动窗口的组合数据包带序号接收方回 ACK发送方超时重传窗口大小通过 ACK 里的 window 字段控制。这个选型很聪明因为期中作业的核心考察点是“能否理解可靠传输的状态机”而不是“能否实现一个能打满带宽的传输协议”。把停等跑通后再把窗口从 1 调成固定值代码改动量并不大实验报告里却能把效率和可靠性两件事都写清楚。如果你的作业要求更严格我一般会建议先把停等实现到能传文件再按 GBN 扩展发送窗口最后才考虑 SR。不要在第一天就试图做完整的 SR乱序缓冲区的边界条件调试起来很容易让人想放弃。2.3 先定义协议头再写收发逻辑写 socket 程序最容易犯的错误是一上来就写 sendto 和 recvfrom结果两边协议字段对不上肉眼看了半天才发现少传了一个字节。正确顺序是先定义一份“线格式”也就是协议头。对课程作业来说协议头不需要像 TCP 那么复杂但下面几个字段是必须的包类型、序列号、确认号、校验和和接收窗口。#pragma pack(push, 1) struct PacketHeader { uint8_t type; // 0DATA, 1ACK uint16_t seq; // 数据包序列号 uint16_t ack; // 累积确认号 uint16_t checksum; // 全包校验和 uint16_t window; // 接收窗口剩余空间 }; struct Packet { PacketHeader header; char data[1024]; }; #pragma pack(pop)这里用#pragma pack(push, 1)是必须的它让结构体按 1 字节对齐避免编译器在字段之间插入填充字节。否则两边用不同编译器或不同平台时同一个结构体解析出来的字段位置就可能错位校验和永远对不上。seq和ack我用了 16 位对 1024 字节数据、窗口 32 的中期作业足够但如果你要传几百 MB 文件最好扩成 32 位否则序号回绕后容易和重传包混淆。checksum用累加和就行性能和正确性都能兼顾。window字段用于流量控制接收方通过它告诉发送方缓冲区还剩多少空间。协议头定义完之后收发双方的逻辑就只围绕这个固定字节布局展开后续代码会干净很多。3. 代码实现socket 初始化、超时重传与乱序缓冲3.1 服务端初始化bind 与接收超时的正确姿势服务端和客户端第一个区别在初始化。客户端只需要创建一个 UDP socket然后填好服务端地址就能 sendto服务端必须先 bind 到固定端口否则内核不知道把收到的报文投递到哪个 socket。这里以服务端为例SOCKET sock socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); if (sock INVALID_SOCKET) { printf(socket failed\n); return -1; } sockaddr_in addr{}; addr.sin_family AF_INET; addr.sin_port htons(9527); addr.sin_addr.s_addr htonl(INADDR_ANY); int opt 1; setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (char*)opt, sizeof(opt)); bind(sock, (sockaddr*)addr, sizeof(addr)); #ifdef _WIN32 int rto 500; // 单位毫秒 setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, (char*)rto, sizeof(rto)); #else struct timeval tv {0, 500000}; // 0.5 秒 setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, tv, sizeof(tv)); #endifsocket 的第一个参数AF_INET表示 IPv4第二个参数SOCK_DGRAM表示数据报套接字第三个参数传IPPROTO_UDP明确使用 UDP。htons(9527)把端口号从主机字节序转换成网络字节序htonl(INADDR_ANY)表示监听本机所有网卡。SO_REUSEADDR 是为了让程序在退出后能立刻重新绑定同一端口否则在 Linux 上跑完一次想立刻重启偶尔会报 Address already in use。SO_RCVTIMEO 是接收超时核心参数。如果不设置recvfrom 会在没有数据时永久阻塞发送端的超时重传逻辑就根本没机会执行。3.2 发送端主循环序列号、ACK 等待和重传判断客户端发送文件时最好按固定数据块切片比如 1024 字节一块每块带上递增序列号。每次只发一个包然后等 ACK这是停等 ARQ 的状态机。Packet pkt; pkt.header.type 0; // 数据包 pkt.header.seq next_seq; // 当前发送序号 pkt.header.ack last_ack; // 捎带确认 memcpy(pkt.data, file_buf, data_len); pkt.header.checksum cal_checksum((unsigned short*)pkt, sizeof(pkt)); int max_retries 10; int retries 0; while (true) { sendto(sock, (char*)pkt, HEADER_SIZE data_len, 0, (sockaddr*)peer, peer_len); Packet ack{}; int ret recvfrom(sock, (char*)ack, sizeof(ack), 0, nullptr, nullptr); if (ret 0 ack.header.ack pkt.header.seq) { next_seq; break; // 收到累计确认发出下一个包 } retries; if (retries max_retries) { printf(peer lost, give up\n); break; } // 超时或 ACK 序号不对重发同一个包 }注意 ACK 的确认号判断用了这是累计确认语义只要接收方 ACK 里的序号大于等于当前包序号说明这个包和它之前的所有包都已确认收到可以安全地发下一个。max_retries 10限制了单个包的重传次数防止对端程序崩溃后发送端无限重传变成死循环。实际场景里如果检测到网卡断开或对端进程退出重传超过一定次数就应该停止并报告错误而不是静默卡住。若你要调整性能可以把data_len从 1024 提到 4096但注意协议头里的window字段和接收缓冲WinSock的SO_RCVBUF都要相应调大否则大包容易被底层丢弃。3.3 接收端主循环校验、去重、回 ACK 和乱序排队接收端的职责有三个校验、去重、回 ACK。校验失败直接丢弃不做任何确认收到未被确认过的数据包后必须马上回 ACK如果数据包序号不是期望序号说明乱序到达需要先把数据放入缓冲区。while (true) { sockaddr_in sender; socklen_t sender_len sizeof(sender); int ret recvfrom(sock, (char*)pkt, sizeof(pkt), 0, (sockaddr*)sender, sender_len); if (ret 0) { continue; // 接收超时或错误继续 } if (cal_checksum((unsigned short*)pkt, sizeof(pkt)) ! 0) { continue; // 校验失败静默丢弃 } if (pkt.header.seq expected_seq) { // 正好是期望序号写入文件 write_to_file(pkt.data, pkt.header.seq); // 把乱序缓冲区里连续的下一个补上来 while (buffer_map.count(expected_seq)) { write_to_file(buffer_map[expected_seq]); buffer_map.erase(expected_seq); } } else if (pkt.header.seq expected_seq) { // 乱序包先缓存 buffer_map[pkt.header.seq] pkt.data; } else { continue; // 重复包忽略 } Packet ack; ack.header.type 1; ack.header.ack expected_seq - 1; ack.header.checksum cal_checksum((unsigned short*)ack, sizeof(ack)); sendto(sock, (char*)ack, sizeof(ack), 0, (sockaddr*)sender, sender_len); }这段代码的核心是expected_seq。它既是写入文件的顺序指针也是 ACK 里的累计确认号。乱序包到达时数据放进内存buffer_map但 ACK 不往前移动发送端会一直看到ack比窗口顶端小从而决定是否重传。这里的buffer_map用有序 map 就行数据量大了可以换数组加位图原理一样都是为了能把乱序包暂时留住等缺失的包到齐后按照顺序补写文件。要注意别在 recvfrom 返回 -1 时立刻把错误打印成“网络断开”。UDP recvfrom 超时是常态发送端每个包都要等 500ms 才收到第一个确认接收端在主循环里可能每秒会空转两次这不代表异常。4. 避坑与常见问题排查从卡死到错误码 100544.1 一模拟丢包程序就卡住超时设置没生效现象是本地运行一切正常一旦用工具把丢包率调到 10%发送端就卡在 recvfrom 里再也不动了界面看起来像死锁。日志里最后一个 sendto 成功后后面没有任何输出。原因很简单SO_RCVTIMEO 没有设置对或者设置的位置不对。很多同学把超时设置放在 bind 之前但不同的操作系统对 setsockopt 的时机有差异设置失败后 recvfrom 依然阻塞无穷长时间发送端等 ACK 等到天荒地老。解决方法是先用一个简单测试脚本验证超时真实生效给一个空 socket 设置 500ms 超时连带上两个 recvfrom看返回值是不是 -1以及耗时是不是接近 500ms。附带再确认一个参数Linux 下 SO_RCVTIMEO 接收的是struct timevalWindows 下是 DWORD 毫秒值两者不能直接兼容。我一般会写一个平台宏分别在两边设置超时然后显示打印 getsockopt 拿到的实际超时值肉眼确认过了再继续。4.2 read udp: unknown error (code10054) 是怎么回事不少人在 Windows 上跑 UDP 可靠传输程序时控制台突然打印出read udp: unknown error (code10054)然后发送端程序就退出了。这个错误码在 Winsock 里对应 WSAECONNRESET意思是“连接被目标主机重置”。原因在于 Windows 对 UDP 的 ICMP 处理方式比较特殊。当你向一个没有进程在监听的端口发 UDP 数据报目标主机的 IP 层会返回一个 ICMP Port Unreachable 消息。Windows 收到这个 ICMP 后会把错误挂到这个 socket 上下一次 recvfrom 就返回 10054。比如你服务端代码崩了但客户端还在重传客户端下一次 recvfrom 就会踩到这个坑。解决方法是先检查对端端口是否真的在监听然后对 10054 做容错处理在 recvfrom 失败后读取错误码如果是 WSAECONNRESET就忽略这个错误继续重传。从设计上讲UDP 本来就不应该因为一个 ICMP 错误码就把整个传输流程打断只有重传次数达到阈值才允许通信失败。这个错误在 Linux 下的表现形式也会出现只是 errno 可能是 ECONNREFUSED排查时记得把两个平台的报错文本都打印出来对比。4.3 重复 ACK 导致重复重传现象是接收端日志里大量出现重复 ACK发送端收到重复 ACK 后立刻重发整个窗口传输效率急剧下降文件又大时甚至不如原始 UDP 快。原因出在重传逻辑上。有些实现把“收到 ACK”等同于“可以发下一个包”但没区分 ACK 是新的表态还是旧的重复。UDP 本身不保证顺序ACK 也可能乱序到达如果你收到一个序号 3 的 ACK又从重传定时器队列里看到了序号 1 的超时就会重复发送已经确认的包。解决方式是累计确认判断。接收端回 ACK 时ack 字段写的是当前已连续收到的最大序号发送端判断时只认“新 ACK”也就是ack.header.ack last_acked_seq才更新发送窗口如果收到的 ACK 序号小于等于已经确认过的序号直接忽略。同时重传定时器不要每收到一个 ACK 就重置否则某个包的 ACK 在网络里多绕了一圈发送端就会跟着把定时器往后拨最终所有超时机制全部失效。4.4 自定义校验和总是校验失败现象比较诡异客户端自己计算校验和没问题服务端怎么算都不对。检查网络顺序也调了还是失败。原因有很大概率是结构体对齐而不是算法本身错了。前文提到用#pragma pack(push, 1)是为了让结构体在内存里的字节布局和线格式完全一致。如果不加编译器会在type和seq之间插入 1 字节 padding导致你在发送端计算校验和的区域和对端计算校验和的区域并不相同自然永远对不上。解决方法是三个方面同时检查结构体加 1 字节对齐发送前让网络字节序与主机字节序统一16 位字段用 htons/ntohs 互转计算校验和时用实际发送的字节长度不要用 sizeof(Packet) 整个结构因为 data 数组里可能有多余的未初始化尾巴也会污染校验和。做完这三件事再不行就在收发两端把校验和原样打印成 hex一对比就能看出是哪一字节错位了。4.5 防火墙静默丢弃 UDP 报文现象是代码逻辑看着全对sendto 返回成功对端 recvfrom 却一个包都收不到。本地同一台机器跑服务端和客户端没问题但把服务端放到另一台机器之后客户端一直超时重传。原因大概率是 Windows 或 Linux 防火墙默认拦截了未知端口的入站 UDP 报文。UDP 没有 TCP 的握手包来触发防火墙弹窗很多防火墙策略会直接静默丢弃。TCP 连接失败时你还能看到 connect timeoutUDP 则是发送成功、接收无响应排查起来更隐蔽。解决方法是先查防火墙规则临时放行测试端口比如 Windows 的“允许应用通过防火墙”里添加客户端程序的监听端口Linux 上则检查iptables -L和firewalld状态。排查时可以在两端分别执行netstat -anu | grep 9527确认 UDP 端口确实处于监听状态再用同一台机器上的nping或nc -u发一条测试报绕过应用层定位问题。5. 验证与进阶用 netem 模拟丢包把作业变成可演示项目5.1 用 netem 模拟丢包、延迟和乱序测试阶段如果不模拟丢包整个程序就是一个普通 UDP 聊天室没有任何说服力。Linux 上最常用的工具是内核自带的 netem通过 tc 命令给网卡添加队列规则可以模拟丢包、延迟、乱序和重复。# 在 lo 网卡上添加 10% 丢包 20ms 延迟 sudo tc qdisc add dev lo root netem loss 10% delay 20ms # 再叠加乱序25% 的包会乱序 sudo tc qdisc change dev lo root netem loss 10% delay 20ms reorder 25% # 测试完成后一定要删掉规则不然本机回环网络一直带故障 sudo tc qdisc del dev lo root用回环网卡 lo 测试比较方便因为服务端和客户端都跑在同一台机器不需要两台物理机。loss 10%表示 10% 的包会被随机丢弃发送端的重传逻辑立刻得到检验reorder 25%会让 25% 的包在规定延迟内超出其他包到达接收端用来验证接收端的乱序缓冲区。不要只在无故障环境里跑一遍就完事那只能证明代码能跑不能证明可靠传输真的可靠。如果你没有 root 权限也可以用用户态的 netcat 加管道模拟但不如 netem 直观。测试时把丢包率从 0%、5%、10%、20% 逐级增加记录每次传输的重传次数、耗时和最终文件哈希。5.2 验证指标哈希一致性、吞吐量和重传率可靠传输最终要回答一个问题数据到了没有对不对。文件传输场景最直接的验证方法是发送方在发送前计算一次源文件哈希接收方在接收完成后计算一次目标文件哈希两者一致才算成功。我在测试时会以表格形式记录结果丢包率文件大小发送耗时重传包数接收端哈希是否一致0%10 MB3.2s0一致5%10 MB3.8s120一致10%10 MB4.5s280一致20%10 MB5.6s640一致协议参数可以按这个报告去调如果吞吐量偏低可以增大发送窗口大小网络 RTT 正常时一次多发几个包如果重传率偏高优先检查超时时间设置超时太短会让 ACK 稍晚到就重传浪费带宽超时太长又会让确认延迟放大整体变慢。一个可行的初始值是把超时设成平均 RTT 的两倍再根据重传率逐步调整。这些数据放在实验报告里老师一眼就能看出你确实调试过。5.3 从作业到实战的两个小改进跑通作业之后如果你还有时间我建议做两个小改进一是动态超时二是双缓冲写入。动态超时的思路是在每次成功收到 ACK 后根据当前 RTT 更新超时时间避免用固定的 500ms 去匹配所有网络环境。最常见的做法是用指数加权移动平均RTT α * 旧RTT (1-α) * 新RTTα 取 0.125 左右再把超时定为两倍 RTT。这样在本地快、在线慢的异构网络下都能自动适配。双缓冲则是接收端在把数据写入文件的同时提前接收下一个包不要让磁盘写操作阻塞 socket 接收否则一旦磁盘抖动接收缓冲区一满内核直接丢包可靠性再强也会被外部因素击穿。我记得当时第一次跑通 20% 丢包率下的文件传输时代码里还留着一个硬编码的 500ms 定时器后来换到虚拟机里调试RTT 从 0.5ms 涨到 30ms整个传输速度降了不止一个数量级。跟着做之后我形成了一个习惯每写一段 UDP 可靠传输代码都会强制自己先在 10% 丢包和 30ms 延迟下跑一遍确认超时和重传路径是活的再去调业务逻辑。这套方法能让你在课程作业和实际项目中少走很多弯路希望帮到你。本文还有配套的精品资源点击获取