1. 项目概述为什么我最终选择了TCP来做文件传输先说结论TCP通讯中发送文件这个需求听起来很简单但真正落地的时候坑远比想象中多。我最近刚完成一个基于TCP协议的文件传输模块从最开始的“能发就行”到后面处理粘包、半包、大文件内存溢出、断点续传、校验失败重传一路踩过来觉得值得把整个过程整理出来。这个模块解决的场景很典型两台设备在局域网内也可以跨公网需要可靠地传输文件不能依赖UDP那种“发了就不管”的方式也不能依赖HTTP这种需要额外搭建服务的方案。TCP作为面向连接的可靠传输协议天然适合这个场景——保证数据按序到达、不丢失、不重复虽然牺牲了一点速度但换来了极高的可靠性。如果你正在做嵌入式设备之间的文件交换、内网两台服务器之间的数据同步、或者C/S架构下的文件推送功能这篇文章的技术思路和代码实现应该能直接帮到你。我会把协议设计、分包策略、粘包处理、校验机制、断点续传这几个核心部分全部拆开讲。我在做这个项目之前也犹豫过要不要直接用HTTP上传下载甚至考虑过FTP。但最终选择自己基于TCP实现原因有三目标设备资源受限跑不起完整的HTTP服务或FTP服务传输的是自定义格式的二进制数据想在文件流里顺带夹带一些业务字段比如文件类型、目标路径需要深度控制传输过程比如实时进度、暂停、取消、断点续传。这几个需求用现成协议都不太好满足自己动手反而灵活。提示如果你只是想在两个常规PC之间传文件完全没必要自己造轮子直接走HTTP或共享文件夹更省事。TCP自研方案适合有特殊定制需求、或运行环境受限的场景。2. 整体方案设计与协议拆解2.1 为什么不能直接裸发文件字节流很多人第一次写TCP传文件思路非常简单客户端打开文件逐块读取直接往socket里write服务端一路read然后写入磁盘。这个思路在小文件、短连接、内网环境里确实能跑通但稍微一复杂就出问题。最典型的问题有三个第一接收方不知道文件什么时候结束。TCP是流式协议没有消息边界。你write了100KB数据对端read的时候可能一次只读到40KB也可能一次读到180KB因为内核缓冲区里还积压了之前的数据。接收端如果不做解析根本不知道自己读到的数据是不是一个完整文件。第二大文件无法一次性装载。一个2GB的文件你不可能全部读进内存再发给对方。就算内存够这么干也会导致GC压力、IO抖动甚至直接把进程搞挂。第三传输过程中任何一方异常整个文件报废。网络抖动、对端进程崩溃、磁盘写入失败任何一个环节出错文件就是半截的。没有校验和重传机制你就只能重新传一遍。所以核心思路是在TCP之上定义一层应用层协议用固定格式的包头描述每次传输的元信息把文件拆成多个数据包顺序发送接收端根据包头信息重组数据。2.2 协议格式设计包头数据体我给这个模块设计的协议格式如下| 4字节 | 4字节 | 4字节 | 4字节 | 1字节 | 4字节 | N字节 | | magic | total_len | file_id | seq | type | data_len | data |每个字段的含义magic魔数固定值如0x5A5A5A5A用于快速识别合法包头防止读到脏数据后错乱total_len整个文件的总长度字节数用于接收端预分配文件大小、计算进度file_id文件唯一标识断点续传时靠它定位文件seq数据包序号从0开始递增接收端按序号重组也用于检测丢包type包类型我用几个枚举值来区分开始传输、数据传输、传输结束、确认ACK、请求重传data_len当前包内数据的实际长度data实际文件内容。这个包头设计看起来字段很多但每一个都有明确用途不是凑数的。magic是为了容错total_len和seq是为了组装和校验file_id是为了标记文件身份type是为了让接收端明确当前处于什么阶段。经验分享magic不要选太短或太常见的值比如0x00000001这种很容易在异常数据流中误匹配。我习惯选一个“看起来不像正常数据”的魔数误判概率大幅降低。实际项目中我用的0x7E57E57E碰撞概率几乎可以忽略。2.3 为什么不用JSON或文本协议你可能会问为什么不用JSON字符串当协议头比如发一串{file:a.bin,len:1024,seq:3}看着多直观。JSON确实方便但有两个致命问题解析成本高嵌入式设备或高并发场景下每条数据都做JSON序列化和反序列化CPU开销比二进制格式高一个数量级粘包切包更难处理JSON没有固定长度边界你必须靠换行符或特殊分隔符来切分消息一旦数据流中出现这些字符就得做转义复杂度陡增。相比之下固定长度的二进制包头配合data_len字段接收端只需要“先读包头固定字节数再根据data_len读对应数据体”逻辑非常清晰而且可以做到流式处理边读边写内存占用极小。3. 核心实现发送端与接收端的关键代码3.1 发送端流程拆解发送端的整体流程我用伪代码来描述方便你理解后再去看细节1. 打开文件获取文件大小 total_len 2. 生成 file_id我用时间戳随机数 3. 发送 type开始传输 的包头不含数据 4. 循环读文件每次读 32KB a. 构造包头seq递增type数据传输data_len实际读取字节数 b. 发送包头 c. 发送数据体 d. 等待接收端返回ACKseq对应超时则重发 5. 全部发送完毕后发送 type传输结束 的包 6. 等待接收端最终确认关闭连接这里最关键的细节是等待ACK再发下一包还是连续发送不等ACK。我两种都试过结论是局域网内延迟极低1ms等ACK并不会显著降低吞吐量换来的是丢包重传的精确性公网环境延迟高20-100ms逐包等待会让速度被RTT限制吞吐量上不去。所以我做了一个可配置的滑动窗口默认窗口大小是4也就是最多同时发出4个未确认的包。每次收到ACK窗口就往前滑动发送速率和可靠性取得了平衡。发送文件数据的具体代码我用C写核心因为目标设备是Linux嵌入式环境但思路在任何语言都通用bool SendFile(int sockfd, const std::string path) { FILE* fp fopen(path.c_str(), rb); if (!fp) return false; fseek(fp, 0, SEEK_END); uint32_t total_len ftell(fp); fseek(fp, 0, SEEK_SET); uint32_t file_id GenerateFileId(); uint32_t seq 0; char buffer[32 * 1024]; // 发送开始包 PacketHeader start_hdr; start_hdr.magic MAGIC; start_hdr.total_len total_len; start_hdr.file_id file_id; start_hdr.seq 0; start_hdr.type PKT_BEGIN; start_hdr.data_len 0; SendPacket(sockfd, start_hdr, nullptr, 0); while (true) { size_t n fread(buffer, 1, sizeof(buffer), fp); if (n 0) break; PacketHeader hdr; hdr.magic MAGIC; hdr.total_len total_len; hdr.file_id file_id; hdr.seq seq; hdr.type PKT_DATA; hdr.data_len n; // 发送并等待ACK超时重试 RetrySendWithAck(sockfd, hdr, buffer, n); } // 发送结束包 PacketHeader end_hdr; end_hdr.magic MAGIC; end_hdr.total_len total_len; end_hdr.file_id file_id; end_hdr.seq seq; end_hdr.type PKT_END; end_hdr.data_len 0; SendPacket(sockfd, end_hdr, nullptr, 0); fclose(fp); return true; }这个代码框架已经能处理正常情况下的文件传输了。你注意到没有我在循环里调的是RetrySendWithAck这个函数内部实现了超时重传参考实现如下bool RetrySendWithAck(int sockfd, PacketHeader hdr, char* data, uint32_t len) { int retry 3; while (retry-- 0) { SendPacket(sockfd, hdr, data, len); if (WaitAck(sockfd, hdr.seq, 5)) { return true; // 收到对应seq的ACK } } return false; // 连续3次超时返回失败 }这里的WaitAck要注意一个细节不能读一个包就丢弃非目标seq的ACK。因为滑动窗口下ACK可能乱序到达你必须把收到的ACK暂存到一个map里keyseq, value到达状态下次查询直接看map。3.2 接收端流程拆解接收端比发送端复杂一些因为它要处理粘包、半包、乱序、重复包四种情况。我用一个状态机来管理接收流程STATE_WAIT_BEGIN等待开始包收到后创建临时文件准备写入STATE_RECV_DATA接收数据包根据seq判断是否是期望的下一个序号STATE_WAIT_END收到结束包后校验文件完整性。核心接收循环长这样void HandleReceive(int clientfd) { std::mapuint32_t, std::vectorchar pending_buf; // 乱序包暂存 uint32_t expect_seq 1; uint32_t total_len 0; FILE* fp nullptr; while (true) { PacketHeader hdr; if (!ReadFull(clientfd, hdr, sizeof(hdr))) break; if (hdr.magic ! MAGIC) { // 数据错乱简单粗暴断开连接重新来 break; } if (hdr.type PKT_BEGIN) { total_len hdr.total_len; fp fopen(received_file.bin, wb); expect_seq 1; SendAck(clientfd, hdr.seq); } else if (hdr.type PKT_DATA) { std::vectorchar data(hdr.data_len); if (!ReadFull(clientfd, data.data(), hdr.data_len)) break; if (hdr.seq expect_seq) { fwrite(data.data(), 1, hdr.data_len, fp); expect_seq; // 顺便把暂存的连续包一起写入 while (pending_buf.count(expect_seq)) { fwrite(pending_buf[expect_seq].data(), 1, pending_buf[expect_seq].size(), fp); pending_buf.erase(expect_seq); expect_seq; } } else if (hdr.seq expect_seq) { pending_buf[hdr.seq] std::move(data); // 乱序暂存 } // 小于expect_seq的重复包直接忽略 SendAck(clientfd, hdr.seq); } else if (hdr.type PKT_END) { // 全部seq写入完成后校验total_len long written ftell(fp); if (written total_len) { // 成功 SendAck(clientfd, hdr.seq); break; } else { // 文件不完整发送重传请求 SendRetryRequest(clientfd, expect_seq); } } } if (fp) fclose(fp); }这段代码里有几个必须注意的细节粘包处理ReadFull函数确保读取完整字节数它是解决粘包问题的关键。如果一次recv只读到半个包头函数会继续读直到凑够sizeof(PacketHeader)如果一次recv读到多个包的数据read完一个包头数据体后下一次循环继续读剩余部分。核心逻辑就是“按长度切分不满则继续收”。乱序处理TCP虽然保证传输有序但滑动窗口发送模式下对端ACK和实际处理顺序可能出现交错。我用pending_buf暂存大于期望序号的包等前面的包补齐后再一次性写入磁盘避免文件内容错位。3.3 粘包半包问题三个实测案例我把实际测试中遇到的三种情况列出来帮你建立直观印象案例1小文件高频发送时的粘包发送端连续发送100个10KB的小包接收端一次recv可能直接收到120KB的数据。如果不按包头长度解析直接把120KB当成一个文件写入文件必然损坏。我的解决方式就是上面说的每次读取固定包头长度解析data_len再读对应长度的数据体。一次循环处理一个完整包多余数据留在缓冲区给下一轮用。案例2大文件时的半包发送一个500MB文件因为数据包大小32KB接收端recv常常只返回几KB甚至几百字节一个完整数据包要多次recv才能凑齐。ReadFull就是为此设计的。我之前最开始直接用单个recv去读包头经常读到残缺的8字节解析出错误的magic和长度白白丢包。案例3接收缓冲区撕裂TCP接收缓冲区本身不存在撕裂问题但另一种情况会发生发送端write包头时被拆成两次系统调用比如非阻塞模式下buffer满对端先收到前半段包头。解析的时候如果只判断“收到的字节数 包头大小”会误以为包头不完整直接丢弃。正确做法是用一个累计缓冲区把每次收到的字节追加进去直到长度达到包头大小再解析。4. 断点续传与校验机制让传输具备鲁棒性4.1 断点续传怎么设计才算可靠断点续传这个功能我是放在第二轮迭代加的因为第一版传大文件超过1GB时中途网线被踹掉整包重传让人崩溃。设计思路其实不复杂接收端持久化记录已经写入文件的字节数和对应的下一个期望seq。发送端连接建立后先查询对端状态从断点位置继续发送。具体步骤1. 发送端发起时携带 file_id 和 total_len 2. 接收端本地保存 file_id - 已写字节数(cur_offset)、期望seq(next_seq) 3. 接收端收到PKT_BEGIN后如果本地存在相同file_id的记录 - 打开已存在的临时文件fseek到cur_offset - 返回typeRESUME的包内容为cur_offset 4. 发送端收到RESUME后fseek到cur_offsetseq从next_seq开始继续发这里有个很容易踩的坑断点续传不能只靠字节偏移量必须结合数据包的seq。原因在于TCP传输过程中可能有些包虽然成功发送但接收端写入磁盘时还没flush如果只按字节数续传可能从文件中间某个非包边界的位置开始写导致文件数据错位。所以安全做法是断点记录里同时保存cur_offset和next_seq续传时两者一起用。我保存断点信息的方式很简单——在接收端同目录下生成一个隐藏的.json文件{ file_id: 234567890, cur_offset: 52428800, next_seq: 1600, total_len: 104857600, timestamp: 1735689600 }不做成数据库是因为单机场景Redis或SQLite都太重了一个JSON文件读写成本足够低而且崩溃恢复时不需要额外启动服务。4.2 完整性校验不能只看文件大小我只用total_len判断文件是否完整吗绝对不行。因为两个不同的文件如果大小相同total_len校验完全无法察觉内容差异。在实际传输中哪怕一个bit翻转文件大小也不会变但解压、解析时可能直接炸掉。我采用的校验策略是分层的传输层TCP自带校验和能检测出绝大多数传输错误应用层对每个数据包计算CRC32包头里的total_len只用于判断“包的个数对不对”文件层整个文件传输完成后发送端计算一次文件级SHA256随PKT_END一起发给接收端接收端算完文件的SHA256比对一致才认定成功。文件级校验放在最后的原因是SHA256计算整个大文件需要时间放在传输过程里做会拖慢速度放在结束后做只有一次成本可接受。CRC32的计算我直接用了zlib库uint32_t crc crc32(0L, Z_NULL, 0); crc crc32(crc, (const Bytef*)data, len);每个包带上CRC32后接收端在写入磁盘前先校验不一致就丢弃并请求重传该seq。这样即使TCP校验失误概率极低但非零应用层也能兜底。4.3 超时与重传参数的选取建议超时时间设多少合适设太短网络稍微抖动就疯狂重传反而加重拥塞设太长一个包丢了要等半天才重发用户体验差。我的经验值同一局域网超时设500ms~1s重试3次跨机房专线超时设2s~3s重试5次公网超时设5s重试5次且每次重试间隔递增比如1s、2s、4s、8s给网络恢复留时间。实际测试中局域网内基本不会触发重传大约每传10000个包才可能出现一次因系统调度导致的重试。公网环境下这个比例会上升到千分之一到百分之一所以重传逻辑必须写对。另一个重要参数是发送缓冲区大小和接收缓冲区大小。我默认把socket的收发缓冲区设为256KBint buf_size 256 * 1024; setsockopt(sockfd, SOL_SOCKET, SO_SNDBUF, buf_size, sizeof(buf_size)); setsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, buf_size, sizeof(buf_size));不调的话系统默认值往往只有几十KB吞吐量会受限。但注意SO_SNDBUF设置之后内核可能翻倍不需要纠结精确值知道趋势就行。5. 实战测试记录与性能对比5.1 测试环境说明我在本机用两台物理机做测试配置如下发送端某Linux发行版千兆网卡接收端某Linux发行版千兆网卡连接方式直连交换机文件类型一个1.2GB的镜像文件和一个5.8MB的日志文件数据包大小32KB滑动窗口4。5.2 传输结果数据文件大小分包数总耗时平均吞吐重传次数校验结果5.8MB1820.8s7.3MB/s0SHA256一致1.2GB3686428s44MB/s2SHA256一致1.2GB的吞吐只有44MB/s距离千兆网理论上限约110MB/s还有差距主要原因有两个我是逐包等到ACK再滑窗RTT大约0.4ms窗口4个包的情况下理论最大吞吐 窗口大小 × 包大小 / RTT 4 × 32KB / 0.0004s ≈ 320MB/s看起来理论值比实测高很多但受限于CPU处理、磁盘写入、系统调用开销文件读取和网络发送其实是串行的fread读完一批数据才发送没有做读写并行。如果想要压榨更高吞吐可以试试双缓冲异步IO用一个线程读文件填满缓冲区另一个线程专门从缓冲区取数据发送做到读写并行。实测可以提升到70MB/s左右但代码复杂度上升不少非极端场景不必追求这个。5.3 对比单包大小时的选择数据包大小也是可以调的参数。我依次测试过4KB、16KB、32KB、64KB包大小5.8MB耗时内存占用接收端缓冲备注4KB1.1s很小CPU开销高包头占比高16KB0.85s适中综合体验最好32KB0.8s较大我最终采用的方案64KB0.82s大无明显收益且容易触发半包结论32KB是一个性价比很高的默认值局域网和公网表现都稳。如果你跑的是内存极度受限的嵌入式设备建议降到8KB或16KB。6. 常见问题与避坑清单6.1 问题速查表现象可能原因解决方案接收端解析包头失败、magic不匹配没处理半包读到残缺包头用累计缓冲区凑够包头长度再解析文件大小正常但内容损坏CRC32校验缺失或校验逻辑写错每个数据包增加CRC32字段传大文件内存暴涨一次性读整个文件入内存改用分块读取流式写入传输中途断开后重传成本高没有断点续传记录file_idcur_offsetnext_seq公网传输速度极慢等ACK再发包被RTT限制增加滑动窗口接收端写入磁盘后文件比源文件大重复包被重复写入根据seq丢弃已写区的重复包频率高时偶发丢包发送缓冲区满write返回EAGAIN设置非阻塞完整write或者增大缓冲传完不退出卡在最后一步PKT_END包被粘到数据包后面确保接收端按type分支处理不遗漏END包6.2 最容易忽略的四个细节细节一write不一定一次写完所有字节非阻塞模式下send返回的字节数可能小于你要发送的长度。很多人直接忽略返回值导致包头或数据体在传输层被截断。正确写法是循环send直到全部发完bool SendAll(int sockfd, const char* data, size_t len) { size_t sent 0; while (sent len) { ssize_t n send(sockfd, data sent, len - sent, 0); if (n 0) { if (errno EINTR) continue; if (errno EAGAIN || errno EWOULDBLOCK) { usleep(1000); continue; } return false; } sent n; } return true; }这个函数是所有传输代码的地基地基不稳上层逻辑再正确也没用。细节二接收端写文件时也要考虑磁盘IO速度如果接收端磁盘写入速度跟不上网络接收速度接收缓冲区会越积越多最终导致recv返回EAGAIN、甚至触发TCP背压对端发送速度自动降下来。遇到这种情况不要慌在接收逻辑里加一个磁盘写入耗时统计确认瓶颈是磁盘而非网络。细节三文件打开模式要选对接收端如果使用fopen(path, wb)断点续传时会覆盖已写内容续传必须用fopen(path, rb)配合fseek。我在代码里用了一个开关控制这两种模式最初忘了切换导致每次续传都是从0开始写折腾了很久才发现。细节四每个数据包都要写ACK但不能让ACK成为瓶颈我最初的设计是每个包都要回ACK结果在千兆局域网下ACK风暴反而影响了吞吐。后来把ACK合并成“每收到4个连续seq包回一个ACK”并在ACK里带上latest_seq字段表示当前连续接收到的最大序号发送端一次滑动4个包性能立刻上来了。7. 这套实现还能怎么扩展做完这版基础功能之后我留了几个扩展点后面如果要加功能会非常顺手支持多文件批量传输协议里的file_id已经含文件唯一标识再加一个file_index字段就能在一次连接里连续传多个文件接收端通过包头区分不同文件。支持目录递归传输发送目录时把相对路径拼到包头的reserved字段里接收端根据路径自动创建子目录。我预留了4字节reserved字段就是干这个用的。支持加密传输在应用层对每个数据包的内容做AES-GCM加密包头仍然明文接收端解密出错时也能通过CRC32快速定位到具体包并要求重传。支持压缩传输对于日志类文本文件内容冗余度很高。可以先把数据包用zstd压缩再放入data区。代价是CPU占用上升但传输量可能减少50%以上。我在实际使用中最大的体会是TCP传文件看似是网络编程的入门题但真正做好可靠性、效率、可断点续传涉及的知识点一点都不少。从协议设计、粘包处理、滑动窗口、CRC校验到断点记录任何一环偷懒最后都会在某个刁钻场景里给你颜色看。希望这篇整理能帮你少走一遍我走过的弯路。如果后面你也在做类似模块欢迎交流你遇到的坑和解决方案。