简介这是一套基于UDP协议实现的大文件传输软件源码包含服务端与客户端两部分面向需要学习网络编程、Socket通信与大文件传输方案的学生和开发者。项目通过UDP循环发送文件传输速率可达10MB/s以上服务端支持多客户端并发上传、动态计算速率并写入日志还可指定时间自动删除文件客户端支持按分钟创建以时间戳命名的文件单文件大小可配置默认6GB。压缩包共102个文件约482KB以32个.h头文件与32个.cpp源文件为核心实现另有24张png界面截图、2个ico图标、2个makefile、2个ui界面文件、2个qrc资源文件、2个pro工程文件及css样式等工程结构完整。目前已有2715人学习下载。读者可从中掌握UDP可靠传输、多线程收发、队列缓冲、日志记录与文件生命周期管理等关键实现适合作为课程设计、毕业设计或网络编程练手项目的参考。1. 为什么 UDP 传大文件不是“找罪受”而是一条被低估的工程路径TCP 传大文件绝大多数时候是默认答案。但真到了跨机房、弱网、高丢包、长肥管道这些场景TCP 的拥塞控制、重传确认、滑动窗口反而会变成拖累——一条 200ms RTT、5% 丢包的链路TCP 吞吐可能掉到带宽的十分之一。UDP 没有连接、没有重传、没有拥塞控制听起来像“裸奔”但正因为内核不替你做决定你才有机会在应用层自己设计确认、重传、分片和速率控制。这就是“基于 UDP 协议设计的大文件传输软件包含服务器与客户端”这个方向真正要解决的问题不是替代 TCP而是在 TCP 表现糟糕的链路上用可控的代价把大文件搬过去。适合谁适合需要跨公网传 GB 级文件、又不想被 TCP 吞吐卡死的后端和运维工程师。下面从协议设计一路讲到能跑起来的代码。2. 协议设计UDP 传大文件必须先定好这四件事2.1 分片大小与 MTU 的取舍UDP 本身不负责分片应用层必须自己切。切多大以太网 MTU 1500 字节减去 IP 头 20、UDP 头 8理论载荷 1472。但公网路径上可能有 PPPoE、隧道封装实际安全值我一般取 12001400。超过 MTU 会导致 IP 层分片任何一个分片丢失整个包就废了重传代价翻倍。常见做法是固定 1400 字节载荷头部再占 1624 字节单包控制在 1424 以内。如果你确定链路干净比如同机房可以试 1472跨公网就老实降到 1200。这个值不是拍脑袋是拿ping -M do -s 1472逐段试出来的。# Linux 下探测路径 MTU-M do 禁止分片 ping -M do -s 1472 -c 3 目标IP # 如果返回 Message too long逐步减小 -s 直到通 ping -M do -s 1200 -c 3 目标IP逻辑说明-s指定 ICMP 载荷大小加上 8 字节 ICMP 头和 20 字节 IP 头就是实际 IP 包大小。-M do禁止内核分片能通说明路径 MTU 至少支持这个尺寸。参数上从 1472 往下每次减 8 或 16找到临界值后再留 50100 字节余量作为应用层分片大小。2.2 包头字段每个字节都要有理由UDP 包头之后紧跟你自己设计的协议头。最小可用集合是文件 ID4 字节、分片序号4 字节、总片数4 字节、标志位1 字节、校验和2 字节。加起来 15 字节对齐到 16 或 20 更好。标志位里至少要区分数据包、ACK、FIN、心跳。校验和用 CRC16 就够别上 MD5——每个包算 MD5 会让 CPU 先成为瓶颈。文件级完整性最后单独用 SHA256 校验一次即可。import struct # 协议头格式!I I I B H 文件ID 分片序号 总片数 标志 校验和 HEADER_FORMAT !IIIBH HEADER_SIZE struct.calcsize(HEADER_FORMAT) # 15 字节 FLAG_DATA 0x01 FLAG_ACK 0x02 FLAG_FIN 0x04 FLAG_HEARTBEAT 0x08 def pack_header(file_id, seq, total, flag, checksum): return struct.pack(HEADER_FORMAT, file_id, seq, total, flag, checksum) def unpack_header(data): return struct.unpack(HEADER_FORMAT, data[:HEADER_SIZE])逻辑说明!表示网络字节序避免大小端问题。I是无符号 32 位整数文件 ID 和分片序号都用它支持单文件最大 4GB 分片数——实际文件大小不受限因为分片序号只标识片不标识字节偏移。参数上如果单文件超过 40 亿片按 1400 字节算约 5.6TB才需要换成 8 字节序号。校验和字段用 CRC16接收端算完不匹配直接丢不回复 ACK让发送端超时重传。2.3 确认与重传别做成“每包一确认”每包一 ACK 在高速链路上会让 ACK 风暴吃掉带宽。常见做法是累积确认接收端每收到 N 个包比如 32 个或每隔 T 毫秒比如 20ms回一个 ACKACK 里带“已连续收到的最大序号”。发送端维护一个滑动窗口窗口内未确认的包超时后重传。超时时间不能固定。RTT 会变固定 200ms 在跨洋链路直接翻车。简单做法是维护平滑 RTTsrtt 0.9 * srtt 0.1 * sample_rtt超时设为srtt * 2下限 100ms上限 2s。这个逻辑和 TCP 的 RTO 计算一个思路但你可以调得更激进因为你知道自己在传文件不是交互流量。class RetransmitManager: def __init__(self): self.srtt 0.2 # 初始 200ms self.window {} # seq - (send_time, data) self.window_size 64 def on_ack(self, ack_seq, now): # 累积确认清除所有 ack_seq 的待确认包 for seq in list(self.window.keys()): if seq ack_seq: sample now - self.window[seq][0] self.srtt 0.9 * self.srtt 0.1 * sample del self.window[seq] def get_timeout(self): return max(0.1, min(2.0, self.srtt * 2)) def need_retransmit(self, now): timeout self.get_timeout() return [seq for seq, (t, _) in self.window.items() if now - t timeout]逻辑说明on_ack收到累积确认后把所有已确认包从窗口移除并用最新样本更新 srtt。get_timeout把超时限制在 100ms 到 2s 之间防止极端值导致重传风暴或死等。need_retransmit返回超时的序号列表发送端遍历重发。参数上window_size决定在途包数量太小吞吐上不去太大内存和丢包恢复成本高。64 个包按 1400 字节算约 90KB 在途千兆链路 RTT 20ms 时理论吞吐约 36Mbps够用要跑满千兆得把窗口开到 1000 以上但内存和重传代价要自己权衡。2.4 文件级完整性最后一道后悔药UDP 不保证任何东西应用层重传也可能因为 bug 漏掉某个包。文件传完后接收端必须做一次整体校验。发送端在 FIN 包里带上文件 SHA256接收端拼完文件后本地算一遍对比。不一致就整个文件重传——别试图定位哪个包错了大文件场景下整体重传比逐包排查更省时间。import hashlib def file_sha256(path, chunk_size1024*1024): h hashlib.sha256() with open(path, rb) as f: while True: chunk f.read(chunk_size) if not chunk: break h.update(chunk) return h.hexdigest()逻辑说明分块读取避免大文件一次性载入内存。chunk_size设 1MB兼顾 IO 效率和内存占用。发送端在发送前算一次接收端在写完后算一次对比十六进制字符串。参数上如果文件超过 10GBSHA256 计算本身要几秒到几十秒可以接受如果嫌慢换 BLAKE3 或 xxHash但 SHA256 兼容性最好。3. 服务器与客户端实现从 socket 到能跑通的最小闭环3.1 服务器端收包、写盘、回 ACK服务器不需要多线程收包——UDP 收包本身很快瓶颈在写盘。单线程收包 异步写盘队列是常见做法。收到数据包后先校验 CRC通过则按分片序号写入文件对应偏移然后更新“已连续收到”的位图达到阈值就回 ACK。import socket import struct import threading import queue HEADER_FORMAT !IIIBH HEADER_SIZE struct.calcsize(HEADER_FORMAT) FLAG_DATA 0x01 FLAG_ACK 0x02 FLAG_FIN 0x04 class UDPServer: def __init__(self, host, port, save_dir): self.sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) self.sock.bind((host, port)) self.save_dir save_dir self.files {} # file_id - {fd, total, received_bitmap, addr} self.write_queue queue.Queue(maxsize1024) self.writer threading.Thread(targetself._write_loop, daemonTrue) self.writer.start() def _write_loop(self): while True: file_id, seq, payload self.write_queue.get() info self.files.get(file_id) if info: info[fd].seek(seq * 1400) info[fd].write(payload) info[received_bitmap].add(seq) def run(self): while True: data, addr self.sock.recvfrom(2048) if len(data) HEADER_SIZE: continue file_id, seq, total, flag, checksum struct.unpack( HEADER_FORMAT, data[:HEADER_SIZE]) payload data[HEADER_SIZE:] if flag FLAG_DATA: if file_id not in self.files: path f{self.save_dir}/{file_id}.bin self.files[file_id] { fd: open(path, wb), total: total, received_bitmap: set(), addr: addr, last_ack: 0 } self.write_queue.put((file_id, seq, payload)) info self.files[file_id] # 每收到 32 个包回一次累积 ACK if len(info[received_bitmap]) % 32 0: ack struct.pack(HEADER_FORMAT, file_id, max(info[received_bitmap]), total, FLAG_ACK, 0) self.sock.sendto(ack, addr) elif flag FLAG_FIN: info self.files.get(file_id) if info: info[fd].close() del self.files[file_id]逻辑说明recvfrom收包后先解头FLAG_DATA走写盘队列FLAG_FIN关文件。写盘用单独线程避免磁盘 IO 阻塞收包。ACK 每 32 个包回一次max(received_bitmap)是当前连续收到的最大序号——注意这里简化了实际应该维护连续位图因为乱序到达时max可能跳变。参数上write_queue设 1024 深度满了就丢包让发送端重传比阻塞收包好。1400是分片大小要和客户端一致。3.2 客户端读文件、切片、发窗口、等 ACK客户端逻辑比服务器复杂要维护发送窗口、处理 ACK、超时重传、最后发 FIN。核心是一个循环窗口有空位就发新包收到 ACK 就滑窗超时就重传。import socket import struct import time import os HEADER_FORMAT !IIIBH HEADER_SIZE struct.calcsize(HEADER_FORMAT) FLAG_DATA 0x01 FLAG_ACK 0x02 FLAG_FIN 0x04 CHUNK_SIZE 1400 class UDPClient: def __init__(self, server_addr): self.sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) self.sock.settimeout(0.05) self.server server_addr self.srtt 0.2 self.window {} # seq - (send_time, data) self.window_size 64 self.next_seq 0 self.total 0 self.file_id 0 def send_file(self, path): size os.path.getsize(path) self.total (size CHUNK_SIZE - 1) // CHUNK_SIZE self.file_id int(time.time()) 0xFFFFFFFF with open(path, rb) as f: while self.next_seq self.total or self.window: # 填充窗口 while (self.next_seq self.total and len(self.window) self.window_size): data f.read(CHUNK_SIZE) if not data: break header struct.pack(HEADER_FORMAT, self.file_id, self.next_seq, self.total, FLAG_DATA, 0) self.sock.sendto(header data, self.server) self.window[self.next_seq] (time.time(), header data) self.next_seq 1 # 收 ACK try: pkt, _ self.sock.recvfrom(2048) fid, ack_seq, _, flag, _ struct.unpack( HEADER_FORMAT, pkt[:HEADER_SIZE]) if flag FLAG_ACK and fid self.file_id: now time.time() for seq in list(self.window.keys()): if seq ack_seq: sample now - self.window[seq][0] self.srtt 0.9 * self.srtt 0.1 * sample del self.window[seq] except socket.timeout: pass # 超时重传 now time.time() timeout max(0.1, min(2.0, self.srtt * 2)) for seq in list(self.window.keys()): if now - self.window[seq][0] timeout: self.sock.sendto(self.window[seq][1], self.server) self.window[seq] (now, self.window[seq][1]) # 发 FIN fin struct.pack(HEADER_FORMAT, self.file_id, self.total, self.total, FLAG_FIN, 0) for _ in range(3): self.sock.sendto(fin, self.server) time.sleep(0.05)逻辑说明主循环先填窗口再尝试收 ACK最后检查超时重传。settimeout(0.05)让recvfrom不阻塞太久保证重传检查及时。ACK 处理里用seq ack_seq做累积确认和服务器端对应。FIN 发三次是防止丢包实际可以等服务器回 FIN-ACK但简化实现里发三次就关。参数上window_size和服务器无关纯客户端控制CHUNK_SIZE必须和服务器一致否则写盘偏移错位。3.3 跑通第一个文件命令与验证服务器先起客户端后发。验证分三步文件大小一致、SHA256 一致、传输耗时在预期范围。# 终端 1起服务器 python3 udp_server.py --host 0.0.0.0 --port 9000 --dir ./recv # 终端 2发文件 python3 udp_client.py --server 127.0.0.1:9000 --file ./test.bin # 验证 ls -l ./test.bin ./recv/*.bin sha256sum ./test.bin ./recv/*.bin逻辑说明服务器监听 9000收到文件存到./recv。客户端指定服务器地址和文件路径。验证时对比文件大小和 SHA256一致才算跑通。参数上本地回环测试丢包率为零主要验证逻辑正确性真实链路测试要用tc模拟丢包和延迟。# 模拟 5% 丢包和 100ms 延迟 sudo tc qdisc add dev eth0 root netem loss 5% delay 100ms # 测试完清除 sudo tc qdisc del dev eth0 root逻辑说明tc netem是 Linux 下模拟网络损伤的标准工具。loss 5%模拟丢包delay 100ms模拟 RTT。在这个条件下跑传输观察吞吐和重传次数。参数上丢包率从 1% 到 20% 逐档测试延迟从 10ms 到 300ms找到你的协议能扛住的边界。4. 避坑与排查UDP 大文件传输最容易翻车的五个点4.1 现象传输到 99% 卡住不动原因最后一个包或 FIN 包丢了发送端窗口里只剩一两个包超时重传间隔越来越长看起来像卡死。解决FIN 包必须带重传且接收端收到 FIN 后要回 FIN-ACK。发送端收到 FIN-ACK 才关闭收不到就每 500ms 重发 FIN最多 10 次。另外最后一个数据包如果丢了累积 ACK 永远到不了 total发送端要能识别“窗口里只剩最后一个包且超时”的情况单独重传。4.2 现象吞吐远低于预期CPU 却不高原因窗口太小。在途包数量 窗口大小吞吐 ≈ 窗口大小 × 分片大小 / RTT。64 个包 × 1400 字节 / 0.1s 896KB/s约 7Mbps。如果 RTT 是 200ms直接掉到 3.5Mbps。解决按带宽延迟积算窗口。千兆链路、100ms RTT需要 1000Mbps × 0.1s / 8 12.5MB 在途除以 1400 约 9000 个包。窗口开到 10000 以上内存占用约 14MB可接受。但窗口大了丢包恢复慢要配合选择性重传。4.3 现象接收端文件 SHA256 对不上但大小一致原因乱序包写盘时偏移算错或者两个包写了同一偏移。常见于多线程写盘没加锁或者seek和write不是原子操作。解决写盘必须单线程或者每个文件一把锁。偏移用seq * CHUNK_SIZE算不要用累计写入字节数。另外接收端要维护已写位图重复包直接丢弃避免覆盖。4.4 现象服务器内存持续增长最终 OOM原因self.files字典里每个文件都开了 fd 和位图传输完成后没清理。如果客户端异常断开FIN 永远不来文件句柄泄漏。解决加超时清理——每个文件记录最后收包时间超过 60 秒没新包就关闭 fd、删除条目。另外位图用set存整数大文件百万片会占几十 MB换成bitarray或分段位图。4.5 现象跨公网传输被中间设备限速或丢弃原因UDP 流量在某些网络里被 QoS 降级或者 NAT 映射超时导致回包到不了。解决客户端和服务器之间加心跳包每 15 秒发一次维持 NAT 映射。如果发现 UDP 被限速只能换端口或换协议——这是网络策略问题应用层解决不了。测试时先用小文件探路确认链路对 UDP 友好再传大文件。5. 进阶技巧用选择性重传把弱网吞吐再拉高一截累积确认在丢包少时没问题但丢包一多一个包丢了后面全要重传。选择性重传SACK让接收端在 ACK 里带上“我收到了哪些不连续的片”发送端只重传真正丢的。实现上ACK 包可以带一个位图每 bit 表示一个片是否收到按窗口对齐。发送端收到后把位图里为 0 的片重传。# ACK 包扩展头部之后跟位图每字节 8 个片 def build_sack_ack(file_id, total, base_seq, bitmap_bytes): header struct.pack(HEADER_FORMAT, file_id, base_seq, total, FLAG_ACK, 0) return header bitmap_bytes def parse_sack_ack(data): file_id, base_seq, total, flag, _ struct.unpack( HEADER_FORMAT, data[:HEADER_SIZE]) bitmap data[HEADER_SIZE:] lost [] for byte_idx, byte in enumerate(bitmap): for bit in range(8): if not (byte (1 bit)): seq base_seq byte_idx * 8 bit if seq total: lost.append(seq) return file_id, base_seq, lost逻辑说明base_seq是位图的起始序号位图每字节表示 8 个片1 表示收到0 表示丢失。发送端解析后只重传lost列表里的片。参数上位图长度按窗口大小算窗口 10000 就需要 1250 字节超过 MTU 要分多个 ACK 包发。实际实现里可以只对窗口内未确认部分做位图减少体积。另一个技巧是动态调整发送速率。不要一上来就满窗口发先慢启动窗口从 16 开始每收到一个完整窗口的 ACK 就翻倍直到丢包或达到上限。这和 TCP 慢启动一个思路但你可以调得更激进因为文件传输对延迟不敏感。我一般设初始窗口 32每 RTT 翻倍上限 8192丢包时减半。这套组合在 5% 丢包、100ms RTT 的链路上比固定窗口吞吐高 3 到 5 倍。最后说个血泪教训别在应用层做拥塞控制时忽略接收端处理能力。发送端窗口开到 10000接收端写盘跟不上内核缓冲区满了直接丢包发送端以为是网络丢包疯狂重传实际是接收端过载。接收端要在 ACK 里带自己的接收窗口剩余发送端据此调整。这个字段加在 ACK 头里2 字节就够。希望帮到你。本文还有配套的精品资源点击获取