从零构建TCP加密文件传输系统：粘包、断点续传与AES-GCM实战-平芜编程栈

1. 从零搭建一套TCP加密文件传输系统，我为什么放弃了现成方案

文件传输这件事，看起来简单，真要做到"自己可控、数据不裸奔"，坑比想象中多。我最初的需求很朴素：在两台机器之间传一些体积不小的文件，可能是几百MB的日志包，也可能是几十GB的数据集，要求传输过程稳定、断点能续、内容不能被中间人看到。市面上现成的工具不少，但要么依赖第三方服务、数据要过别人的服务器，要么配置复杂到让人怀疑人生，要么干脆就是个黑盒，出了问题完全不知道从哪查。

于是就有了这个Socket_Tcp加密文件传输系统。核心思路很直接：用 TCP 做底层传输保证可靠性，在应用层自己实现一套加密和校验机制，把文件切成块、加密、编号、发送、落盘、校验，全流程自己掌控。它解决的问题是：在不可信的网络环境里，让文件从 A 点安全、完整地到达 B 点，并且整个过程可观测、可调试、可扩展。

这套东西适合谁？如果你是会写一点网络编程、想搞清楚"文件传输到底是怎么一回事"的开发者，或者你手头有个内网/跨机房的数据搬运需求、又不想引入重型中间件，那这套思路可以直接抄。哪怕你只是想理解 TCP 粘包、加密分块、断点续传这些概念在真实项目里怎么落地，跟着走一遍也会很有收获。下面我按实际搭建的顺序，把每个关键决策背后的"为什么"讲透。

2. 传输层为什么锁定TCP，以及它带来的三个必须解决的问题

2.1 TCP的可靠性是白送的，但"消息边界"要自己画

选 TCP 而不是 UDP，理由很实在：文件传输最怕丢数据。UDP 快是快，但它不保证顺序、不保证到达，你得自己在应用层实现重传、排序、去重，等于把 TCP 干的活重写一遍，还未必写得比内核好。TCP 天然提供可靠、有序、面向连接的字节流，这是文件传输的刚需。

但 TCP 有个经典特性必须正视：它是字节流，没有消息边界。你 send 了三次，每次 1KB，接收端可能一次 recv 到 3KB，也可能分五次收到。这就是所谓的"粘包/拆包"。很多人第一次写 TCP 文件传输，直接send(file_bytes)然后对面recv循环写文件，小文件测试没问题，一大就出诡异 bug——文件内容错位、长度对不上。

解决办法是设计一个应用层协议头。我的做法是每个数据包前面固定加一段头部，结构大致如下：

字段	长度	说明
魔数	4 字节	固定值，用于快速识别包起始，过滤脏数据
版本号	1 字节	协议版本，方便后续升级兼容
包类型	1 字节	握手/元数据/数据块/结束/确认
保留位	2 字节	对齐用，未来扩展
载荷长度	4 字节	后面真正数据的字节数
载荷	变长	加密后的实际内容

接收端先读固定长度的头部（比如 16 字节），解析出载荷长度，再精确读取那么多字节，这样边界就清晰了。这里有个细节：recv不保证一次读满你要的字节数，所以必须写一个recv_exactly(n)的辅助函数，循环读取直到凑够 n 字节或者连接断开。这个函数是整个系统稳定的基石，我后面会专门讲它踩过的坑。

2.2 大文件不能一次性读进内存

第二个必须解决的问题是内存。一个 10GB 的文件，你不可能read()到内存里再加密发送，机器直接爆掉。所以文件必须分块（chunk）处理。块大小是个需要权衡的参数：

块太小（比如 1KB）：包数量爆炸，头部开销占比高，系统调用频繁，吞吐上不去。
块太大（比如 100MB）：单块加密耗时长，内存占用高，断点续传的粒度太粗，重传代价大。

我实测下来，64KB 到 1MB是比较舒服的区间。最终我选了 256KB 作为默认块大小，理由是：它既能保证不错的吞吐，又让单块加密的延迟控制在毫秒级，断点续传时最多重传 256KB，代价可接受。这个值可以通过配置调整，不同场景可以自己压测。

2.3 断点续传需要"块级"的进度记录

第三个问题是中断。网络抖动、进程被杀、机器重启，都可能让传输中断。如果每次都从头传，几十 GB 的文件能让人崩溃。断点续传的关键是记录已成功接收的块编号。

我的设计是：发送端给每个数据块编号（从 0 开始递增），接收端每成功写入一块并校验通过，就把这个编号记录到一个进度文件里（比如xxx.part.progress）。重连后，接收端把已完成的块编号列表发给发送端，发送端跳过这些块，从缺失的块继续发。这里要注意，进度记录必须先落盘再确认，否则进程崩溃时可能记录了但数据没写全，导致文件损坏。这个顺序问题我在第 5 节会详细展开。

3. 加密方案怎么选：对称加密打底，密钥交换单独设计

3.1 为什么用对称加密传数据，而不是非对称

一提到加密，很多人第一反应是 RSA。但 RSA 有个致命问题：慢，而且它只能加密比密钥短的数据。拿它直接加密几十 GB 的文件，性能上完全不可行。所以正确的分工是：

对称加密（如 AES）负责加密真正的文件数据，因为它快，能处理任意长度的数据。
非对称加密（如 RSA/ECC）只用来做一件事：安全地交换那个对称密钥。

这就是所谓的混合加密体系，也是 TLS 等主流协议的基本思路。我在系统里用的就是这套：会话开始时，双方通过非对称方式协商出一个临时的对称密钥（会话密钥），之后的文件数据全部用这个对称密钥加密。

3.2 AES的模式选择：为什么是GCM而不是CBC

对称加密算法我选 AES，这是业界标准，硬件加速支持好。但 AES 有不同的工作模式，选错了会埋雷。

早期很多人用CBC 模式，它需要把数据补齐到块大小的整数倍，而且它只保证机密性，不保证完整性——攻击者可以篡改密文，你解密出来是乱码但不知道被改了。要保证完整性还得额外加 HMAC，组合起来容易出错（比如经典的 padding oracle 攻击）。

我选的是GCM 模式。GCM 是认证加密（AEAD），一次操作同时提供机密性和完整性，解密时会自动校验认证标签，数据被篡改会直接解密失败。而且 GCM 不需要填充，支持流式处理，非常适合分块传输。每个块加密时我会带上一个唯一的nonce（随机数或计数器），绝对不能重复使用同一个 nonce 配同一个密钥，否则 GCM 的安全性直接崩塌。我的做法是：nonce 由"文件ID + 块编号"派生，保证全局唯一。

3.3 密钥交换的落地细节

会话密钥怎么安全地送到对方手里？如果直接明文发密钥，那加密就白做了。我用的是非对称加密来保护对称密钥的分发：

接收端生成一对非对称密钥（公钥+私钥），把公钥发给发送端。
发送端生成一个随机的对称会话密钥，用接收端的公钥加密后发过去。
接收端用自己的私钥解密，拿到会话密钥。

这样即使有人截获了公钥和加密后的会话密钥，没有私钥也解不出来。这里有个实践要点：每次会话都生成新的对称密钥，不要复用。会话结束密钥就丢弃，这叫"前向安全性"的思路——即使某次密钥泄露，也影响不到历史传输。

提示：非对称密钥的位数要够。RSA 建议至少 2048 位，ECC 建议 256 位以上。位数太低在现代算力面前不安全。

3.4 完整性校验：加密之外再加一道哈希

虽然 GCM 已经保证了单块的完整性，但我在整个文件层面还加了一道 SHA-256 校验。原因有两个：一是防止块顺序被恶意打乱（单块校验通过不代表整体正确），二是给用户一个明确的"文件是否完整"的结论。发送端在传输前算出整个文件的 SHA-256，通过元数据包发给接收端；接收端全部块收齐、拼装完成后，重新算一遍哈希，比对一致才算成功。这个设计在排查问题时特别有用——一旦哈希对不上，你就知道要么是传输丢了块，要么是落盘出了问题。

4. 协议交互全流程：从握手到文件落盘的每一步

4.1 握手阶段：先谈好规矩再传数据

连接建立后不能上来就发文件，得先握手确认双方"说的是同一种语言"。我的握手流程是这样的：

客户端连接成功后，发送一个HELLO包，携带协议版本号和支持的加密算法列表。
服务端回复HELLO_ACK，选定一个双方都支持的算法，并附上自己的公钥。
客户端生成会话密钥，用服务端公钥加密后通过KEY_EXCHANGE包发送。
服务端解密成功，回复KEY_OK，握手完成。

握手阶段最容易忽略的是版本协商。如果客户端和服务端协议版本不一致，直接传数据会解析错乱。所以我在 HELLO 包里带了版本号，服务端发现不兼容就明确拒绝，而不是硬着头皮传。这个设计在后续升级协议时救过我好几次。

4.2 元数据阶段：让接收端提前知道要收什么

握手完成后，发送端先发一个META包，里面包含：

文件名（注意要做路径安全处理，防止../之类的路径穿越）
文件总大小
总块数
块大小
整个文件的 SHA-256
文件唯一ID（用于断点续传时匹配）

接收端收到 META 后，检查本地是否已有同名文件的进度记录。如果有，就进入断点续传逻辑，把已完成的块编号列表通过RESUME包回给发送端；如果没有，就回复META_ACK表示从头开始。这一步是整个断点续传机制的入口，设计得好不好直接决定体验。

4.3 数据块传输：编号、加密、发送、确认

进入正式传输后，发送端循环处理每个块：

从文件指定偏移读取 256KB 数据。
用会话密钥 + 该块对应的 nonce 做 AES-GCM 加密，得到密文和认证标签。
组装数据包：头部（含块编号）+ 密文 + 认证标签。
通过 TCP 发送。
等待接收端的ACK（携带块编号）。

这里我采用的是滑动窗口 + 批量确认的思路，而不是"发一块等一个 ACK"。因为每块都等确认，网络往返延迟会严重拖慢吞吐。我的做法是允许在途未确认的块达到一定数量（比如 32 块），接收端可以累积确认多个块。这样既保证了可靠性，又不会因为等待而空转。窗口大小需要根据网络状况调，内网可以开大，跨公网要保守一些。

4.4 结束与校验：收尾不能马虎

所有块发完后，发送端发一个FINISH包。接收端收到后：

确认所有块都已收到且校验通过（检查块编号是否连续、无缺失）。
把临时分块文件按顺序拼装成最终文件。
计算最终文件的 SHA-256，和 META 里的比对。
比对一致，回复FINISH_ACK，删除进度文件和临时块；不一致，回复FINISH_NACK，触发重传或报错。

只有收到 FINISH_ACK，发送端才认为传输真正成功。这个"最后一道校验"绝对不能省，我见过太多"看起来传完了但文件是坏的"的案例，都是因为收尾阶段偷懒。

5. 那些让我熬夜的坑：粘包、半包与进度落盘顺序

5.1 recv读不满：半包问题的完整排查链路

系统第一版跑小文件一切正常，一传大文件就偶发失败，报错是"解析头部失败"或者"数据长度异常"。我一开始怀疑是加密问题，排查了半天加密逻辑，没问题。后来加日志才发现，问题出在recv上。

现象是这样的：接收端调用recv(buf, 16)想读 16 字节的头部，结果只读到了 8 字节就返回了。代码里没检查返回值，直接按 16 字节解析，后面全乱套。这就是半包——TCP 只保证字节流有序，不保证你一次能读到你想要的量。

排查思路我总结成三步：第一，在所有recv调用处打印实际返回的字节数；第二，对比期望值和实际值，找出哪些调用返回了小于期望的值；第三，确认这些地方有没有做循环读取。定位到之后，修复方案就是写一个recv_exactly函数：

def recv_exactly(sock, n): buf = b'' while len(buf) < n: chunk = sock.recv(n - len(buf)) if not chunk: raise ConnectionError("连接在读取完成前关闭") buf += chunk return buf

这个函数看起来简单，但它是整个系统稳定的关键。所有读取固定长度的地方（头部、认证标签）都必须用它。读取变长载荷时，先读头部拿到长度，再用recv_exactly读那么多字节。自从统一用这个函数，半包问题再没出现过。

5.2 粘包：一次recv读到多个包怎么办

和半包相反的问题是粘包——发送端连续发了两个包，接收端一次recv把两个包的数据都读回来了。如果你按"一次 recv 就是一个包"来解析，第二个包就被吞了。

解决粘包的根本办法还是长度前缀。因为我的协议头里有明确的"载荷长度"字段，接收端的逻辑是：先确保缓冲区里有完整的头部，解析出载荷长度，再确保缓冲区里有完整的载荷，凑齐一个完整包就处理，处理完从缓冲区移除，继续看下一个。这本质上是一个状态机 + 缓冲区的解析器。核心思想是：不要假设 recv 的边界和包的边界一致，永远以协议头里的长度为准。

我踩过的具体坑是：早期用recv的返回值直接当包长度，结果粘包时把两个包的数据拼一起解密，GCM 认证直接失败。后来改成维护一个接收缓冲区，按长度切包，问题解决。这个缓冲区解析器我建议单独写成一个类，逻辑清晰也好测试。

5.3 进度落盘顺序：先写数据还是先记进度

断点续传的进度记录有个隐蔽的顺序陷阱。假设接收端收到一个块，逻辑是"先更新进度文件，再写数据块"。如果更新完进度、还没写数据时进程崩了，重启后系统认为这块已完成，跳过不传，结果最终文件缺了这一块，哈希校验失败。

正确顺序必须是：先把数据块完整写入临时文件并 flush 到磁盘，确认写入成功后，再更新进度记录。这样即使崩溃，最坏情况是某块数据写了但进度没记，重启后重传这一块，覆盖写入，结果依然正确。宁可多传一块，也不能少传一块。

更进一步，进度文件本身也要原子更新：先写到一个临时文件，再rename覆盖原进度文件。rename在大多数文件系统上是原子操作，能避免进度文件写到一半崩溃导致内容损坏。这个技巧在处理任何"关键状态记录"时都适用。

5.4 内存与文件句柄：别让小疏忽拖垮系统

还有一个容易被忽视的点：文件句柄和内存的释放。传输过程中如果异常退出，临时文件句柄没关，长期运行会耗尽句柄。我的做法是用try/finally或者上下文管理器确保任何路径下资源都被释放。另外，接收缓冲区不能无限增长——如果对端发了超大的载荷长度（可能是恶意构造），你得有个上限检查，超过合理值直接断开，防止内存被撑爆。这个上限我设的是块大小的两倍，正常流量绝不会触发。

6. 性能调优与实测：从能用走向好用

6.1 块大小、窗口大小、缓冲区大小的联动调优

系统能跑通之后，我开始压测调优。影响吞吐的主要有三个参数：块大小、滑动窗口大小、socket 缓冲区大小。它们不是孤立的，得联动看。

参数	调小的影响	调大的影响	我的取值
块大小	包多、开销大、吞吐低	单块延迟高、重传代价大	256KB
滑动窗口	吞吐上不去、往返等待多	内存占用高、丢包重传多	32 块
socket 缓冲区	高延迟链路吞吐受限	内存占用增加	系统默认的 2-4 倍

调优方法很朴素：固定两个参数，压测第三个，画吞吐曲线，找拐点。我在内网千兆环境下实测，256KB 块 + 32 窗口能跑到接近网卡上限；跨公网高延迟链路，窗口开大反而因为丢包重传导致吞吐下降，最后降到 8 块更稳。没有一组万能参数，必须按实际链路压测。

6.2 加密开销到底有多大

很多人担心加密拖慢传输。我实测对比了加密和不加密的吞吐：在支持 AES 硬件加速的机器上，AES-GCM 的开销大概只占整体耗时的 5% 到 10%，瓶颈还是在网络 IO 上。所以不要为了性能牺牲加密，这个代价值得。如果确实遇到 CPU 瓶颈，可以考虑多线程并行加密不同的块，但要注意 nonce 的唯一性管理，别搞出重复 nonce。

6.3 并发传输与多文件场景

单文件传顺了之后，自然会想传多个文件。我的做法是每个文件一个独立会话，而不是在一个连接里混传多个文件。这样进度记录、断点续传、错误处理都互相隔离，一个文件出问题不影响其他。如果连接建立开销大，可以复用 TCP 连接，但协议层要能区分不同文件的包（靠文件ID字段）。并发数不要开太高，磁盘 IO 和网络带宽是共享的，开太多反而互相拖累，我一般控制在 4 到 8 个并发。

6.4 日志与可观测性：出问题时能查

最后强调一个容易被忽略但极其重要的点：日志。传输系统出问题时，如果没有足够的日志，你根本不知道卡在哪一步。我在关键节点都打了日志：握手完成、元数据交换、每 N 个块打印一次进度、断点续传触发、校验结果。日志里带上文件ID、块编号、时间戳，方便串联。但注意别每块都打，否则日志本身就成了性能瓶颈。我的做法是每 100 块或每 5 秒打一次进度，异常时打详细日志。

注意：日志里绝对不能打印密钥、明文数据等敏感信息。调试时可以打印块编号和长度，但内容本身要脱敏。

7. 我在实际搭建中总结的几条硬经验

这套系统我从第一版能跑到后来稳定用于日常数据搬运，中间返工了好几次。回头看，最值钱的不是代码本身，而是这些踩出来的经验。

第一条，协议设计要留余地。头部里的版本号、保留位，当时觉得多余，后来加新包类型、改字段含义时，全靠它们做兼容。协议一旦上线，改起来成本极高，前期多留几个字节的扩展空间，绝对不亏。

第二条，所有涉及"状态记录"的地方，都要考虑崩溃一致性。进度文件、临时文件、最终文件的写入顺序，决定了系统在异常情况下是"可恢复"还是"彻底损坏"。先写数据后记进度、原子 rename 更新状态，这两个习惯让我避免了好几次数据损坏。

第三条，别信任何"一次就能读完/写完"的假设。TCP 的 recv 可能读不满，send 也可能只发出去一部分（虽然阻塞模式下少见，但非阻塞模式很常见）。所有 IO 操作都要循环处理，检查返回值。这个习惯不只适用于网络编程，读写文件、管道通信都一样。

第四条，加密不是加个库调用就完事。nonce 不能重复、模式要选认证加密、密钥要每次会话更新、完整性校验要覆盖整体。这些细节任何一个出错，加密就形同虚设。如果对密码学不熟，宁可多查资料、多测试，也别想当然。

第五条，性能调优靠数据不靠感觉。块大小、窗口大小这些参数，网上给的"最佳值"只能当起点，真实链路千差万别。老老实实压测、看曲线、找拐点，比抄别人的配置靠谱得多。

这套 Socket_Tcp 加密文件传输系统，说到底就是把"可靠传输、安全加密、断点续传、完整性校验"这几件事，用最朴素的 TCP 和密码学原语，一块一块拼起来。它不花哨，但每一行逻辑你都能讲清楚为什么这么写，出了问题也知道从哪查。这种"自己完全掌控"的感觉，是任何现成工具都给不了的。如果你也在做类似的东西，希望这些经验能帮你少熬几个夜。