尧图网页设计 
简介基于TCP协议的文件传输服务器完整项目使用Visual Studio 2015与C编写面向网络编程初学者及需要实现可靠文件传输功能的开发者。项目演示了Socket建立连接、文件名与大小预传输、服务端目录校验与文件创建、TCP确认与重传保障数据完整、四次挥手关闭连接等关键流程可清晰理解面向连接的字节流通信机制。资源共42个文件以cpp/h源代码、sln/vcxproj工程文件、exe/obj/pdb编译产物、rc/ico资源文件为主压缩包67.33MB附带可执行程序便于直接运行和调试。已有1520人学习适合课程设计、毕业设计或自学Socket编程也可作为实现断点续传、多线程处理、加密传输等扩展功能的起点。 TCP文件传输服务器这个需求看起来简单真做起来坑不少。市面上FTP、HTTP传文件都有现成方案但很多场景——比如内网设备互联、嵌入式板子对接、自定义协议联调、甚至是给老系统的C#客户端做数据通道——你绕不开直接用TCP写一个。我这几年先后用Python、C#、Qt都写过这类服务端踩过的坑可以列一长串。这篇就把从协议设计到落地实现的过程完整拆开讲适合准备自己动手实现TCP文件传输、但又不想照抄网上残缺demo的读者。1. 先想清楚文件传输场景下TCP凭什么能站住1.1 选TCP还是UDP不只是看可靠两个字很多文章一上来就说“TCP可靠所以适合传文件”这话对但不完整。传文件这件事真正要的是数据完整、顺序一致、重复可控。TCP的确认重传机制天然保证这三件事你不需要在应用层再实现一套滑动窗口和超时重传。UDP在文件传输里不是不能用像一些高清录播、视频推流场景为了低延迟确实会用UDP或者RUDP但你得自己处理丢包重传、乱序重组、流控工程量完全不在一个量级。实际项目中我见过不少团队为了一点点性能去折腾UDP传文件最后都后悔。文件传输对延迟没那么敏感但错误绝对不能容忍——一个字节错了整个包就废了。UDP适合的是“丢了就丢了没关系”的数据文件显然不属于这一类。所以常规文件传输TCP就是最省心的底座。1.2 三次握手四次挥手理解了才不容易写错代码当你调用connect()成功返回时背后已经走完了一次三次握手。这个过程保证了双方都知道“链路是通的”但注意——这个“通”是双向的、基于系统协议栈的探测并不代表对端应用层已经就绪。很多人在客户端connect成功后就立刻send()大块数据结果服务端处理还卡在建立连接的逻辑里数据就丢了一部分。这不是握手的问题而是你对“握手完成”和“应用就绪”之间那个时间差没有敬畏。四次挥手的问题更隐蔽。主动关闭的一方会进入TIME_WAIT状态默认等待约2个报文最大生存期2MSLLinux上通常是60秒。如果你的服务端每次处理完一个文件就主动close()在高频次连接场景下你会发现端口被大量TIME_WAIT占用新连接起不来报错就是那行经典的only one usage of each socket address。这不是玄学是TCP本身的状态机机制。解决方案之一就是下面要讲的SO_REUSEADDR但根本思路是减少连接频率别传一个小文件就断开一次。2. 传输协议设计传文件不只是把字节丢进socket2.1 元数据必须先行文件名、大小、校验值一个不能少裸的TCP就是一条字节管道你往里面倒什么它就是什么。但接收方怎么知道“这个字节流什么时候开始、什么时候结束、这是哪个文件”所以必须在数据之前定义一个明确的应用层协议头。我习惯的做法是先发4字节固定长度的包头里面存的是JSON元数据区的长度然后是JSON元数据最后才是文件二进制内容。结构就是4字节大端整数header_lenheader_len字节的JSON元数据比如{filename: test.bin, filesize: 1048576, md5: xxx}后续纯文件字节流为什么不用固定长度的二进制结构体因为JSON可扩展性强以后想加个filetime、uploader字段不用改协议版本号解析也方便。固定结构体性能确实好一点但代价是每一端都要维护结构对齐改一个字段两边都得同步改调试周期长。个人项目、内部系统JSON够用了。校验值强烈建议算。平时传传文本文件出错了不明显但压缩包、固件、程序文件错一个字节就全废。MD5计算压力不大SHA256更稳看你们对安全等级的要求。2.2 缓冲区大小和分包策略决定传输效率的天花板TCP没有“消息边界”只有字节流。但TCP有一个很重要的特性它内部会帮你做分段和重排。应用层每次send()多大的块不代表对方每次recv()就拿到多大的块。所以接收端必须要做“读满期望字节数”的逻辑也就是所谓精确读取recv_exact否则就会出现粘包、半包问题。缓冲区大小上我实测下来64KB65536字节是比较甜点的值。太小比如1KB系统调用次数多CPU都在空转太大比如10MB反而会在内存占用和内核缓冲之间产生瓶颈还容易碰到并发场景下的内存压力。一次读64KB配合循环读取既平滑又不浪费。发送端还有一个容易忽略的点别一次性把整个文件读进内存再发送。一个4GB的视频文件你试试把整个文件read()进来内存直接爆炸。正确做法是按块读取按块发送配合一个简单的游标记录进度这样还能顺便做百分比显示。2.3 粘包拆包新手最容易翻车的地方网上问TCP文件传输的帖子十个有八个在问“为什么服务端收到的数据是乱的”。这基本就是没处理粘包拆包。TCP是流协议应用层看到的是连续的字节流你send了三次对端recv可能一次就全拿走了也可能分五次才拿完。解决办法就是上面说的长度前缀法length-prefix framing。所有应用层消息都带上长度信息接收端先读长度再按长度读完整消息。文件二进制流的“长度”就是header里的filesize字段读完这个长度就代表文件结束了不需要额外加结束标志。这也是为什么我强烈建议在头部放filesize——它同时解决了拆包和判断文件结束两件事。3. 从零实现一个能直接复用的TCP文件传输服务器3.1 服务端骨架先解决监听和并发模型最大的一个设计决策是单线程串行还是多线程/多进程/异步我给出最直观的建议文件传输是典型的I/O密集型阻塞操作如果文件很小几百KB单线程accept连接然后一个接一个处理完全跑得动但只要文件一大或者同时来两个客户端单线程就会把第二个请求活活饿死。实际项目里我最常用的是threading模块每个连接一个线程逻辑简单读起来也直白。更激进的可以用asyncio但文件I/O和多路复用的组合写起来复杂度翻倍收益对中小项目来说不明显。先贴服务端的核心代码import socket import json import os import struct import hashlib import threading def recv_exact(conn, n): data b while len(data) n: chunk conn.recv(n - len(data)) if not chunk: raise ConnectionError(connection closed by peer) data chunk return data def handle_client(conn, addr, save_dir): try: header_len struct.unpack(I, recv_exact(conn, 4))[0] header json.loads(recv_exact(conn, header_len).decode(utf-8)) filename os.path.basename(header[filename]) # 防目录穿越 filesize int(header[filesize]) expect_md5 header.get(md5, ) save_path os.path.join(save_dir, filename) received 0 md5 hashlib.md5() with open(save_path, wb) as f: while received filesize: chunk conn.recv(min(65536, filesize - received)) if not chunk: break f.write(chunk) received len(chunk) md5.update(chunk) ack struct.pack(Q, received) conn.sendall(ack) if received filesize and (not expect_md5 or md5.hexdigest() expect_md5): conn.sendall(bOK) else: conn.sendall(bERROR) except Exception as e: print(f[error] {addr}: {e}) finally: conn.close() def main(): server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((0.0.0.0, 9000)) server.listen(5) print(TCP file server listening on 0.0.0.0:9000) save_dir ./uploads os.makedirs(save_dir, exist_okTrue) while True: conn, addr server.accept() print(f[connect] {addr}) threading.Thread(targethandle_client, args(conn, addr, save_dir), daemonTrue).start() if __name__ __main__: main()这里几个细节值得单独说。SO_REUSEADDR放在bind()之前设置作用有两点一是允许服务器重启时立刻重新绑定同一个端口不用干等60秒的TIME_WAIT二是在多网卡环境下让系统决定绑定哪个地址的细节变得更宽容。这个socket选项应该成为TCP服务器的标配否则你每次改代码重启服务都要被“地址已被占用”折磨一遍。os.path.basename()处理文件名是有安全考虑的。客户端传过来的filename如果带了路径分隔符直接拼到保存目录下就可能写出指定目录之外。这个操作在网络安全测试里叫目录穿越你在内网自己玩可能无所谓但只要服务可能对外开放这个坑必须堵住。3.2 客户端实现发送带元数据的文件流客户端逻辑和服务端对称。先算文件MD5再构造JSON头部然后一块一块读文件发送。每发一块等服务端的进度确认这样客户端可以实时知道服务端已经落盘了多少字节而不是傻乎乎地一直send到内核缓冲区堆满。import socket import json import os import struct import hashlib def recv_exact(conn, n): data b while len(data) n: chunk conn.recv(n - len(data)) if not chunk: raise ConnectionError(connection closed by peer) data chunk return data def send_file(host, port, filepath, chunk_size65536): filesize os.path.getsize(filepath) filename os.path.basename(filepath) md5 hashlib.md5() with open(filepath, rb) as f: for chunk in iter(lambda: f.read(chunk_size), b): md5.update(chunk) header json.dumps({ filename: filename, filesize: filesize, md5: md5.hexdigest() }).encode(utf-8) conn socket.socket(socket.AF_INET, socket.SOCK_STREAM) conn.settimeout(10) conn.connect((host, port)) conn.sendall(struct.pack(I, len(header))) conn.sendall(header) sent 0 with open(filepath, rb) as f: while sent filesize: chunk f.read(chunk_size) if not chunk: break conn.sendall(chunk) sent len(chunk) ack struct.unpack(Q, recv_exact(conn, 8))[0] percent ack / filesize * 100 print(f\rprogress: {ack}/{filesize} ({percent:.1f}%), end, flushTrue) print() result conn.recv(2) print(server response:, result.decode(utf-8)) conn.close()recv_exact在客户端同样重要。你按进度确认类型用的是8字节无符号整数Q那读取确认时就必须读满8字节不能只recv(8)一次就当读完了——我就踩过这种坑极端情况下一次recv只返回了4字节后面的4字节留到下次结果解析出来的ack直接错乱。所有按长度读取的地方都必须套用recv_exact这是TCP编程里最基础也最容易被忽略的铁律。超时设置也是必须的。settimeout(10)让所有阻塞操作都带上10秒上限防止服务端宕机后客户端无限期卡在connect()或者某个recv()上。如果你不做这个设置TCP栈在连接失败时的超时时间往往要等上几分钟甚至更久用户体验极差。3.3 断点续传和并发处理这两个能力要不要一开始就加断点续传是很多人拿到代码后第一个想加的需求。思路是用一个专门的续传请求来告知服务端“我从第N字节开始继续传”服务端打开文件并seek到N位置接着写但校验值只能对完整文件验证续传片段无法做单独校验所以最后还是要做整体校验。设计上不复杂但会明显增加协议复杂度比如要新增“续传请求”“服务端确认起始位置”“文件是否存在”等交互。首次实现时我建议先不做把基础链路跑通查错验证都没问题了再往上面加。并发场景要注意的则是磁盘I/O的竞争。多线程同时写文件、同时刷盘如果存储是机械硬盘性能会断崖式下跌。真要并发接收大文件方向是搞个队列把落盘操作串行化或者按客户端IP/文件名做哈希分流到不同目录甚至不同磁盘。并发这件事业务量没到之前先别急着优化但架构上要预留出能扩展的口子。4. 实测中的那些坑问题现象、排查思路与最终解法4.1 bind报错only one usage of each socket address这行报错的完整形态是类似error: listen tcp 127.0.0.1:9000: bind: only one usage of each socket address。看到它基本上就两个原因端口被别的进程占用了或者你上次的进程还在TIME_WAIT状态没退出。排查第一步是netstat -ano | grep 9000看端口被谁占着如果是你自己上次启动的服务还残留TIME_WAIT那就等30-60秒或者重启前加SO_REUSEADDR。如果端口被完全无关的程序占用那就是端口冲突直接换端口或者把那个进程处理掉。注意SO_REUSEADDR解决的是TIME_WAIT不是“端口被另一个正在监听的服务占用”后者谁也救不了你。4.2 connection reset by peer一半以上的原因是“在错误的时间发数据”TCP connection reset by peer这句话能排进TCP问题最常出现的榜单前三。它的本质是对端进程已经不存在了或者对端的协议栈主动给了个RST包。常见原因有这么几类一是接收方进程崩溃了它的内核会收到底层某个错误从而发RST。二是发送方写完数据后立刻close()但接收方还有没读完的数据接收方协议栈检测到“你有数据没读完就关了”直接回RST。三是防火墙或中间设备主动干预。排查时先看服务端进程是否还活着再看是不是自己的close时机有问题——如果你发送完就直接单方面close很多情况下确实会触发这个错。正确做法是想确认对方已经把数据完整收走发送方先shutdown(SHUT_WR)表示“我不再发数据了但还能收”等对方返回确认再close()。4.3 连接超时别急着怀疑代码先打一遍链路客户端connect超时第一反应别去改代码。先在本机telnet 目标IP 端口或者nc -vz 目标IP 端口确认TCP层能不能通。如果是跨机器还要查两个方向目标机器的防火墙有没有放行这个端口云服务器的话还要看安全组规则。我自己就干过这种事本地直连好好的部署到Linux云服务器上怎么都连不上查了半天才发现安全组只开了22和809000端口根本没放行。还有一种情况是服务端虽然监听了但监听地址是127.0.0.1而不是0.0.0.0。这时远程连当然超时——服务端压根就没在对外网卡上监听。这个点很隐蔽写代码时bind((127.0.0.1, port))看着没问题日志也显示监听成功了但外部就是连不上。开发调试可以用回环地址正式服务一定要bind到0.0.0.0或指定业务网卡地址。4.4 大文件传输卡死与内存暴涨超过2GB的文件注意你选的数据类型。filesize如果用有符号32位整数表示最大只能到2147483647字节约2GB超了直接溢出变负数。所以前面代码里进度确认用的是Q无符号64位整数2EB之前不用担心。同理接收端不要预先分配一个大list去装所有chunk再统一写盘必须边收边写。我见过有人把接收到的所有数据append到bytes里最后一次性写文件传几个GB的文件直接内存拉满然后进程被系统杀掉。针对大文件的另一个建议是服务端边收边实时算MD5不要等文件全部收完再从头读一遍算校验。大文件单独再读一遍的耗时相当于白白又做了一次磁盘读写。边收边算不会拖慢传输最后的校验结果却能立刻反馈给客户端。5. 一些可以少走弯路的扩展方向等你把这套基础链路跑通了回头看很多生产需求其实就是在这个骨架上做加法。比如要跟Linux服务器之间互传文件可以加一个简单命令行的参数解析做成一个receive模式和一个send模式。想集成到现有系统里可以把核心收发逻辑封装成类留出“打印进度回调”和“传输完成回调”的接口。还有一个我越来越推荐的演进路线如果传输的文件数量多、还要做文件列表同步、断点续传、多客户端管理那直接在这套代码基础上硬堆是不明智的不如直接迁移到现成协议上。比如用HTTP的分块上传或用SFTP这类基于SSH通道的现成方案大厂和开源社区已经帮你踩平了绝大多数坑。自研TCP文件传输真正的价值在于学习TCP机制本身以及实现高度定制化的私有协议——比如你的嵌入式板子只能解析自定义帧格式或者你的业务需要在传输过程中实时加密、实时压缩这些场景下现成方案反而绑手绑脚。做过几轮之后我自己的体会是TCP文件传输服务器的难点从来不在“把socket连通”而在协议设计、边界处理和故障排查这三件事上。把元数据先行、长度前缀、精确读取、状态确认、超时控制这五个点想透你再写任何基于TCP的业务——不管是文件、消息还是指令流——都会顺手很多。本文还有配套的精品资源点击获取 TCP文件传输服务器从零实现：协议设计、粘包处理与踩坑实战
简介基于TCP协议的文件传输服务器完整项目使用Visual Studio 2015与C编写面向网络编程初学者及需要实现可靠文件传输功能的开发者。项目演示了Socket建立连接、文件名与大小预传输、服务端目录校验与文件创建、TCP确认与重传保障数据完整、四次挥手关闭连接等关键流程可清晰理解面向连接的字节流通信机制。资源共42个文件以cpp/h源代码、sln/vcxproj工程文件、exe/obj/pdb编译产物、rc/ico资源文件为主压缩包67.33MB附带可执行程序便于直接运行和调试。已有1520人学习适合课程设计、毕业设计或自学Socket编程也可作为实现断点续传、多线程处理、加密传输等扩展功能的起点。 TCP文件传输服务器这个需求看起来简单真做起来坑不少。市面上FTP、HTTP传文件都有现成方案但很多场景——比如内网设备互联、嵌入式板子对接、自定义协议联调、甚至是给老系统的C#客户端做数据通道——你绕不开直接用TCP写一个。我这几年先后用Python、C#、Qt都写过这类服务端踩过的坑可以列一长串。这篇就把从协议设计到落地实现的过程完整拆开讲适合准备自己动手实现TCP文件传输、但又不想照抄网上残缺demo的读者。1. 先想清楚文件传输场景下TCP凭什么能站住1.1 选TCP还是UDP不只是看可靠两个字很多文章一上来就说“TCP可靠所以适合传文件”这话对但不完整。传文件这件事真正要的是数据完整、顺序一致、重复可控。TCP的确认重传机制天然保证这三件事你不需要在应用层再实现一套滑动窗口和超时重传。UDP在文件传输里不是不能用像一些高清录播、视频推流场景为了低延迟确实会用UDP或者RUDP但你得自己处理丢包重传、乱序重组、流控工程量完全不在一个量级。实际项目中我见过不少团队为了一点点性能去折腾UDP传文件最后都后悔。文件传输对延迟没那么敏感但错误绝对不能容忍——一个字节错了整个包就废了。UDP适合的是“丢了就丢了没关系”的数据文件显然不属于这一类。所以常规文件传输TCP就是最省心的底座。1.2 三次握手四次挥手理解了才不容易写错代码当你调用connect()成功返回时背后已经走完了一次三次握手。这个过程保证了双方都知道“链路是通的”但注意——这个“通”是双向的、基于系统协议栈的探测并不代表对端应用层已经就绪。很多人在客户端connect成功后就立刻send()大块数据结果服务端处理还卡在建立连接的逻辑里数据就丢了一部分。这不是握手的问题而是你对“握手完成”和“应用就绪”之间那个时间差没有敬畏。四次挥手的问题更隐蔽。主动关闭的一方会进入TIME_WAIT状态默认等待约2个报文最大生存期2MSLLinux上通常是60秒。如果你的服务端每次处理完一个文件就主动close()在高频次连接场景下你会发现端口被大量TIME_WAIT占用新连接起不来报错就是那行经典的only one usage of each socket address。这不是玄学是TCP本身的状态机机制。解决方案之一就是下面要讲的SO_REUSEADDR但根本思路是减少连接频率别传一个小文件就断开一次。2. 传输协议设计传文件不只是把字节丢进socket2.1 元数据必须先行文件名、大小、校验值一个不能少裸的TCP就是一条字节管道你往里面倒什么它就是什么。但接收方怎么知道“这个字节流什么时候开始、什么时候结束、这是哪个文件”所以必须在数据之前定义一个明确的应用层协议头。我习惯的做法是先发4字节固定长度的包头里面存的是JSON元数据区的长度然后是JSON元数据最后才是文件二进制内容。结构就是4字节大端整数header_lenheader_len字节的JSON元数据比如{filename: test.bin, filesize: 1048576, md5: xxx}后续纯文件字节流为什么不用固定长度的二进制结构体因为JSON可扩展性强以后想加个filetime、uploader字段不用改协议版本号解析也方便。固定结构体性能确实好一点但代价是每一端都要维护结构对齐改一个字段两边都得同步改调试周期长。个人项目、内部系统JSON够用了。校验值强烈建议算。平时传传文本文件出错了不明显但压缩包、固件、程序文件错一个字节就全废。MD5计算压力不大SHA256更稳看你们对安全等级的要求。2.2 缓冲区大小和分包策略决定传输效率的天花板TCP没有“消息边界”只有字节流。但TCP有一个很重要的特性它内部会帮你做分段和重排。应用层每次send()多大的块不代表对方每次recv()就拿到多大的块。所以接收端必须要做“读满期望字节数”的逻辑也就是所谓精确读取recv_exact否则就会出现粘包、半包问题。缓冲区大小上我实测下来64KB65536字节是比较甜点的值。太小比如1KB系统调用次数多CPU都在空转太大比如10MB反而会在内存占用和内核缓冲之间产生瓶颈还容易碰到并发场景下的内存压力。一次读64KB配合循环读取既平滑又不浪费。发送端还有一个容易忽略的点别一次性把整个文件读进内存再发送。一个4GB的视频文件你试试把整个文件read()进来内存直接爆炸。正确做法是按块读取按块发送配合一个简单的游标记录进度这样还能顺便做百分比显示。2.3 粘包拆包新手最容易翻车的地方网上问TCP文件传输的帖子十个有八个在问“为什么服务端收到的数据是乱的”。这基本就是没处理粘包拆包。TCP是流协议应用层看到的是连续的字节流你send了三次对端recv可能一次就全拿走了也可能分五次才拿完。解决办法就是上面说的长度前缀法length-prefix framing。所有应用层消息都带上长度信息接收端先读长度再按长度读完整消息。文件二进制流的“长度”就是header里的filesize字段读完这个长度就代表文件结束了不需要额外加结束标志。这也是为什么我强烈建议在头部放filesize——它同时解决了拆包和判断文件结束两件事。3. 从零实现一个能直接复用的TCP文件传输服务器3.1 服务端骨架先解决监听和并发模型最大的一个设计决策是单线程串行还是多线程/多进程/异步我给出最直观的建议文件传输是典型的I/O密集型阻塞操作如果文件很小几百KB单线程accept连接然后一个接一个处理完全跑得动但只要文件一大或者同时来两个客户端单线程就会把第二个请求活活饿死。实际项目里我最常用的是threading模块每个连接一个线程逻辑简单读起来也直白。更激进的可以用asyncio但文件I/O和多路复用的组合写起来复杂度翻倍收益对中小项目来说不明显。先贴服务端的核心代码import socket import json import os import struct import hashlib import threading def recv_exact(conn, n): data b while len(data) n: chunk conn.recv(n - len(data)) if not chunk: raise ConnectionError(connection closed by peer) data chunk return data def handle_client(conn, addr, save_dir): try: header_len struct.unpack(I, recv_exact(conn, 4))[0] header json.loads(recv_exact(conn, header_len).decode(utf-8)) filename os.path.basename(header[filename]) # 防目录穿越 filesize int(header[filesize]) expect_md5 header.get(md5, ) save_path os.path.join(save_dir, filename) received 0 md5 hashlib.md5() with open(save_path, wb) as f: while received filesize: chunk conn.recv(min(65536, filesize - received)) if not chunk: break f.write(chunk) received len(chunk) md5.update(chunk) ack struct.pack(Q, received) conn.sendall(ack) if received filesize and (not expect_md5 or md5.hexdigest() expect_md5): conn.sendall(bOK) else: conn.sendall(bERROR) except Exception as e: print(f[error] {addr}: {e}) finally: conn.close() def main(): server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((0.0.0.0, 9000)) server.listen(5) print(TCP file server listening on 0.0.0.0:9000) save_dir ./uploads os.makedirs(save_dir, exist_okTrue) while True: conn, addr server.accept() print(f[connect] {addr}) threading.Thread(targethandle_client, args(conn, addr, save_dir), daemonTrue).start() if __name__ __main__: main()这里几个细节值得单独说。SO_REUSEADDR放在bind()之前设置作用有两点一是允许服务器重启时立刻重新绑定同一个端口不用干等60秒的TIME_WAIT二是在多网卡环境下让系统决定绑定哪个地址的细节变得更宽容。这个socket选项应该成为TCP服务器的标配否则你每次改代码重启服务都要被“地址已被占用”折磨一遍。os.path.basename()处理文件名是有安全考虑的。客户端传过来的filename如果带了路径分隔符直接拼到保存目录下就可能写出指定目录之外。这个操作在网络安全测试里叫目录穿越你在内网自己玩可能无所谓但只要服务可能对外开放这个坑必须堵住。3.2 客户端实现发送带元数据的文件流客户端逻辑和服务端对称。先算文件MD5再构造JSON头部然后一块一块读文件发送。每发一块等服务端的进度确认这样客户端可以实时知道服务端已经落盘了多少字节而不是傻乎乎地一直send到内核缓冲区堆满。import socket import json import os import struct import hashlib def recv_exact(conn, n): data b while len(data) n: chunk conn.recv(n - len(data)) if not chunk: raise ConnectionError(connection closed by peer) data chunk return data def send_file(host, port, filepath, chunk_size65536): filesize os.path.getsize(filepath) filename os.path.basename(filepath) md5 hashlib.md5() with open(filepath, rb) as f: for chunk in iter(lambda: f.read(chunk_size), b): md5.update(chunk) header json.dumps({ filename: filename, filesize: filesize, md5: md5.hexdigest() }).encode(utf-8) conn socket.socket(socket.AF_INET, socket.SOCK_STREAM) conn.settimeout(10) conn.connect((host, port)) conn.sendall(struct.pack(I, len(header))) conn.sendall(header) sent 0 with open(filepath, rb) as f: while sent filesize: chunk f.read(chunk_size) if not chunk: break conn.sendall(chunk) sent len(chunk) ack struct.unpack(Q, recv_exact(conn, 8))[0] percent ack / filesize * 100 print(f\rprogress: {ack}/{filesize} ({percent:.1f}%), end, flushTrue) print() result conn.recv(2) print(server response:, result.decode(utf-8)) conn.close()recv_exact在客户端同样重要。你按进度确认类型用的是8字节无符号整数Q那读取确认时就必须读满8字节不能只recv(8)一次就当读完了——我就踩过这种坑极端情况下一次recv只返回了4字节后面的4字节留到下次结果解析出来的ack直接错乱。所有按长度读取的地方都必须套用recv_exact这是TCP编程里最基础也最容易被忽略的铁律。超时设置也是必须的。settimeout(10)让所有阻塞操作都带上10秒上限防止服务端宕机后客户端无限期卡在connect()或者某个recv()上。如果你不做这个设置TCP栈在连接失败时的超时时间往往要等上几分钟甚至更久用户体验极差。3.3 断点续传和并发处理这两个能力要不要一开始就加断点续传是很多人拿到代码后第一个想加的需求。思路是用一个专门的续传请求来告知服务端“我从第N字节开始继续传”服务端打开文件并seek到N位置接着写但校验值只能对完整文件验证续传片段无法做单独校验所以最后还是要做整体校验。设计上不复杂但会明显增加协议复杂度比如要新增“续传请求”“服务端确认起始位置”“文件是否存在”等交互。首次实现时我建议先不做把基础链路跑通查错验证都没问题了再往上面加。并发场景要注意的则是磁盘I/O的竞争。多线程同时写文件、同时刷盘如果存储是机械硬盘性能会断崖式下跌。真要并发接收大文件方向是搞个队列把落盘操作串行化或者按客户端IP/文件名做哈希分流到不同目录甚至不同磁盘。并发这件事业务量没到之前先别急着优化但架构上要预留出能扩展的口子。4. 实测中的那些坑问题现象、排查思路与最终解法4.1 bind报错only one usage of each socket address这行报错的完整形态是类似error: listen tcp 127.0.0.1:9000: bind: only one usage of each socket address。看到它基本上就两个原因端口被别的进程占用了或者你上次的进程还在TIME_WAIT状态没退出。排查第一步是netstat -ano | grep 9000看端口被谁占着如果是你自己上次启动的服务还残留TIME_WAIT那就等30-60秒或者重启前加SO_REUSEADDR。如果端口被完全无关的程序占用那就是端口冲突直接换端口或者把那个进程处理掉。注意SO_REUSEADDR解决的是TIME_WAIT不是“端口被另一个正在监听的服务占用”后者谁也救不了你。4.2 connection reset by peer一半以上的原因是“在错误的时间发数据”TCP connection reset by peer这句话能排进TCP问题最常出现的榜单前三。它的本质是对端进程已经不存在了或者对端的协议栈主动给了个RST包。常见原因有这么几类一是接收方进程崩溃了它的内核会收到底层某个错误从而发RST。二是发送方写完数据后立刻close()但接收方还有没读完的数据接收方协议栈检测到“你有数据没读完就关了”直接回RST。三是防火墙或中间设备主动干预。排查时先看服务端进程是否还活着再看是不是自己的close时机有问题——如果你发送完就直接单方面close很多情况下确实会触发这个错。正确做法是想确认对方已经把数据完整收走发送方先shutdown(SHUT_WR)表示“我不再发数据了但还能收”等对方返回确认再close()。4.3 连接超时别急着怀疑代码先打一遍链路客户端connect超时第一反应别去改代码。先在本机telnet 目标IP 端口或者nc -vz 目标IP 端口确认TCP层能不能通。如果是跨机器还要查两个方向目标机器的防火墙有没有放行这个端口云服务器的话还要看安全组规则。我自己就干过这种事本地直连好好的部署到Linux云服务器上怎么都连不上查了半天才发现安全组只开了22和809000端口根本没放行。还有一种情况是服务端虽然监听了但监听地址是127.0.0.1而不是0.0.0.0。这时远程连当然超时——服务端压根就没在对外网卡上监听。这个点很隐蔽写代码时bind((127.0.0.1, port))看着没问题日志也显示监听成功了但外部就是连不上。开发调试可以用回环地址正式服务一定要bind到0.0.0.0或指定业务网卡地址。4.4 大文件传输卡死与内存暴涨超过2GB的文件注意你选的数据类型。filesize如果用有符号32位整数表示最大只能到2147483647字节约2GB超了直接溢出变负数。所以前面代码里进度确认用的是Q无符号64位整数2EB之前不用担心。同理接收端不要预先分配一个大list去装所有chunk再统一写盘必须边收边写。我见过有人把接收到的所有数据append到bytes里最后一次性写文件传几个GB的文件直接内存拉满然后进程被系统杀掉。针对大文件的另一个建议是服务端边收边实时算MD5不要等文件全部收完再从头读一遍算校验。大文件单独再读一遍的耗时相当于白白又做了一次磁盘读写。边收边算不会拖慢传输最后的校验结果却能立刻反馈给客户端。5. 一些可以少走弯路的扩展方向等你把这套基础链路跑通了回头看很多生产需求其实就是在这个骨架上做加法。比如要跟Linux服务器之间互传文件可以加一个简单命令行的参数解析做成一个receive模式和一个send模式。想集成到现有系统里可以把核心收发逻辑封装成类留出“打印进度回调”和“传输完成回调”的接口。还有一个我越来越推荐的演进路线如果传输的文件数量多、还要做文件列表同步、断点续传、多客户端管理那直接在这套代码基础上硬堆是不明智的不如直接迁移到现成协议上。比如用HTTP的分块上传或用SFTP这类基于SSH通道的现成方案大厂和开源社区已经帮你踩平了绝大多数坑。自研TCP文件传输真正的价值在于学习TCP机制本身以及实现高度定制化的私有协议——比如你的嵌入式板子只能解析自定义帧格式或者你的业务需要在传输过程中实时加密、实时压缩这些场景下现成方案反而绑手绑脚。做过几轮之后我自己的体会是TCP文件传输服务器的难点从来不在“把socket连通”而在协议设计、边界处理和故障排查这三件事上。把元数据先行、长度前缀、精确读取、状态确认、超时控制这五个点想透你再写任何基于TCP的业务——不管是文件、消息还是指令流——都会顺手很多。本文还有配套的精品资源点击获取