手写并发文件传输服务：一次搞懂Linux文件IO、线程池与Socket

1. 项目底座：为什么用"并发文件传输服务"把这五块内容全串起来

C语言学到一定程度，很多人都会卡在同一个地方：单独看每个知识点都觉得懂，文件IO会读写、进程线程能写出几个demo、Socket也能照书敲出一个回声服务器，可真要把这些模块组合成一个能跑、能扛、能编译多文件的项目，立刻就不知道从哪下手了。我这次就是为了治这个毛病，把Linux系统编程里的文件IO、进程线程、Socket和Makefile全部串起来做了一遍，最后落地成一个并发文件传输服务。

1.1 每个模块在项目里的真实角色

这个项目不算花哨，但好在它每一个模块都是"被需要的"，不是硬凑上去表演的：

文件传输这个场景特别有意思的地方在于：网络IO和文件IO永远是一对出现的。客户端收文件，是从socket读、往磁盘写；服务端发文件，是从磁盘读、往socket写。两个方向都有IO边界和缓冲区问题，任何一个环节写得不严谨，传大文件时就会出现"传完了但md5对不上"这种让人头皮发麻的诡异问题。

1.2 自定义应用层协议：不依赖框架才能理解框架

既然是练手项目，我一开始就决定不用任何网络库，完全基于POSIX socket API自己定义一套简单的应用层协议。一方面是想把底层的封包、解包逻辑亲手走一遍，另一方面是日后接触正式的网络框架时，不至于连"帧""消息边界"这些概念是从哪来的都不知道。

协议设计很简单，一个固定格式的头加上变长数据体：

#define PROTO_MAGIC 0x5A5A #define CMD_UPLOAD 0x01 // 客户端 -> 服务端：上传文件 #define CMD_DOWNLOAD 0x02 // 客户端 -> 服务端：下载文件 #define CMD_RESP_OK 0x10 // 服务端 -> 客户端：成功响应 #define CMD_RESP_ERR 0x11 // 服务端 -> 客户端：失败响应 #define FILE_NAME_MAX 64 struct proto_header { uint16_t magic; // 魔数，用于快速校验 uint16_t cmd; // 命令字 uint32_t body_len; // 整个包体的长度（字节数） };

魔数的意义是让接收端可以快速丢弃无效数据流，避免把垃圾数据解析成命令。body_len字段是整个协议的核心，收包流程全靠它来确认"一个完整消息到底有多长"。

这套设计最大的收益是：当你踩到粘包、半包这些坑的时候，你清楚地知道坑在哪儿，因为你亲手设计了解决它们的机制，而不是稀里糊涂地调一个现成框架的接口。

2. 文件IO层：读写文件没你想的那么简单

文件IO这块，教科书上讲的和实际工程里用到的，差距相当大。如果你只是跟着教材抄过open、read、write的示例，那你大概率会在这层踩坑。

2.1 open的flags与权限位：服务端写文件写出一堆没权限的货

服务端在接收上传文件时，需要调用open创建新文件。我的第一个版本长这样：

int fd = open(save_path, O_WRONLY | O_CREAT | O_TRUNC, 0644);

看起来没毛病，但我实测时才注意到服务器进程工作目录下新建的文件，权限变成了0640而不是0644。排查一圈才发现是进程的umask是0027，0644 & ~0027 == 0640，group那一组完全没有读权限。结果就是我本机测试没问题，换到另一个环境跑，客户端下载下来的文件别人都没法读。

处理方案有两种：在服务端启动时调用umask(0)，或者创建文件后主动chmod。我最后选择的是启动时设umask(0)，然后open时明确写清楚mode，这样权限完全由代码控制，不依赖环境。

另外还有一点：O_TRUNC配合O_WRONLY使用，意味着如果同名文件已经存在，会被直接清空重写。对下载场景无所谓，但对上传场景这是有风险的，最好先用access()判断文件是否已存在，再决定是覆盖还是报错。

2.2 read/write的返回值需要逐字节处理

基础良好的同学都知道read返回值有三态：大于0表示读取了N字节；等于0表示到达文件末尾；小于0是出错。但真到写代码时，很多人会犯一个很隐蔽的错误：write一次性写入失败，就认为整个包发送失败了。实际上对阻塞IO，write可能只写入了一部分数据就返回了，这种情况必须循环把剩余字节写完。

我写了一个通用的write_all来保证文件IO的完整写入，和Socket层的完整收发逻辑是互相对应的：

ssize_t write_all(int fd, const void *buf, size_t len) { const char *p = (const char *)buf; size_t left = len; while (left > 0) { ssize_t n = write(fd, p, left); if (n < 0) { if (errno == EINTR) // 被信号打断，重试即可 continue; return -1; } if (n == 0) break; p += n; left -= n; } return len - left; }

EINTR这个小细节，我在初次版本里完全忽略了。当时测试时偶尔会出现"一次大文件传输莫名其妙少了几个字节"的问题，后来用strace追踪才发现write调用返回了-1 EINTR，而代码把它当成写入失败把连接关掉了。处理规则很简单：遇到EINTR继续重试，其他错误才是真的异常。

2.3 缓冲区大小：64KB比4KB快了不止一点

文件拷贝类任务的性能大头是系统调用次数，每一次read和write都会陷入内核。缓冲区只有4KB时，传一个100MB的文件需要2.5万次read和2.5万次write；换成64KB缓冲区，系统调用次数直接降到原来的1/16。

我专门拉了一组粗测数据做对比，在同一台机器上通过回环地址传输100MB文件：

所以项目里统一用64KB缓冲区，这是一个甜点值。磁盘写完后数据还在内核页缓存里，如果亟需落盘，在文件传输完毕时要调fsync，否则机器突然断电时可能丢数据。这个对普通测试项目不是必须的，但作为习惯一定要有。

2.4 文件完整性校验：别等传完了才发现内容不对

我在项目中做的校验分两层：第一层是服务端和客户端都统计实际传输的字节数，和协议头里声明的文件大小比对；第二层是用md5sum对比原文件和传输后文件的哈希值。第一次测试时我就遇到"字节数一致，md5不一致"的情况，查了半天才发现是缓冲区的最后一次read只读到部分数据，但代码错误地假设read一次一定读满buffer，导致尾部塞进了上一次残留的脏数据。

这种Bug用眼睛很难看出来，但用校验工具一测就露馅。所以我的建议是：任何文件传输类项目，完整性校验一定要从一开始就加上，不要等怀疑出问题才加，到了排查阶段就晚了。

3. 并发模型：从单线程排队到线程池的演进

文件传输服务最核心的挑战是并发。我先写了一个最朴素的单线程版本，再一步步演进到线程池，每一步都有明确的动机和实测感受。

3.1 单线程基线版本：第二个客户端永远在等

第一个可运行版本是单线程循环：

while (1) { int conn_fd = accept(listen_fd, ...); handle_client(conn_fd); // 完整处理完一个客户端的下载请求 close(conn_fd); }

逻辑完全正确，但用户体验一塌糊涂。本地测试，客户端A下载一个大文件时，客户端B连接上来后服务端根本没有反应，因为accept调用根本还没执行到。文件下载这类任务耗时主要在网络传输，最直觉的改进思路就是"每个连接单独派一个执行体去处理"。

3.2 多进程方案实测：简单但有边界

当时我第一反应是用多进程，网上很多经典服务器示例也是这么写的：

pid_t pid = fork(); if (pid == 0) { close(listen_fd); handle_client(conn_fd); close(conn_fd); exit(0); } close(conn_fd); // 父进程关掉这个连接fd

这套方案跑起来后，确实解决了并发问题，简单粗暴。进程之间完全隔离，子进程处理过程中崩溃不会拖垮整个服务端。但它也有几个让我比较头疼的边界：

• 每个连接都要fork一次，1000个连接就是1000次进程创建，开销比线程大不少。
• 想统计"当前在线客户端数""总共服务过多少请求"，父子进程之间共享状态很麻烦，要靠IPC或共享内存。
• 如果多个子进程同时阻塞在accept上，会出现惊群现象，虽然有内核解决方案，但我这个项目不想引入太复杂的东西。

3.3 线程池方案：最终选型和线程安全细节

多进程方案基础上稍作调整就是多线程，但线程版本真正考验人的是线程安全。我的最终方案是主线程accept，然后把连接fd塞进一个任务队列，一组工作线程从队列里取任务处理，也就是典型的线程池模型。

这里有一个之前没想明白、后来才摸透的关键点：任务队列的锁粒度。用互斥锁保护队列本身是必须的，但工作线程处理单个客户端连接的全过程绝不能加全局锁，否则多个客户端又被串行化了。正确的做法是：只有队列入队、出队这两个短操作需要加锁，后续的网络传输全部在锁外进行。

struct task { int conn_fd; struct sockaddr_in peer_addr; }; pthread_mutex_t queue_lock = PTHREAD_MUTEX_INITIALIZER; pthread_cond_t queue_cond = PTHREAD_COND_INITIALIZER; task_queue_t work_queue; void *worker_main(void *arg) { while (1) { pthread_mutex_lock(&queue_lock); while (task_queue_empty(&work_queue)) pthread_cond_wait(&queue_cond, &queue_lock); struct task t = task_queue_pop(&work_queue); pthread_mutex_unlock(&queue_lock); handle_client(t.conn_fd); // 锁外处理连接 close(t.conn_fd); } }

条件变量这套机制，课本上讲的是"等待-通知"，但实际写起来最容易犯的错是漏掉锁内循环判断。比如队列为空时，多个线程同时被唤醒，其中一个取走了任务，其他线程再次判断队列为空就要继续睡眠。如果用if而不是while，线程就会带着空任务向下执行，最终读到未定义数据。这个坑我是在并发压测时用AddressSanitizer抓出来的，报错信息非常经典。

另外统计信息我用了一个全局原子变量：

static _Atomic long g_total_requests = 0; // 在handle_client入口处 atomic_fetch_add(&g_total_requests, 1);

这比每次统计都拿互斥锁要轻量得多，也足够满足需求。

3.4 线程资源和SIGPIPE：两个容易被忽略的坑

线程默认栈大小是8MB，我的服务器只维护8个工作线程，看起来无所谓，但如果连接数增多，每连接一线程的模型下，过千连接就是8GB虚拟内存，压力非常大。线程池模式里线程数固定，这个压力还在可控范围，但我还是用pthread_attr_setstacksize把工作线程栈调到了1MB，足够处理文件IO逻辑，也显著降低了内存占用。

SIGPIPE这个问题是这个项目让我印象最深的坑之一：当客户端断开连接后，服务端继续往这个socket写数据，内核会发出SIGPIPE信号，而该信号的默认行为是终止进程。也就是说，你的服务器会在某个客户端异常退出时整进程挂掉，不是崩溃，而是直接被信号杀了。

解决办法很简单，在main函数启动时加一句：

signal(SIGPIPE, SIG_IGN);

忽略之后，对已断开连接的写操作会返回EPIPE错误，交给业务代码处理即可。这一步不做，高并发测试时服务器撑不过五分钟。

4. Socket通信层：从demo级到能扛住真实网络场景

很多Socket教程写的是"连接、收发、关闭"三步走，看起来很简单，但真实的网络环境远比demo复杂：半包、粘包、客户端半路断开、网络闪断，都得靠代码一层层兜住。

4.1 基础封装的三个关键点

第一个关键点是SO_REUSEADDR。服务端正常退出后，之前监听的端口会处于TIME_WAIT状态，紧接着重启服务端，bind会失败提示地址已被占用。这是因为TCP连接关闭后的TIME_WAIT要持续一段时间。用setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, ...)可以解决这个重启问题，这在开发阶段几乎是必备的。

第二个关键点是完整收发。send和recv都不能保证一次调用就把整段数据传完，尤其是网络繁忙时，所以必须封装成循环收发：

int send_all(int fd, const void *buf, size_t len) { const char *p = (const char *)buf; size_t left = len; while (left > 0) { ssize_t n = send(fd, p, left, 0); if (n < 0) { if (errno == EINTR) continue; return -1; } p += n; left -= n; } return 0; }

recv_all的实现逻辑与send_all对称。这套封装从文件IO那里沿用过来，思路完全一致。

第三个关键点是字节序。TCP协议规定多字节整数统一用网络字节序（大端），本地机器一般是小端。协议头里的body_len我用htonl编码、ntohl解码。我一开始忘了做这一步，结果就出现了"客户端声明的文件长度是0，服务端却解析出一个天文数字"的怪事，一下浪费了半天时间才定位到。

4.2 粘包与半包：TCP是字节流不是消息流

TCP是流式协议，它只保证字节的有序可靠传输，不保证单个send的数据块与单个recv的数据块一一对应。客户端连续发送两次数据，内核可能把两个包合并到一次recv里返回，这是粘包；反过来，一个大数据包可能分多次到达，recv只读到了其中一部分，这是半包。

处理方案很常规：通过消息头里的body_len按需读取。服务端接收一个完整请求的流程是：

int recv_proto_msg(int fd, struct proto_header *hdr, uint8_t **body) { // 1. 先完整接收头部，头部大小固定 if (recv_all(fd, hdr, sizeof(*hdr)) < 0) return -1; // 2. 头部字段转主机字节序 hdr->body_len = ntohl(hdr->body_len); // 3. 根据body_len分配缓冲区，循环接收数据体 *body = malloc(hdr->body_len); if (recv_all(fd, *body, hdr->body_len) < 0) { free(*body); return -1; } return 0; }

这一套做完，粘包和半包就不会再成为问题。如果收到的字节数不够一个头部，recv_all会一直等，直到完整头部到达或者连接异常返回。

4.3 超时控制与异常客户端处理

真实场景里客户端不一定规规矩矩，比如连上了但不发送任何数据，工作线程就一直阻塞在recv上，一个恶意或者单纯有Bug的客户端就能白白占住一个工作线程。为此我引入了接收超时：

struct timeval tv; tv.tv_sec = 60; tv.tv_usec = 0; setsockopt(conn_fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));

设置之后，如果60秒内没有收到任何数据，recv会返回-1，errno是EAGAIN或EWOULDBLOCK。这时候可以判定该连接异常，关闭连接释放线程资源。同理，发送方向也可以设置SO_SNDTIMEO，防止对端接收窗口阻塞把发送线程挂死。

另一个经常被忽略的问题是断连检测。对端通过close正常关闭连接时，recv返回0；对端进程崩溃或网络异常硬断开时，recv返回-1，errno是ECONNRESET。两种情况下都要关掉连接fd和释放已分配的内存，否则泄漏会越来越严重。

4.4 大文件传输的落地细节

协议头设计之初，我只放了文件名长度，但很快发现必须把文件大小也放进去。服务端下载文件时用fstat获取文件真实大小，发给客户端；客户端上传文件时，先在协议体里发送文件大小，服务端据此判断后续要收多少字节。

接收文件和服务端下载时，我都坚持"先写临时文件，传输确认完整后再rename成正式文件"。这个习惯是从下载工具那边学来的，可以避免传输到一半时服务端异常重启，留下一个残缺文件把正式文件污染掉。实际连接中，客户端每次下载完就对文件做一次md5校验，整个传输链路有没有出问题一目了然。

传输进度和限速这块，我在客户端加了一个简单的进度打印，下载时每收到1MB打印一次百分比。服务端因为要对多客户端公平，我没有做太复杂的限速，只是通过usleep控制每秒最大发送字节数。对于这个项目的训练目的来说，能把基本的传输闭环做扎实，比叠加花样的优先级更高。

5. Makefile组织工程与调试三板斧

项目做到这里，源文件已经有common、client、server三个目录，十来个头文件和源文件。每次手动敲gcc是不现实的，我用一份手写的Makefile完成了全部构建工作。

5.1 手写Makefile的基本结构

工程目录我按功能拆成三个子目录：

project/ ├── Makefile ├── common/ │ ├── proto.h │ └── proto.c ├── server/ │ ├── server.c │ ├── worker.c │ └── worker.h └── client/ └── client.c

Makefile的核心思路是：每个.c文件编译成对应的.o文件，最后链接生成两个可执行程序。我用变量和模式规则避免手写每一个文件的编译命令：

CC := gcc CFLAGS := -Wall -Wextra -O2 -g LDFLAGS := -lpthread COMMON_SRC := $(wildcard common/*.c) SERVER_SRC := $(wildcard server/*.c) CLIENT_SRC := $(wildcard client/*.c) COMMON_OBJ := $(COMMON_SRC:.c=.o) SERVER_OBJ := $(SERVER_SRC:.c=.o) $(COMMON_OBJ) CLIENT_OBJ := $(CLIENT_SRC:.c=.o) $(COMMON_OBJ) all: server client server: $(SERVER_OBJ) $(CC) $(CFLAGS) -o $@ $^ $(LDFLAGS) client: $(CLIENT_OBJ) $(CC) $(CFLAGS) -o $@ $^ $(LDFLAGS) %.o: %.c $(CC) $(CFLAGS) -c -o $@ $< clean: rm -f server client $(COMMON_OBJ) $(SERVER_OBJ) $(CLIENT_OBJ)

$(wildcard ...)会自动收集目录下所有.c文件，新增源文件不需要改Makefile；%.o: %.c模式规则把每个源文件单独编译。链接时-lpthread必须写，很多初学者写完线程代码但忘了链线程库，编译器一路报undefined reference to 'pthread_create'，其实就是少了这一步。

调试和发布版本我用宏开关区分：开发时开-g -DDEBUG -O0，方便断点和日志；发布时切到-O2 -DNDEBUG去掉调试日志。这里我踩过一个细节坑：服务端日志开关如果控制得不好，每传一个文件都打印一大屏调试信息会严重影响吞吐，所以日志模块我加了分级开关，只有DEBUG宏打开时才输出调试级日志。

5.2 头文件依赖自动管理

手写Makefile最容易踩的坑是头文件改了，包含它的.c文件不会重新编译。解决方案是让gcc生成.d依赖文件，通过-MMD -MP把每个源文件对头文件的依赖关系记录下来：

CFLAGS += -MMD -MP DEPS := $(COMMON_SRC:.c=.d) $(SERVER_SRC:.c=.d) $(CLIENT_SRC:.c=.d) -include $(DEPS)

这样只要任何头文件被修改，依赖它的源文件就会自动重新编译，省去了手动make clean的烦恼。这个特性我强烈建议刚学Makefile的人第一件事就加上，能省掉大量无意义的重复劳动。

5.3 gdb、strace、valgrind三板斧

到了调Bug环节，单靠printf效率太低，我把三板斧的用法整理了一遍，项目后期基本全靠这三样定位问题。

第一板斧是gdb，尤其是多线程程序。程序挂住或崩溃时，先用gdb ./server core打开core文件，再执行thread apply all bt，把所有线程的调用栈打出来。有一次服务端疑似死锁，就是靠这个看到两个工作线程都卡在条件变量等待上、主线程卡在accept上，很快就定位到是队列通知丢失。

第二板斧是strace。strace -p <pid>可以看到进程每次系统调用。怀疑网络收发异常时，strace -f -e trace=network -p <pid>能直接看到accept、recvfrom、sendto的参数和返回值，错误码一目了然。我定位EINTR问题就是靠它看到write(-1, EINTR)。

第三板斧是valgrind。valgrind --leak-check=full --show-leak-kinds=all -v ./server可以在压测结束后列出所有内存泄漏点。这个项目前期泄漏非常严重，主要集中在：连接关闭时忘了free收包缓冲区、线程池退出时没有回收线程资源。valgrind把每一处泄漏的文件和行号都打出来，改起来非常快。

5.4 我踩过并希望你别再踩的四个坑

这四个坑是我这个项目里最耗时、也最典型的，单列出来给后来者参考：

1. 字节序没转就解析长度字段：协议头里的长度字段必须统一用网络序。忘了ntohl，客户端声明的文件大小可能被解析成上千倍的错误值，malloc直接就失败了。
2. send没有处理短写就返回成功：测试环境网络好时一切正常，一旦数据量大或者网络波动，send只发了一半就返回，导致对端一直等后续数据，直接卡死。必须用send_all循环发完。
3. 条件变量用if判断而不是while：多个工作线程同时被唤醒时，较晚获得锁的线程拿到的任务可能已经被取走。用while循环重新检查队列状态，这是POSIX条件变量使用的基本功，忽略它的后果是偶发性越界访问。
4. Makefile忘了链接-lpthread：这是最让人哭笑不得的坑。编译器提示找不到pthread_create时，第一反应是去检查头文件，结果最后发现只是链接参数少了。建议一上来就把LDFLAGS写好。

5.5 端到端压测脚本

最后写了一个简单的bash脚本做并发验证，一次性起5个客户端同时从服务端下载同一个100MB文件，全部完成后逐一做md5校验：

#!/bin/bash for i in 1 2 3 4 5; do ./client download bigfile.bin ./out_$i.bin & done wait for i in 1 2 3 4 5; do md5sum bigfile.bin out_$i.bin done

第一次跑这脚本时，5个文件打印出的md5全部一致，那一刻才敢说这个并发文件传输服务真正站住了脚。之后再跑上传方向、异常断开、超时无响应这些边界场景，心里有底多了，因为整个传输链路的每一层都已经逐项验证过。

最后再分享一点个人体会：这个项目的正确打开方式不是把上面的代码抄一遍就完事，而是先让自己写出一个单线程版本，跑起来感受一下什么叫"第二个用户在等"；然后改成每连接一个线程，体会并发的爽快和资源开销；最后再上线程池，踩一遍条件变量和锁的坑。这个演进过程，每一步踩到的坑都是Linux系统编程里最值钱的经验积累。做完这个项目之后，如果你想继续深入，可以试着把线程池换成select或epoll多路复用模型，或者给传输加上加密和断点续传，那种改造带来的认知冲击，不会比这次小。