简介面向网络编程课程设计与实验场景这份基于Python的可靠数据传输协议实现资料包含完整设计报告与可运行源码覆盖停等协议、GBN协议和SR协议的逐步演进帮助学习者在UDP之上构建可靠的单向与双向数据传输机制并通过模拟数据包丢失验证协议有效性。压缩包共14个文件包含8个Python脚本、1份Word设计报告、说明文档与测试数据整体大小仅493KB。已有1014人学习下载。资料从基础停等协议起步逐步扩展至GBN与SR协议并实现基于该协议栈的C/S文件传输应用源码与报告配合可直接运行验证协议行为也可作为计算机网络课程设计、毕业设计或自学可靠传输原理的参考资料。设计报告详细阐述了各协议的设计思路、帧格式与实验结果代码中配置文件、设备模拟、数据产生等工具脚本一应俱全便于二次开发与实验复现。1. 基于Python实现的可靠数据传输协议先搞明白它到底在解决什么问题把“基于Python实现的可靠数据传输协议.zip”这个标题拆开看它不是一个库也不是某某大厂的开源框架而是一个典型的“用Python从零写一套可靠传输机制”的动手项目。常见应用场景是课程设计、毕业设计或者某个局域网内不想引入TCP/IP栈却能控制传输行为的自定义工具。它要解决的核心问题很简单UDP只负责发不保证顺序、不保证不丢、不保证不重复而系统自带的TCP虽然可靠却是一口“黑匣子”你不能改它的窗口、不能观察重传时机、不能按自己的数据格式定义报文。于是这类项目的常规做法是用UDP socket当作“裸信道”自己在应用层实现校验和、序号、确认ACK、超时重传、滑动窗口这几样东西最终得到一个能跑在局域网内的可靠传输工具。这个标题值得做是因为它正好卡在Python学习者从“会语法”到“会网络编程”的分界线上。读者通常是两类人一类是刚看完python基础语法、python入门教程的在校生需要一个不依赖框架的动手项目另一类是写python爬虫、做数据分析时偶尔要传文件的从业者想知道自己实现可靠传输需要付出多少成本、有哪些坑。这篇文章就按“协议怎么设计→最小实现怎么跑通→窗口和吞吐怎么优化→哪些参数不能乱调→怎么验证它真的可靠”的顺序展开所有代码基于Python 3.8只需要标准库不依赖第三方包。2. 可靠数据传输协议的底层设计四个机制一个不能少2.1 为什么UDP裸奔不行丢包、乱序、重复是常态先明确一个概念这里的“可靠”是相对UDP说的不是让你重造一个TCP。TCP可靠是因为它在内核里做了四件事校验数据完整性、给每个字节编号、接收方回ACK、发送方超时重传。换到Python应用层这四件事一样都不能少只是实现方式更直白你能看见每一步发生了什么这正是这个项目最大的学习价值。用Python做这件事几乎100%的从业者会选UDP socket当底座而不是直接用TCP socket。原因有两点第一TCP的可靠性是内核实现的你拿不到中间状态——丢包率、重传次数、接收缓冲占用统统不透明想调试自己写的流控逻辑根本无从下手第二TCP的API把字节流封装得太干净没有“帧”的概念而自定义协议通常需要按固定格式的报文来交换。UDP保留了一个sendto/recvfrom就能拿到完整报文的边界非常适合在应用层做实验。这里有一个关键认知丢包不是只在网络故障时才发生。在局域网里UDP丢包率通常很低但一旦接收方的socket缓冲区满内核会直接丢弃后续到达的数据报。而数据报乱序在跨交换机、有多个链路时也偶有发生。所以你不能假设“局域网就不会出问题”所有机制都要按最坏情况设计。2.2 报文格式先于代码四个字段说清楚谁发给谁动手写代码之前先把报文格式定死。这是这类项目最容易被新手省略的一步但省略的代价是后期调试时根本分不清收到的字节是数据还是控制信息。我一般会定义一个固定头变长载荷的结构字段按顺序排列保证发送端和接收端都能用同一套解析函数还原。import struct import zlib MAGIC bRDT1 # 魔数防止把无关数据报当成协议报文 TYPE_DATA 0x01 TYPE_ACK 0x02 HEADER_SIZE 16 def build_packet(seq: int, payload: bytes, pkt_type: int TYPE_DATA) - bytes: # 4字节魔数 1字节类型 2字节序号 2字节载荷长度 4字节校验和 3字节保留 length len(payload) # 校验和覆盖 类型序号长度载荷防止头部和数据同时被篡改 checksum zlib.crc32(payload struct.pack(BHI, pkt_type, seq, length)) header struct.pack(4sBHI, MAGIC, pkt_type, seq, length) packet header struct.pack(I, checksum) b\x00 * 3 payload return packet def parse_packet(data: bytes): if len(data) HEADER_SIZE or data[:4] ! MAGIC: return None _, pkt_type, seq, length struct.unpack(4sBHI, data[:11]) checksum struct.unpack(I, data[11:15])[0] payload data[HEADER_SIZE:] # 校验和验证先用接收到的字节重新计算再与报文里的值比对 calc zlib.crc32(payload struct.pack(BHI, pkt_type, seq, length)) if calc ! checksum or len(payload) ! length: return None return {type: pkt_type, seq: seq, payload: payload}这段代码做三件事打包成固定结构、解析、校验。参数说明seq用的是无符号16位整数范围0到65535这是因为滑动窗口场景下后面第4章会讲到序号空间必须足够大不能像初版代码那样用布尔值表示“上一个/下一个”checksum用zlib.crc32而不是Python内置hash因为crc32在短报文上碰撞概率更低性能也足够struct的字节序必须发送端和接收端都用“”大端否则一台小端机器打包、另一台解析时字段会全部错位。这里要特别提醒一个新人常犯的错误校验和计算范围不一致。打包时先算校验和再拼头部接收时却只对载荷做校验导致头部字段被篡改时校验依然通过。上面的代码把类型、序号、长度和载荷一起参与校验所以用同一套逻辑避免这个坑。魔数MAGIC一定要有它能在调试阶段救你一命——网络调试助手、别的程序往你端口发的随机数据都会被快速过滤。2.3 接收方“确认”的三种语义ACK、NAK、带内反馈报文格式定义好之后下一步是确定确认机制。可靠数据传输协议最基础的消息是“数据报文”和“ACK报文”。ACK报文的seq字段表示“我期待的下一个序号”这种写法和TCP的累积确认是一致的接收方收到seq1的报文回复ACK2意思是“1及以前的都收到了下次请发2”。这样发送端就不需要为每个报文单独维护一个“是否被确认”的集合收到ACK2就能一次性确认seq1之前的所有报文。有人会问要不要用NAK否定确认我的建议是初版协议里不要加。原因有两个。第一NAK在丢包率不高的局域网里几乎没有价值——你发NAK的代价和直接重传是一样的还要额外处理NAK丢失的情况第二NAK本身也需要保护万一NAK丢了发送端还是靠超时兜底那NAK就变成了纯粹的额外开销。所以协议越简单越可靠初版只要数据报文和ACK报文两种类型就够了。当后面实现流水线传输时ACK里带一个“当前接收窗口剩余空间”的字段就能顺便完成流控这属于进阶设计第4章会说。3. 用Python在UDP上跑通停等协议最小可靠传输的第一版3.1 发送端主循环发一个、等一个、超时重传停等协议是可靠数据传输的最小闭环它的逻辑只有三行发送报文→等待ACK→没等到就重发。这个协议虽然吞吐量低但它是后面所有流水线协议的基础牵涉到的socket缓冲区处理、超时设置、重传计数都是通用的。先看发送端的实现。import socket import time DEST (127.0.0.1, 8888) BUF_SIZE 4096 TIMEOUT 0.5 # 初始超时时间单位秒 MAX_RETRY 8 def rdt_send(sock: socket.socket, seq: int, payload: bytes) - bool: pkt build_packet(seq, payload, TYPE_DATA) for attempt in range(MAX_RETRY): sock.sendto(pkt, DEST) sock.settimeout(TIMEOUT) try: data, _ sock.recvfrom(BUF_SIZE) ack parse_packet(data) # 只认“期待序号”的ACK其他一律丢弃 if ack and ack[type] TYPE_ACK and ack[seq] seq 1: return True except socket.timeout: print(f[重传] seq{seq} attempt{attempt}, timeout{TIMEOUT}) # 超时后增大重传间隔避免网络拥塞时雪上加霜 sock.settimeout(TIMEOUT * (2 ** (attempt 1))) return False sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) # 模拟发送一个文件把文件切成4096字节的块逐块走停等协议 file_data bhello reliable transfer protocol * 1000 chunk_size 4096 seq 0 for offset in range(0, len(file_data), chunk_size): chunk file_data[offset:offset chunk_size] ok rdt_send(sock, seq, chunk) if not ok: print(发送失败中止) break seq 1逻辑说明每次调用rdt_send只发送一个数据报文并等待与之对应的ACK。重点在两处一是settimeout放在每次发送前而不是初始化时这样每次循环超时时间都可能不同二是超时后采用指数退避超时时间翻倍重试这是从TCP拥塞控制里借鉴的保守策略。参数说明初始超时0.5秒适合局域网跨公网时建议改到1秒以上重试次数设8次是因为8次重试后总等待时间已经超过100秒再等也没有意义不如让上层文件传输模块直接报错。这里有一个很容易被忽略但极其影响调试的细节sock.recvfrom拿到的数据可能是“迟到的旧ACK”。比如发送端超时重发了seq1两次第一次重发的ACK晚到了第二次重发的ACK先到接收端实际上已经正确收到了data1但发送端两次收到的ACK一模一样不会出错。真正的坑在流水线阶段——确认号相同但含义不同我会在第4章具体讲。3.2 接收端主循环校验、去重、回ACK接收端的逻辑比发送端简单收到数据包→校验→判断是不是期待的那个序号→是就保存并回ACK不是就丢弃或者也回一个ACK让发送端别再重发。def rdt_receive(sock: socket.socket, output_file: str): expected_seq 0 with open(output_file, wb) as f: while True: data, addr sock.recvfrom(BUF_SIZE 100) pkt parse_packet(data) if pkt is None: continue if pkt[type] TYPE_DATA and pkt[seq] expected_seq 1: f.write(pkt[payload]) # 收到正确数据后立刻回ACKACK里携带“期待的下一个序号” ack build_packet(pkt[seq] 1, b, TYPE_ACK) sock.sendto(ack, addr) expected_seq 1 # 如果收到的序号不是期待的说明是重复报文不回ACK这个接收端有一个关键取舍对于重复的旧数据包它选择沉默而不是回ACK。很多人写到这里会顺手回一个ACK理由是“告诉对方我已经有这份数据了”。但仔细想一下接收端如果收到了重复包说明发送端还没收到此前发的ACK如果此时回ACK这个ACK可能再次丢失发送端还是超时重传。既然超时重传是最终兜底接收端沉默反而能减少无效ACK占用带宽。当然在丢包率极高的环境里沉默会让发送端多等一个超时周期才重传这是可以接受的。3.3 两个逻辑错误忽略校验和与没有文件边界初版代码写完后我习惯做一轮“破坏性测试”。最简单的做法是用随机字节篡改载荷看接收端会不会把坏数据写进文件。你会发现如果parse_packet里校验和比较被注释掉接收端会把坏数据照单全收文件解压必然失败。所以校验不是“安全加分项”而是“可靠性的底线”。另一个问题是文件边界。上面的接收端没有“传输结束”信号因为停等协议里每个报文的seq递增接收端不知道什么时候该关文件。常见的做法是发送端在最后一个报文后发一个TYPE_FIN0x03的控制包接收端收到FIN后才break。这个FIN包也需要走一遍重传逻辑否则文件末尾可能丢数据。如果你嫌麻烦可以先在发送端把文件总字节数放进一个Type0x04的包头包接收端记录总量收到指定字节数就退出循环。这个设计比单靠FIN包更稳因为它能捕获“文件传了一半就断了”的情况。4. 从停等走向流水线用滑动窗口把吞吐提上来4.1 停等协议为什么慢一个RTT只能传一个报文停等协议正确但效率低得令人发指。算一笔账假设局域网RTT是2毫秒每个报文承载的数据是4KB那么理论吞吐只有4KB / 2ms 2MB/s。看起来还行但把Python的socket处理开销、校验计算、进程调度都算进去实际吞吐能到500KB/s就谢天谢地了。如果RTT变成20毫秒跨路由器吞吐直接掉到200KB/s。传输一个50MB的文件要超过4分钟这还只是局域网场景。解决办法是流水线不等到第一个ACK回来就继续发后续报文。这样在同一个RTT窗口内能发多个包吞吐量约等于“窗口大小 × 单包大小 / RTT”。窗口大小为64、每包4KB、RTT为2ms时理论吞吐 64 × 4KB / 2ms 128MB/s。当然实际会低很多但至少比停等协议高出一个数量级。实现流水线的直接冲动是“开线程发送方不断发接收方不断回”。这种做法能做但没有必要因为要处理线程安全问题、锁开销、线程退出条件。更干净的做法是用“单线程超时检查”完成流水线维护一个待重发的队列和滑动窗口的边界每发一个包就记下时间循环里先检查有没有超时的包要重发再决定能不能发送新包。这段代码是这类协议的核心也是最容易出错的部分。import collections WINDOW_SIZE 64 # 发送窗口单位报文 SPEC_RANGE 256 # 序号空间必须大于 2*WINDOW_SIZE TIMEOUT 1.5 # 固定超时简化分析 SEND_INTERVAL 0.01 # 控制发送速率避免瞬间打爆缓冲区 def sender_with_window(sock: socket.socket, payload_list, addr): base 0 # 最早的未确认序号 next_seq 0 # 下一个要发送的序号 timer {} # seq - 发送时间用于超时判断 while base len(payload_list): # 1. 检查超时从base开始扫描发现超过TIMEOUT就重发 now time.time() for s in range(base, next_seq): if s in timer and now - timer[s] TIMEOUT: pkt build_packet(s, payload_list[s], TYPE_DATA) sock.sendto(pkt, addr) timer[s] now break # 每轮只重发一个防止重传风暴 # 2. 发送新报文窗口未满且还有待发数据 while next_seq - base WINDOW_SIZE and next_seq len(payload_list): pkt build_packet(next_seq, payload_list[next_seq], TYPE_DATA) sock.sendto(pkt, addr) timer[next_seq] time.time() next_seq 1 # 3. 非阻塞地收ACK收不到就继续循环 sock.setblocking(False) try: data, _ sock.recvfrom(BUF_SIZE 100) ack parse_packet(data) if ack and ack[type] TYPE_ACK and ack[seq] base: # 累积确认把seq之前的全部标记为已确认 for s in range(base, ack[seq]): timer.pop(s, None) base ack[seq] except BlockingIOError: pass time.sleep(SEND_INTERVAL)这段代码有三个设计点值得说明。第一累积确认的语义ACK报文里的seq 期待的下一序号收到seq10就说明0到9都确认了所以把base直接推进到10而不是只确认某一个。第二每轮最多重发一个超时报文这个限制很关键。如果窗口里有20个包同时超时一轮全部重发会带来极度的拥塞而每轮一个、配合随机间隔能让网络有喘息机会。第三收ACK用的是非阻塞方式这样发送循环不会像停等协议那样“卡”在recvfrom上等ACK而是每10毫秒轮询一次兼顾了吞吐和响应性。参数方面WINDOW_SIZE设为64是因为序号空间SPEC_RANGE是256满足“序号空间 ≥ 2×窗口”的经典条件避免接收端无法区分新包和重复包。如果你把窗口加到128序号空间必须翻倍到512以上否则序号回绕后接收方会判定错误。4.2 序号回绕为什么是致命伤一个最容易翻车的边界条件在停等协议里序号只有一个比特0和1交替不会出现回绕问题。滑动窗口一上序号必须在有限空间里循环使用于是“新报文”和“旧重复报文”在序号上可能完全一样。这就是必须让序号空间大于窗口两倍的原因——接收方看到的序号在可分辨的范围内必须唯一。看一个具体例子序号范围0到255窗口大小64。发送方发出seq0的包超时后没有重发而是继续发seq64、seq65……直到seq255然后回绕到seq0。如果这时第一个seq0的包绕了一大圈终于到达接收端接收端会以为这是新数据。为了规避这种风险你要么限制窗口不超过序号空间的一半要么给“本轮序号空间”加一个纪元值。我推荐前者因为它简单且符合普通文件传输场景。参数设定的黄金法则是序号空间 2 × 窗口 冗余量。窗口64就选256窗口128就选512冗余量保证即使极端情况下新旧包在序号上仍可区分。4.3 接收方也搞乱序缓存还是直接回退N滑动窗口的接收方有两种策略回退NGBN和选择重传SR。回退N最省内存接收方只保留一个“期待序号”把不按序到达的报文全部丢弃收到乱序包时不做缓存。代价是发送方要重传从丢失点到窗口末端的一整片数据浪费带宽。选择重传则是把乱序到达的包先放进缓存然后回复“这个序号到了”的确认发送方只需重传真正丢失的那个。我的建议是初版做SR因为代码复杂度只多一个字典和一个乱序存储换来的却是丢包率在1%以下时几乎无感的重传。实现也很简单接收方E用expected_seq记录顺序边界R用list缓存乱序包。收到seq10的包时如果expected_seq8就把10放进缓存并回复一个“期待9”的ACK等到9到达再检查缓存里10、11、12是否齐了齐了就一起写入文件、推进expected_seq。需要留意的是SR模式下接收方只要收到合法包就应该回ACK包括重复包因为发送方需要知道哪些包“到了且没有丢”避免不必要的重传。这一点和停等协议里“沉默不回复”的策略不同逻辑完全反过来了很多人在这里会踩坑。原因很简单停等协议里每个ACK只对应“唯一等待的包”而SR里一个ACK可以同时确认多个包重复ACK能抑制早期重传。5. 五个高频踩坑记录现象、原因和解决5.1 CRC32算出来对不上接收方把好包当坏包丢了现象局域网内传输零丢包但接收端打印一堆“校验失败”文件传不完。原因打包时校验和只算了一部分或者解包时字段错位。最常见的是struct.pack时用了“I”小端接收端用“I”解析两边对不上另一种是把长度字段排除在校验和范围外导致长度被篡改时校验不通过。解决把“参与校验的字节串”统一成一个变量比如先在发送端构造一个不包含校验和的临时包计算完再拼上接收端同样先提取除校验和外的字段计算后比对。代码里用同一个函数处理保证两端逻辑一致。调试时打印一下parse_packet里的calc和checksum一眼就能看出来是不是字节序问题。5.2 超时时间设太短重传风暴把网络打崩现象窗口协议下传输刚开始时一切正常跑几秒后吞吐急剧下降重传次数暴增CPU占用高网络抓包发现重复报文占了总量的30%以上。原因初始超时设成了0.2秒而实际处理一个报文包括文件写入、ACK解析常超过0.3秒大量本不该重传的包因为“超时”被重发了。解决把超时设置和实际处理周期分开。先跑一个不带重传的“裸传输”统计从发送到收到ACK的平均间隔把这个值乘以2作为超时基线后续每次重传都采用指数退避。建议的最小基线是0.5秒局域网也要留足。5.3 序号回绕后比较“大于/小于”判断错误现象窗口开着开着明明丢包不严重接收方却总是把数据当成重复的丢弃发送方一直重复重传文件大小始终不对。原因用“ack_seq base”判断ACK的先进性。当序号回绕比如base250收到一个ACK2这个ACK其实代表期待序号2它明明比250更新但按数值判断“2小于250”就被忽略了。解决用“seq - base”的结果来判断。如果(ack_seq - base) % SPEC_RANGE SPEC_RANGE/2就认为是新ACK否则旧ACK。这是TCP里标准的前后比较方法用序号环形的“距离”代替直线数值比较。注意这里的SPEC_RANGE必须是2的幂或至少是窗口的两倍否则距离计算会出错。5.4 接收端socket缓冲区溢出丢包全被算到网络上现象传输正常但抓包发现很多数据包在局域网内已经到达了接收端网卡应用程序却没收到重传率很高。原因UDP接收缓冲区过小Windows默认8KBLinux默认208KB。发送端每秒发出几MB数据接收程序来不及recvfrom缓冲区一满内核就把新到的数据报丢弃。解决用setsockopt把接收缓冲区调大比如sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 210241024)同时发送端用SEND_INTERVAL限制发送速率让接收端有足够时间处理。这两个参数要配合只调缓冲区不控速率缓冲区还是会满。调完后用ss -ulnp或netstat -nu观察收包统计确认Recv-Q不再堆积。5.5 ACK丢失后沉默策略失效发送方无谓重传现象丢包率只有1%时重传率飙到10%以上。原因发送方窗口里有20个未确认序号接收方收到重复包后保持沉默而发送方每轮只重发一个超时包其余19个要等下一轮才能重发。期间网络实际上是畅通的但发送方不知道白白等了很长的超时周期。解决流水线模式下接收方收到重复包时应当发一个“重复ACK”报文里携带期待的序号这样发送方一旦收到重复ACK就立刻重发该序号而不是等待超时。这其实就是快速重传的雏形。代码上只需在接收端“重复包”分支里不再沉默改回发送ACK。要记住停等协议沉默省带宽流水线协议重复ACK防卡顿策略要随场景切换。6. 验证协议可靠性的三个手段失败注入、吞吐观测与回传率写完协议后千万不要直接在“无丢包、无延迟”的本地回环上测一次说“一切正常”那是自己骗自己。我平时会花半小时做一套能重复执行的验证脚本每次改动协议配置后都跑一遍避免回归。第一件要做的是丢包模拟器。Windows和Linux都可以设置带宽和丢包率但最省事的是在协议层注入发送方用一个概率函数决定是否实际把报文丢进socket。这个丢包器只在测试时启生产环境不启用。参数推荐低丢包率0.5%测基本功能高丢包率5%测拥塞控制是否生效。运行10轮对比文件MD5是否一致。import random def send_with_loss(sock, pkt, addr, loss_rate0.02): # 按概率“假装发送成功”实际不发也不写timer模拟丢包 if random.random() loss_rate: return False sock.sendto(pkt, addr) return True第二件是统计重传率。收发双方各维护一个计数器发送方统计“实际调用sendto的总次数”和“成功收到的ACK总数”比值就是重传率。健康状态下局域网5%丢包实验的重传率应控制在12%以内如果超过30%说明超时设置或重传策略有问题。我一般把统计数据写进日志最后用Python脚本解析log算平均值和峰值。第三件是做乱序注入。在发送方每10个包里有2个交换发送顺序。接收方如果采用SR缓存文件仍能完整收到如果采用GBN且没有缓存乱序会导致大量重传吞吐明显下降。这一步是用来验证你选择的接收策略是否真的扛得住乱序的不只是理论分析。我的习惯是每改一个参数窗口大小、超时时间、丢包率就把三项测试的结果记在一个表格里横轴是配置纵轴是吞吐和重传率。这样调参不再是“拍脑袋”而是转化成数据和选择的工具。这套流程做完你手上这套基于Python实现的自定义可靠传输协议才敢说是真的可以交给别人用、放进实验报告或论文里的。希望帮到你。本文还有配套的精品资源点击获取