尧图网页设计 
简介这是一份基于TCP协议实现文件传输的Visual Studio 2015工程源码包面向学习Windows网络编程、C/C#Socket通信或需要搭建简易文件传输服务的开发者。项目完整展示了服务器与客户端建立连接、预传文件名与大小、按路径创建文件、可靠接收数据以及关闭连接等核心流程并附有Debug目录下的可执行文件与调试符号便于直接运行和跟踪验证。压缩包共42个文件主要包含.cpp/.h源码、.rc界面资源、.sln/.vcxproj工程配置、.tlog/.obj/.pdb编译中间文件以及.ico/.aps等资源文件整体约67.33MB结构清晰适合对照学习TCP粘包处理、Socket阻塞收发及MFC对话框程序组织方式。目前已有1520人学习下载代码量适中可直接作为课程设计或毕业设计的参考基础也可在此之上扩展断点续传、多线程并发、加密传输等功能。1. 内网设备升级逼我重新写了一个TCP传输服务最近在给一台边缘网关做固件升级设备端没有Web容器、没有HTTP服务只有一段裸的Socket监听逻辑。要在局域网内把大约几十MB的固件包从PC推过去最直接的办法就是起一个TCP文件传输服务器让网关主动连过来拉数据。这类场景在工业设备、嵌入式板卡、小型IoT网关里很常见HTTP头太重设备固件里根本没集成协议栈之外的库UDP又不可靠固件传一半丢包了设备直接变砖的例子我见过不止一次。所以TCP就成了最稳妥、最少依赖的选择。我把自己重新折腾这套基础服务的完整过程梳理一下包括协议头怎么设计、粘包怎么处理、服务器代码怎么写、以及上线之后容易遇到的连接超时、连接重置和端口占用问题。适合正打算自己搭TCP文件传输服务的人参考或者你在调试类似Socket问题时对照排查。2. TCP不丢消息但它也不替你分消息粘包才是第一个敌人2.1 先把“流”这个概念吃透TCP在传输层是一个面向连接的、可靠的字节流协议。三次握手建立连接、四次挥手断开连接这些是TCP的“规矩”但不是我们写文件传输时最需要关心的重点。真正影响代码设计的是“字节流”三个字TCP本身没有任何消息边界它只知道把字节按顺序从一端搬到另一端。你调用一次sendall发出去的数据对端可能分三次才收到反过来你两次send之间接收方也可能把两段数据合并成一次recv读出来。这就是俗称的“粘包”本质上是TCP把数据切成了任意大小的段再交给应用层时并不保证和你发送时的分割一致。做个生活化类比你把三本书依次扔进传送带传送带把书送到对面对面的人拿到的顺序一定是对的但书和书之间没有隔板他可能把三本推成一摞一起递给你也可能某一本书被切成了两半先后送到。这个“切和拼”的动作完全由系统内核和网络状况决定应用层插不上手。2.2 好消息我们可以在应用层自己“加边框”既然TCP不提供边界那就在协议里自己定义边界。最常见的方法有两种固定长度头部每次发送前先固定发若干字节的消息头比如4字节表示文件名长度、8字节表示文件大小接收方严格按这个长度去读读满再解析下一个结构。分隔符以换行符或特殊字符分隔消息适合短文本命令不适合二进制文件因为文件内容里可能恰好出现同样的分隔符。做文件传输必须用固定长度头部因为文件内容是二进制你不能在数据里寻找结束标记。核心逻辑就一句话先收定长包头解析出后续载荷的长度再精确读取那么多字节的载荷。这个逻辑会贯穿整个客户端和服务器的实现后面代码里我会反复用到它。2.3 TCP缓冲区与发送频率还有一个容易忽略的点发送端和接收端各自有系统缓冲区recv(65536)并不代表最多只收到65536字节而是“最多从内核缓冲区拷贝65536字节出来”。如果对端发送速度极快而应用层没有及时取出数据内核缓冲区满了以后TCP会通过滑动窗口机制自动要求对端降速这就是流量控制。所以合理的分块大小既能避免拷贝过多无用数据也能让缓冲区保持健康水位。实测下来1KB到256KB之间的分块对绝大多数局域网文件传输都有不错的效果我习惯用64KB折中内存占用和系统调用次数。3. 开工前先设计协议再写代码四件事必须提前定清楚很多人一上来就写send和recv结果测试时小文件没问题几十MB大文件传一半就卡死或者文件名带了中文就乱码。这些坑大多不是因为代码写错而是协议头没设计好。3.1 协议头怎么定义我建议至少包含这几部分字段长度说明魔数4字节用于快速识别非法连接比如0xAA55AA55网络字节序文件名长度4字节无符号整数避免文件名里出现空格/中文时解析困难文件名可变UTF-8编码解决中文文件名问题文件大小8字节无符号长整型单位字节最大可表示超过EB的文件文件数据可变按固定块大小分片发送这里有两个设计细节值得展开讲。为什么要魔数。TCP是字节流如果某个客户端发的数据不符合协议服务器应该尽早识别并断开而不是傻等。收到前4字节后和魔数比对不匹配就直接关闭连接并记录日志能挡住很多调试期的手误。为什么要网络字节序。C语言里大端小端的问题大家都懂Python的struct.pack(!IQ, ...)也直接支持网络序一个小写的!就搞定。但如果你用Java或C#写对端或者对接一个嵌入式C设备大小端不一致会造成解析出的长度值完全错乱。所有多字节字段一律使用网络字节序这个习惯能省掉跨语言联调的大量时间。3.2 文件分块与磁盘写入策略服务器收到数据后不是一次性写入磁盘而是边收边写避免占用过多内存。接收循环里每次recv的字节数不要超过自己的缓冲区上限通常和发送端的分块大小保持一致即可。如果一次性把整个文件读进内存再发32GB大文件会直接把服务端内存打爆这个教训几乎每个做文件传输的人都经历过一遍。3.3 传输中断时的落盘策略实际传输中网络抖动、客户端崩溃都可能让文件只传一半。如果服务器直接打开目标文件名并写入那原有文件会被截断或覆盖可能连设备恢复的机会都没有。我习惯先写一个带临时后缀的文件比如xxx.bin.part全部接收完成后再os.replace改名成最终文件。这样即使传输失败磁盘上残留的也只是.part文件原文件完整不受影响。4. 最小可用的传输实现客户端与服务器代码走读选择Python做示例不是因为生产环境只能用Python而是它的socket和struct模块足够直白方便看到每一步在干什么。实际项目中你完全可以用C#、Java、Go重写只要协议一致跨语言通信毫无障碍。4.1 服务器端拆成接收函数和连接处理函数import socket import struct import os CHUNK_SIZE 64 * 1024 MAGIC 0xAA55AA55 def recv_exact(conn: socket.socket, n: int) - bytes: data b while len(data) n: chunk conn.recv(n - len(data)) if not chunk: raise ConnectionError(connection closed while reading) data chunk return data def handle_client(conn: socket.socket, addr): print(f[连接] {addr} 已接入) try: header recv_exact(conn, 16) magic, name_len, file_size struct.unpack(!IIQ, header) if magic ! MAGIC: print(f[丢弃] 非法头部魔数不匹配: {hex(magic)}) return filename_bytes recv_exact(conn, name_len) filename filename_bytes.decode(utf-8) safe_name os.path.basename(filename) tmp_path f{safe_name}.part received 0 with open(tmp_path, wb) as f: while received file_size: remain file_size - received chunk conn.recv(min(CHUNK_SIZE, remain)) if not chunk: raise ConnectionError(connection closed during file transfer) f.write(chunk) received len(chunk) os.replace(tmp_path, safe_name) print(f[完成] {safe_name} 接收完成共 {received} 字节) except Exception as e: print(f[错误] {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(128) print(TCP文件传输服务器已启动监听端口 9000) while True: conn, addr server.accept() handle_client(conn, addr) if __name__ __main__: main()重点说几个位置recv_exact不是系统自带函数必须自己写。它严格读取n字节直到收满或连接断开这是处理定长包头和后续载荷的核心。struct.unpack(!IIQ, header)对应发送端的“网络序uint32 网络序uint32 网络序uint64”正好16字节。os.path.basename用来去掉客户端传过来的路径信息避免恶意客户端传一个../../etc/passwd把文件写到意外位置。这个安全习惯做裸TCP服务时一定要保留。当前代码是串行处理连接一个客户端传完另一个才能接适合调试和简单场景。生产环境一般要加多线程或异步后面单独讲。4.2 客户端sendall比send更可靠import socket import struct import os CHUNK_SIZE 64 * 1024 MAGIC 0xAA55AA55 def send_file(host: str, port: int, filepath: str): filename os.path.basename(filepath) name_bytes filename.encode(utf-8) file_size os.path.getsize(filepath) s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((host, port)) header struct.pack(!IIQ, MAGIC, len(name_bytes), file_size) s.sendall(header) s.sendall(name_bytes) sent 0 with open(filepath, rb) as f: while True: chunk f.read(CHUNK_SIZE) if not chunk: break s.sendall(chunk) sent len(chunk) print(f[完成] 已发送 {sent} 字节) s.close() if __name__ __main__: import sys if len(sys.argv) ! 4: print(f用法: python {sys.argv[0]} 服务器IP 端口 文件路径) sys.exit(1) send_file(sys.argv[1], int(sys.argv[2]), sys.argv[3])sendall会和send有区别send只发一次可能只发送了缓冲区可用空间的一部分需要循环判断返回值sendall会在内部一直重试直到全部字节发完或者连接出现错误。客户端这里用sendall更省心服务器收数据时则必须配合recv_exact来做“必须读满N字节”的逻辑因为recv同样可能一次只取出一部分数据。4.3 跑通一次传输Linux或macOS下分别开两个终端先启动服务器python3 server.py再运行客户端python3 client.py 127.0.0.1 9000 ./test.bin如果一切正常服务器终端会打印[连接] (127.0.0.1, 51234) 已接入 [完成] test.bin 接收完成共 1048576 字节第一次跑通这个流程后你可能会觉得“就这”但真正拿到复杂网络环境里各种让人头疼的连接问题才会冒出来。5. connect超时、connection reset、端口被占用真实排障记录我把这类问题放在单独一节因为代码能跑通和能在线上稳定运行是两回事。很多人在本地用127.0.0.1测试一切正常换成服务器IP或者跨网段就突然不行这时候基本都是下面几个坑。5.1 报错“connect timed out”但IP和端口看起来都没问题connect超时通常意味着目标主机不可达或者防火墙把SYN包丢掉了。排查顺序我建议这样来ping 服务器IP telnet 服务器IP 端口 nc -vz 服务器IP 端口 ss -lntp | grep 9000发现ss里没监听说明服务器进程没起来或者端口配错监听正常但telnet卡住多半是云服务器安全组没放行端口或者本地有iptables/firewalld规则拦截ping不通可能是不同网段路由问题先检查网络配置。还有一个容易被忽略的点服务器绑定的是0.0.0.0还是127.0.0.1差距很大。绑定127.0.0.1只允许本机回环访问跨设备连接必然超时。之前就有个热搜报错“listen tcp 127.0.0.1:11434: bind: only one usage of each socket address”这类问题一半发生在绑定地址归属另一半是端口被占用。局域网服务要暴露给其他机器绑定地址写0.0.0.0别写回环地址。5.2 “tcp connection reset by peer”是谁发起的RSTRSTReset是TCP里用来强制断开连接的控制位。出现Connection reset by peer意思是对方在TCP层面直接强制关闭了连接而不是正常走四次挥手。常见原因有三个对方进程崩溃或有未处理异常Socket被操作系统直接释放内核发送RST对方收到了不期待的载荷比如连接关闭后还有数据继续发过来中间设备负载均衡、防火墙检查到连接空闲超时主动发RST。排查时用tcpdump看连接的生命周期能看到哪一侧先发出了RSTtcpdump -i eth0 host 服务器IP and tcp port 9000 -w trans.pcap抓包后把文件拿到Wireshark里分析重点看标记[RST]的包之前双方各自发了什么能快速定位是服务端异常退出还是客户端对已关闭连接发数据。5.3 “address already in use”和TIME_WAIT的关系服务器重启时报Address already in use相信每个人都遇到过。SO_REUSEADDR能解决大部分场景它允许新socket绑定到处于TIME_WAIT状态的旧地址。如果加了setsockopt还不行多半是端口真的被另一个进程占用了。ss -lntp | grep 9000 lsof -i :9000看到占用进程后确认是不是你的旧服务没杀干净或者端口冲突。TIME_WAIT本身是TCP为可靠关闭设计的机制通常持续60秒大量短连接会堆积大量TIME_WAIT连接这也是为什么高并发文件服务尽量复用长连接而不是每个文件都新建连接。5.4 大数据量传输时速度突然掉到0如果文件传输中途速度断崖式下降注意看是不是接收端缓冲区满了但读取不及时导致TCP窗口变为0对端被迫暂停发送。代码层面可以通过增大接收socket的缓冲区缓解server.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 1024 * 1024)但这只是“缓解”根本解法还是要让应用层及时消费数据并尽快落盘别在业务逻辑里做重计算把接收循环堵住。6. 走向生产环境并发、断点续传、校验与限速6.1 并发模型怎么选上面示例代码是串行处理连接。真要放到生产环境至少要做两件事一是把accept之后的处理放到独立线程或进程去执行二是限制并发数量防止连接数被打满。如果追求高并发Linux下推荐用selectors基于epoll实现单线程异步I/O可以支撑大量空闲连接。但文件传输的特点是单个连接长时间占满CPU和磁盘I/O多线程模型反而更直观。核心点是线程池上限from concurrent.futures import ThreadPoolExecutor with ThreadPoolExecutor(max_workers16) as pool: while True: conn, addr server.accept() pool.submit(handle_client, conn, addr)这个max_workers要根据服务器内存和磁盘吞吐量调整一般8到32之间比较常见。6.2 断点续传不是必须但关键时刻能救命内网传输大文件断网一次就从头开始重传体验很差。实现断点续传需要在协议里增加两个字段起始偏移量和已接收的校验信息。服务器接到请求后先检查本地是否已有部分文件如果有就把已接收长度告诉客户端客户端seek到对应位置继续发送。这种设计对网关FOTA升级、镜像同步这些场景实用性极高。6.3 校验和MD5不是最强的但够用文件传完不代表数据完全一致网络错误虽然被TCP的校验和规避了一部分但存储介质损坏、程序逻辑Bug照样可能导致数据错位。最稳妥的做法是传输结束后客户端和服务端分别计算MD5或SHA256值并对比。为了不重新读一遍整个文件拖慢速度也可以在发送过程中边分块边计算增量哈希。网络层可靠性解决的是“字节到了没有”应用层校验解决的是“字节对没有”这两层不能互相替代。6.4 限速别把生产网络打满文件传输不像网页请求一上来就容易跑满带宽。如果这台服务器还要承担其他业务建议做限速。简单实现可以用令牌桶思想import time class RateLimiter: def __init__(self, bytes_per_sec): self.rate bytes_per_sec self.tokens bytes_per_sec self.updated_at time.time() def consume(self, amount): now time.time() self.tokens (now - self.updated_at) * self.rate self.updated_at now if self.tokens self.rate: self.tokens self.rate if self.tokens amount: time.sleep((amount - self.tokens) / self.rate) self.tokens 0 else: self.tokens - amount每次发送分块前调用consume(len(chunk))就能把发送速度限制在预设值附近。限速值得结合实际网络带宽调整宁可慢一点也别把业务链路堵死。6.5 TCP和UDP、WebSocket的边界在哪里最后说一句关于选型的个人判断。TCP文件传输适合“设备之间直连、没有复杂路由穿透、文件较大且要求完整到达”的场景。UDP适合实时音视频和游戏状态同步能容忍丢包和乱序WebSocket适合浏览器与服务器之间需要双向实时通信的场景但它底层也是TCP只是加了一层HTTP升级握手和帧封装。搞清楚了TCP的定位就不会在选型时拿UDP做文件传输然后拼命做应用层重传也不会非要用WebSocket去连一个只开了TCP端口的嵌入式设备。我实际使用中的体会是裸TCP文件传输服务器虽然看起来“原始”但它的可预测性和低依赖在特定场景里非常有价值。只要你把协议头设计好、粘包处理好、并发和断点续传按需加上这套方案可以稳定跑很久。最后再分享一个小技巧生产服务器上记得加SO_KEEPALIVE并设置合理的TCP保活参数这样设备异常断电后服务器能在几分钟内感知到连接失效自动清理半开连接不会让线程池被一堆僵尸连接占满。本文还有配套的精品资源点击获取 TCP文件传输服务器实战：从协议设计到粘包处理与排障指南
简介这是一份基于TCP协议实现文件传输的Visual Studio 2015工程源码包面向学习Windows网络编程、C/C#Socket通信或需要搭建简易文件传输服务的开发者。项目完整展示了服务器与客户端建立连接、预传文件名与大小、按路径创建文件、可靠接收数据以及关闭连接等核心流程并附有Debug目录下的可执行文件与调试符号便于直接运行和跟踪验证。压缩包共42个文件主要包含.cpp/.h源码、.rc界面资源、.sln/.vcxproj工程配置、.tlog/.obj/.pdb编译中间文件以及.ico/.aps等资源文件整体约67.33MB结构清晰适合对照学习TCP粘包处理、Socket阻塞收发及MFC对话框程序组织方式。目前已有1520人学习下载代码量适中可直接作为课程设计或毕业设计的参考基础也可在此之上扩展断点续传、多线程并发、加密传输等功能。1. 内网设备升级逼我重新写了一个TCP传输服务最近在给一台边缘网关做固件升级设备端没有Web容器、没有HTTP服务只有一段裸的Socket监听逻辑。要在局域网内把大约几十MB的固件包从PC推过去最直接的办法就是起一个TCP文件传输服务器让网关主动连过来拉数据。这类场景在工业设备、嵌入式板卡、小型IoT网关里很常见HTTP头太重设备固件里根本没集成协议栈之外的库UDP又不可靠固件传一半丢包了设备直接变砖的例子我见过不止一次。所以TCP就成了最稳妥、最少依赖的选择。我把自己重新折腾这套基础服务的完整过程梳理一下包括协议头怎么设计、粘包怎么处理、服务器代码怎么写、以及上线之后容易遇到的连接超时、连接重置和端口占用问题。适合正打算自己搭TCP文件传输服务的人参考或者你在调试类似Socket问题时对照排查。2. TCP不丢消息但它也不替你分消息粘包才是第一个敌人2.1 先把“流”这个概念吃透TCP在传输层是一个面向连接的、可靠的字节流协议。三次握手建立连接、四次挥手断开连接这些是TCP的“规矩”但不是我们写文件传输时最需要关心的重点。真正影响代码设计的是“字节流”三个字TCP本身没有任何消息边界它只知道把字节按顺序从一端搬到另一端。你调用一次sendall发出去的数据对端可能分三次才收到反过来你两次send之间接收方也可能把两段数据合并成一次recv读出来。这就是俗称的“粘包”本质上是TCP把数据切成了任意大小的段再交给应用层时并不保证和你发送时的分割一致。做个生活化类比你把三本书依次扔进传送带传送带把书送到对面对面的人拿到的顺序一定是对的但书和书之间没有隔板他可能把三本推成一摞一起递给你也可能某一本书被切成了两半先后送到。这个“切和拼”的动作完全由系统内核和网络状况决定应用层插不上手。2.2 好消息我们可以在应用层自己“加边框”既然TCP不提供边界那就在协议里自己定义边界。最常见的方法有两种固定长度头部每次发送前先固定发若干字节的消息头比如4字节表示文件名长度、8字节表示文件大小接收方严格按这个长度去读读满再解析下一个结构。分隔符以换行符或特殊字符分隔消息适合短文本命令不适合二进制文件因为文件内容里可能恰好出现同样的分隔符。做文件传输必须用固定长度头部因为文件内容是二进制你不能在数据里寻找结束标记。核心逻辑就一句话先收定长包头解析出后续载荷的长度再精确读取那么多字节的载荷。这个逻辑会贯穿整个客户端和服务器的实现后面代码里我会反复用到它。2.3 TCP缓冲区与发送频率还有一个容易忽略的点发送端和接收端各自有系统缓冲区recv(65536)并不代表最多只收到65536字节而是“最多从内核缓冲区拷贝65536字节出来”。如果对端发送速度极快而应用层没有及时取出数据内核缓冲区满了以后TCP会通过滑动窗口机制自动要求对端降速这就是流量控制。所以合理的分块大小既能避免拷贝过多无用数据也能让缓冲区保持健康水位。实测下来1KB到256KB之间的分块对绝大多数局域网文件传输都有不错的效果我习惯用64KB折中内存占用和系统调用次数。3. 开工前先设计协议再写代码四件事必须提前定清楚很多人一上来就写send和recv结果测试时小文件没问题几十MB大文件传一半就卡死或者文件名带了中文就乱码。这些坑大多不是因为代码写错而是协议头没设计好。3.1 协议头怎么定义我建议至少包含这几部分字段长度说明魔数4字节用于快速识别非法连接比如0xAA55AA55网络字节序文件名长度4字节无符号整数避免文件名里出现空格/中文时解析困难文件名可变UTF-8编码解决中文文件名问题文件大小8字节无符号长整型单位字节最大可表示超过EB的文件文件数据可变按固定块大小分片发送这里有两个设计细节值得展开讲。为什么要魔数。TCP是字节流如果某个客户端发的数据不符合协议服务器应该尽早识别并断开而不是傻等。收到前4字节后和魔数比对不匹配就直接关闭连接并记录日志能挡住很多调试期的手误。为什么要网络字节序。C语言里大端小端的问题大家都懂Python的struct.pack(!IQ, ...)也直接支持网络序一个小写的!就搞定。但如果你用Java或C#写对端或者对接一个嵌入式C设备大小端不一致会造成解析出的长度值完全错乱。所有多字节字段一律使用网络字节序这个习惯能省掉跨语言联调的大量时间。3.2 文件分块与磁盘写入策略服务器收到数据后不是一次性写入磁盘而是边收边写避免占用过多内存。接收循环里每次recv的字节数不要超过自己的缓冲区上限通常和发送端的分块大小保持一致即可。如果一次性把整个文件读进内存再发32GB大文件会直接把服务端内存打爆这个教训几乎每个做文件传输的人都经历过一遍。3.3 传输中断时的落盘策略实际传输中网络抖动、客户端崩溃都可能让文件只传一半。如果服务器直接打开目标文件名并写入那原有文件会被截断或覆盖可能连设备恢复的机会都没有。我习惯先写一个带临时后缀的文件比如xxx.bin.part全部接收完成后再os.replace改名成最终文件。这样即使传输失败磁盘上残留的也只是.part文件原文件完整不受影响。4. 最小可用的传输实现客户端与服务器代码走读选择Python做示例不是因为生产环境只能用Python而是它的socket和struct模块足够直白方便看到每一步在干什么。实际项目中你完全可以用C#、Java、Go重写只要协议一致跨语言通信毫无障碍。4.1 服务器端拆成接收函数和连接处理函数import socket import struct import os CHUNK_SIZE 64 * 1024 MAGIC 0xAA55AA55 def recv_exact(conn: socket.socket, n: int) - bytes: data b while len(data) n: chunk conn.recv(n - len(data)) if not chunk: raise ConnectionError(connection closed while reading) data chunk return data def handle_client(conn: socket.socket, addr): print(f[连接] {addr} 已接入) try: header recv_exact(conn, 16) magic, name_len, file_size struct.unpack(!IIQ, header) if magic ! MAGIC: print(f[丢弃] 非法头部魔数不匹配: {hex(magic)}) return filename_bytes recv_exact(conn, name_len) filename filename_bytes.decode(utf-8) safe_name os.path.basename(filename) tmp_path f{safe_name}.part received 0 with open(tmp_path, wb) as f: while received file_size: remain file_size - received chunk conn.recv(min(CHUNK_SIZE, remain)) if not chunk: raise ConnectionError(connection closed during file transfer) f.write(chunk) received len(chunk) os.replace(tmp_path, safe_name) print(f[完成] {safe_name} 接收完成共 {received} 字节) except Exception as e: print(f[错误] {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(128) print(TCP文件传输服务器已启动监听端口 9000) while True: conn, addr server.accept() handle_client(conn, addr) if __name__ __main__: main()重点说几个位置recv_exact不是系统自带函数必须自己写。它严格读取n字节直到收满或连接断开这是处理定长包头和后续载荷的核心。struct.unpack(!IIQ, header)对应发送端的“网络序uint32 网络序uint32 网络序uint64”正好16字节。os.path.basename用来去掉客户端传过来的路径信息避免恶意客户端传一个../../etc/passwd把文件写到意外位置。这个安全习惯做裸TCP服务时一定要保留。当前代码是串行处理连接一个客户端传完另一个才能接适合调试和简单场景。生产环境一般要加多线程或异步后面单独讲。4.2 客户端sendall比send更可靠import socket import struct import os CHUNK_SIZE 64 * 1024 MAGIC 0xAA55AA55 def send_file(host: str, port: int, filepath: str): filename os.path.basename(filepath) name_bytes filename.encode(utf-8) file_size os.path.getsize(filepath) s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((host, port)) header struct.pack(!IIQ, MAGIC, len(name_bytes), file_size) s.sendall(header) s.sendall(name_bytes) sent 0 with open(filepath, rb) as f: while True: chunk f.read(CHUNK_SIZE) if not chunk: break s.sendall(chunk) sent len(chunk) print(f[完成] 已发送 {sent} 字节) s.close() if __name__ __main__: import sys if len(sys.argv) ! 4: print(f用法: python {sys.argv[0]} 服务器IP 端口 文件路径) sys.exit(1) send_file(sys.argv[1], int(sys.argv[2]), sys.argv[3])sendall会和send有区别send只发一次可能只发送了缓冲区可用空间的一部分需要循环判断返回值sendall会在内部一直重试直到全部字节发完或者连接出现错误。客户端这里用sendall更省心服务器收数据时则必须配合recv_exact来做“必须读满N字节”的逻辑因为recv同样可能一次只取出一部分数据。4.3 跑通一次传输Linux或macOS下分别开两个终端先启动服务器python3 server.py再运行客户端python3 client.py 127.0.0.1 9000 ./test.bin如果一切正常服务器终端会打印[连接] (127.0.0.1, 51234) 已接入 [完成] test.bin 接收完成共 1048576 字节第一次跑通这个流程后你可能会觉得“就这”但真正拿到复杂网络环境里各种让人头疼的连接问题才会冒出来。5. connect超时、connection reset、端口被占用真实排障记录我把这类问题放在单独一节因为代码能跑通和能在线上稳定运行是两回事。很多人在本地用127.0.0.1测试一切正常换成服务器IP或者跨网段就突然不行这时候基本都是下面几个坑。5.1 报错“connect timed out”但IP和端口看起来都没问题connect超时通常意味着目标主机不可达或者防火墙把SYN包丢掉了。排查顺序我建议这样来ping 服务器IP telnet 服务器IP 端口 nc -vz 服务器IP 端口 ss -lntp | grep 9000发现ss里没监听说明服务器进程没起来或者端口配错监听正常但telnet卡住多半是云服务器安全组没放行端口或者本地有iptables/firewalld规则拦截ping不通可能是不同网段路由问题先检查网络配置。还有一个容易被忽略的点服务器绑定的是0.0.0.0还是127.0.0.1差距很大。绑定127.0.0.1只允许本机回环访问跨设备连接必然超时。之前就有个热搜报错“listen tcp 127.0.0.1:11434: bind: only one usage of each socket address”这类问题一半发生在绑定地址归属另一半是端口被占用。局域网服务要暴露给其他机器绑定地址写0.0.0.0别写回环地址。5.2 “tcp connection reset by peer”是谁发起的RSTRSTReset是TCP里用来强制断开连接的控制位。出现Connection reset by peer意思是对方在TCP层面直接强制关闭了连接而不是正常走四次挥手。常见原因有三个对方进程崩溃或有未处理异常Socket被操作系统直接释放内核发送RST对方收到了不期待的载荷比如连接关闭后还有数据继续发过来中间设备负载均衡、防火墙检查到连接空闲超时主动发RST。排查时用tcpdump看连接的生命周期能看到哪一侧先发出了RSTtcpdump -i eth0 host 服务器IP and tcp port 9000 -w trans.pcap抓包后把文件拿到Wireshark里分析重点看标记[RST]的包之前双方各自发了什么能快速定位是服务端异常退出还是客户端对已关闭连接发数据。5.3 “address already in use”和TIME_WAIT的关系服务器重启时报Address already in use相信每个人都遇到过。SO_REUSEADDR能解决大部分场景它允许新socket绑定到处于TIME_WAIT状态的旧地址。如果加了setsockopt还不行多半是端口真的被另一个进程占用了。ss -lntp | grep 9000 lsof -i :9000看到占用进程后确认是不是你的旧服务没杀干净或者端口冲突。TIME_WAIT本身是TCP为可靠关闭设计的机制通常持续60秒大量短连接会堆积大量TIME_WAIT连接这也是为什么高并发文件服务尽量复用长连接而不是每个文件都新建连接。5.4 大数据量传输时速度突然掉到0如果文件传输中途速度断崖式下降注意看是不是接收端缓冲区满了但读取不及时导致TCP窗口变为0对端被迫暂停发送。代码层面可以通过增大接收socket的缓冲区缓解server.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 1024 * 1024)但这只是“缓解”根本解法还是要让应用层及时消费数据并尽快落盘别在业务逻辑里做重计算把接收循环堵住。6. 走向生产环境并发、断点续传、校验与限速6.1 并发模型怎么选上面示例代码是串行处理连接。真要放到生产环境至少要做两件事一是把accept之后的处理放到独立线程或进程去执行二是限制并发数量防止连接数被打满。如果追求高并发Linux下推荐用selectors基于epoll实现单线程异步I/O可以支撑大量空闲连接。但文件传输的特点是单个连接长时间占满CPU和磁盘I/O多线程模型反而更直观。核心点是线程池上限from concurrent.futures import ThreadPoolExecutor with ThreadPoolExecutor(max_workers16) as pool: while True: conn, addr server.accept() pool.submit(handle_client, conn, addr)这个max_workers要根据服务器内存和磁盘吞吐量调整一般8到32之间比较常见。6.2 断点续传不是必须但关键时刻能救命内网传输大文件断网一次就从头开始重传体验很差。实现断点续传需要在协议里增加两个字段起始偏移量和已接收的校验信息。服务器接到请求后先检查本地是否已有部分文件如果有就把已接收长度告诉客户端客户端seek到对应位置继续发送。这种设计对网关FOTA升级、镜像同步这些场景实用性极高。6.3 校验和MD5不是最强的但够用文件传完不代表数据完全一致网络错误虽然被TCP的校验和规避了一部分但存储介质损坏、程序逻辑Bug照样可能导致数据错位。最稳妥的做法是传输结束后客户端和服务端分别计算MD5或SHA256值并对比。为了不重新读一遍整个文件拖慢速度也可以在发送过程中边分块边计算增量哈希。网络层可靠性解决的是“字节到了没有”应用层校验解决的是“字节对没有”这两层不能互相替代。6.4 限速别把生产网络打满文件传输不像网页请求一上来就容易跑满带宽。如果这台服务器还要承担其他业务建议做限速。简单实现可以用令牌桶思想import time class RateLimiter: def __init__(self, bytes_per_sec): self.rate bytes_per_sec self.tokens bytes_per_sec self.updated_at time.time() def consume(self, amount): now time.time() self.tokens (now - self.updated_at) * self.rate self.updated_at now if self.tokens self.rate: self.tokens self.rate if self.tokens amount: time.sleep((amount - self.tokens) / self.rate) self.tokens 0 else: self.tokens - amount每次发送分块前调用consume(len(chunk))就能把发送速度限制在预设值附近。限速值得结合实际网络带宽调整宁可慢一点也别把业务链路堵死。6.5 TCP和UDP、WebSocket的边界在哪里最后说一句关于选型的个人判断。TCP文件传输适合“设备之间直连、没有复杂路由穿透、文件较大且要求完整到达”的场景。UDP适合实时音视频和游戏状态同步能容忍丢包和乱序WebSocket适合浏览器与服务器之间需要双向实时通信的场景但它底层也是TCP只是加了一层HTTP升级握手和帧封装。搞清楚了TCP的定位就不会在选型时拿UDP做文件传输然后拼命做应用层重传也不会非要用WebSocket去连一个只开了TCP端口的嵌入式设备。我实际使用中的体会是裸TCP文件传输服务器虽然看起来“原始”但它的可预测性和低依赖在特定场景里非常有价值。只要你把协议头设计好、粘包处理好、并发和断点续传按需加上这套方案可以稳定跑很久。最后再分享一个小技巧生产服务器上记得加SO_KEEPALIVE并设置合理的TCP保活参数这样设备异常断电后服务器能在几分钟内感知到连接失效自动清理半开连接不会让线程池被一堆僵尸连接占满。本文还有配套的精品资源点击获取