MFC网络编程实战：文件传输中的TCP粘包与多线程处理

简介：这份资源面向学习网络编程与MFC框架的C++开发者，提供一套完整的文件传输实验方案，包含客户端与服务端两个可运行程序。实验以Socket编程为核心，借助MFC封装的CSocket类完成连接建立、文件读取、数据收发与本地保存，覆盖TCP/IP通信、文件I/O操作及面向对象代码组织等知识点，适合课程实验、自学练手或项目参考。压缩包共63个文件，约109.68MB，以h头文件、cpp源文件、vcxproj工程文件、sln解决方案为主，另含exe可执行程序、pdb调试符号、obj编译中间文件及rc资源脚本等，工程结构完整，可直接用Visual Studio打开编译运行。目前已有316人学习下载。读者可从中获得客户端与服务端的完整源码、连接与收发流程的实现思路，以及文件传输过程中资源释放与异常处理的参考写法，便于对照理解MFC网络编程的落地方式。

1. 网络编程实验：MFC实现文件传输，为什么今天还值得动手做一遍

很多人第一次接触 socket 网络编程，是在控制台里敲send和recv，跑通一个「服务端发一句 hello，客户端打印出来」就结束了。可一旦要传真实文件，问题立刻冒出来：TCP 粘包怎么切、大文件怎么分块、进度条怎么实时刷新、客户端断线服务端怎么感知。MFC 实现文件传输这个实验，恰好把这些坑一次性摊在你面前。它不是一个过时的玩具，而是一个把 Windows 消息循环、阻塞 socket、多线程、文件 IO 揉在一起的综合练习。适合刚学完 C++ 和网络编程基础、想找一个能看得见界面的项目练手的人，也适合需要给内部工具加一个「局域网传文件」功能的工程师。下面按「先跑通最小链路，再补健壮性」的顺序讲清楚。

2. 先把 C/S 链路跑通：MFC 里 socket 的初始化与最小收发

2.1 为什么选阻塞 socket + 工作线程，而不是异步模型

MFC 里做网络编程，常见有三条路：CAsyncSocket、CSocket、以及直接调用 Winsock 的阻塞 socket。CAsyncSocket 基于窗口消息通知，写起来事件驱动很优雅，但它的回调在 UI 线程里跑，一旦在 OnReceive 里做文件写盘，界面就卡死。CSocket 虽然内部帮你把阻塞调用转成了消息泵，但它的序列化机制和异常处理对新手不够透明，出问题很难定位。

我一般会选最朴素的方案：服务端和客户端各起一个独立工作线程，线程里用阻塞 socket 做 accept、recv、send，主线程只管界面。这样职责清晰，调试时能明确知道卡在哪一步。代价是要自己处理线程退出和 socket 关闭的时序，但这恰恰是网络编程必须学会的东西。

提示：Winsock 使用前必须调用WSAStartup，程序退出前调用WSACleanup，两者配对。MFC 的AfxSocketInit()内部帮你做了这件事，但如果你混用原生 Winsock API，建议还是显式调用，避免引用计数混乱。

2.2 服务端最小可运行代码：监听、接受、收文件

下面这段代码放在服务端的工作线程函数里，负责监听端口、接受一个连接、把收到的数据写入文件。为了先跑通，这里假设客户端会先发一个固定长度的文件头（文件名长度 + 文件名 + 文件大小），再发文件内容。

// 服务端工作线程：监听并接收文件 UINT ServerRecvThread(LPVOID pParam) { // 1. 创建监听 socket SOCKET listenSock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); if (listenSock == INVALID_SOCKET) return 1; sockaddr_in addr = { 0 }; addr.sin_family = AF_INET; addr.sin_port = htons(9527); // 监听端口，可改 addr.sin_addr.s_addr = INADDR_ANY; // 接受任意网卡连接 if (bind(listenSock, (sockaddr*)&addr, sizeof(addr)) == SOCKET_ERROR) { closesocket(listenSock); return 1; } listen(listenSock, SOMAXCONN); // 2. 阻塞等待客户端连接 SOCKET clientSock = accept(listenSock, nullptr, nullptr); if (clientSock == INVALID_SOCKET) { closesocket(listenSock); return 1; } // 3. 先收 4 字节文件名长度（网络字节序） int nameLen = 0; recv(clientSock, (char*)&nameLen, 4, 0); nameLen = ntohl(nameLen); // 4. 收文件名 char fileName[256] = { 0 }; recv(clientSock, fileName, nameLen, 0); // 5. 收 8 字节文件大小 long long fileSize = 0; recv(clientSock, (char*)&fileSize, 8, 0); fileSize = ntohll(fileSize); // 需自行实现 64 位字节序转换 // 6. 循环收文件内容，写入磁盘 FILE* fp = fopen(fileName, "wb"); char buf[4096]; long long received = 0; while (received < fileSize) { int n = recv(clientSock, buf, sizeof(buf), 0); if (n <= 0) break; // 连接断开或出错 fwrite(buf, 1, n, fp); received += n; // 此处可向主线程 PostMessage 更新进度 } fclose(fp); closesocket(clientSock); closesocket(listenSock); return 0; }

逻辑说明：先建立监听，accept 返回后开始按「长度前缀」协议读取。文件名长度用 4 字节 int，文件大小用 8 字节 long long，都转成网络字节序发送，避免大小端不一致。收文件时用固定 4KB 缓冲区循环 recv，直到累计字节数等于文件大小。参数方面，端口 9527 可换成任意未占用端口；缓冲区 4096 是经验值，局域网下可以调到 8192 或 16384 提升吞吐，但要注意每次 recv 返回的字节数并不等于请求的字节数，必须按返回值累加。

2.3 客户端最小可运行代码：连接、发头、发内容

客户端工作线程先 connect，然后按同样协议发送文件头，再循环读文件发送。

// 客户端工作线程：连接服务端并发送文件 UINT ClientSendThread(LPVOID pParam) { CString* pFilePath = (CString*)pParam; CString filePath = *pFilePath; SOCKET sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); sockaddr_in addr = { 0 }; addr.sin_family = AF_INET; addr.sin_port = htons(9527); inet_pton(AF_INET, "127.0.0.1", &addr.sin_addr); // 换成服务端 IP if (connect(sock, (sockaddr*)&addr, sizeof(addr)) == SOCKET_ERROR) { closesocket(sock); return 1; } // 打开文件，取文件名和大小 CFile file; if (!file.Open(filePath, CFile::modeRead | CFile::typeBinary)) { closesocket(sock); return 1; } ULONGLONG fileSize = file.GetLength(); CString fileName = file.GetFileName(); // 发文件名长度 + 文件名 int nameLen = fileName.GetLength(); int nameLenNet = htonl(nameLen); send(sock, (char*)&nameLenNet, 4, 0); send(sock, (char*)fileName.GetString(), nameLen, 0); // 发文件大小 long long sizeNet = htonll(fileSize); send(sock, (char*)&sizeNet, 8, 0); // 循环读文件发送 char buf[4096]; UINT nRead = 0; while ((nRead = file.Read(buf, sizeof(buf))) > 0) { send(sock, buf, nRead, 0); } file.Close(); closesocket(sock); return 0; }

逻辑说明：inet_pton把点分十进制 IP 转成二进制，比旧版inet_addr更安全。发送时先发 4 字节长度，再发文件名本身，最后发 8 字节大小。文件内容按 4KB 块读取发送。注意send返回值可能小于请求发送的字节数，严格来说需要循环发送直到发完，这里为了代码简洁先省略，后面避坑章节会专门讲。

3. 把「能传」变成「传得稳」：协议设计与粘包处理

3.1 为什么必须自己定协议：TCP 是字节流，没有消息边界

TCP 只保证字节按序到达，不保证你调用一次 send 就对应对方一次 recv。如果客户端连续发「文件名长度 + 文件名 + 文件大小」，服务端一次 recv 可能只收到前 2 个字节，也可能把三部分全收到还多带了文件内容。这就是粘包。解决方式只有两种：定长消息，或者给每条消息加长度前缀。文件传输里文件名长度不固定，所以必须用长度前缀。

上面最小代码里其实已经用了长度前缀，但只处理了「一次 recv 刚好收全」的理想情况。真实网络下，recv(clientSock, (char*)&nameLen, 4, 0)可能只返回 2，剩下 2 字节下次才到。所以需要一个recvAll辅助函数，确保收满指定字节数再返回。

// 确保收满 len 字节，返回实际收到的字节数 int recvAll(SOCKET sock, char* buf, int len) { int total = 0; while (total < len) { int n = recv(sock, buf + total, len - total, 0); if (n <= 0) return total; // 连接关闭或出错 total += n; } return total; }

逻辑说明：循环 recv 直到累计收满 len 或连接断开。参数 buf 是输出缓冲区，len 是期望字节数。返回值小于 len 说明对端提前关闭，调用方应视为错误。这个函数是后面所有定长字段读取的基础。

3.2 文件头结构体怎么定：字段顺序、字节序、对齐

把文件头定义成一个结构体，发送前逐字段转网络字节序，比散着发更清晰。常见做法是：

发送顺序固定为 nameLen → fileName → fileSize → md5。接收方按同样顺序读。注意不要直接把结构体send((char*)&header, sizeof(header), 0)，因为编译器可能插入填充字节，且字节序没转。逐字段序列化虽然多写几行，但跨平台和跨编译器都稳。

注意：文件名建议只传文件名，不传完整路径。服务端收到后自己拼接收目录，避免客户端传入..\..\这类路径造成目录穿越。

3.3 大文件分块与进度反馈：PostMessage 更新 UI

传大文件时界面不能卡，进度条要动。工作线程里每收/发一块，就向主窗口 PostMessage 一个自定义消息，携带当前字节数和总字节数。主窗口收到后更新进度条控件。

// 工作线程中发送进度 #define WM_UPDATE_PROGRESS (WM_USER + 100) PostMessage(hMainWnd, WM_UPDATE_PROGRESS, (WPARAM)received, (LPARAM)fileSize); // 主窗口消息处理 afx_msg LRESULT OnUpdateProgress(WPARAM wParam, LPARAM lParam) { long long received = (long long)wParam; long long total = (long long)lParam; int percent = total > 0 ? (int)(received * 100 / total) : 0; m_progressCtrl.SetPos(percent); return 0; }

逻辑说明：PostMessage 是异步的，不会阻塞工作线程。wParam 和 lParam 都是 32 位，传 64 位文件大小时需要拆成两个参数或用指针，这里为了演示先假设文件小于 2GB。参数 percent 是整数百分比，进度条控件范围设为 0 到 100。

4. 避坑与排查：文件传输实验里最容易翻车的 5 个点

4.1 现象：小文件能传，大文件传到一半卡死

原因：发送端send返回值没检查，或者接收端recv缓冲区太小导致 TCP 窗口填满后双方互相等待。更常见的是发送端一次性把整个文件读进内存再 send，内存爆了或 send 阻塞。

解决：发送端必须循环读文件、循环 send，并且检查 send 返回值。接收端 recv 循环不能假设一次收完。双方都不要一次性分配整个文件大小的缓冲区。

4.2 现象：服务端收到的文件名乱码或带尾巴

原因：文件名长度按字符数算，但发送时用了多字节编码，一个中文占 2 或 3 字节，长度对不上。或者 recv 文件名时没有补\0。

解决：统一用 UTF-8 编码，长度按字节数算。接收方收到后手动在末尾补\0。如果项目要求宽字符，收发两端都统一用WideCharToMultiByte转 UTF-8。

4.3 现象：客户端点关闭窗口，服务端线程不退，进程残留

原因：工作线程阻塞在recv或accept上，主线程直接退出，没有通知线程结束，也没有 closesocket。

解决：主窗口 OnClose 里先closesocket监听 socket 和连接 socket，让阻塞调用返回错误，再等待线程退出。或者用select加超时，定期检查退出标志。不要用TerminateThread，会泄漏资源。

4.4 现象：同一台机器测试正常，换两台机器就连不上

原因：客户端连接地址写的是127.0.0.1，只能连本机。或者服务端防火墙没放行端口。

解决：客户端 IP 改成服务端实际局域网 IP。服务端程序首次运行时会弹出 Windows 防火墙提示，必须允许专用网络访问。如果没弹，手动在防火墙入站规则里加端口。

4.5 现象：传输速度只有几 MB/s，远低于局域网带宽

原因：每次 recv/send 缓冲区太小，或者每发一块就刷一次界面导致消息队列拥堵。

解决：缓冲区调到 32KB 或 64KB。进度消息不要每块都发，可以每 1% 或每 100ms 发一次。关闭 Nagle 算法：setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, ...)，但文件传输是批量数据，Nagle 影响不大，主要瓶颈还是缓冲区大小和磁盘 IO。

5. 进阶技巧：用 select 做多客户端与断线检测

单客户端实验跑通后，下一步自然是支持多客户端同时上传。最直接的办法是每个 accept 返回的 socket 起一个线程，但客户端多了线程数爆炸。更稳的做法是用select或WSAEventSelect做 IO 多路复用。下面给一个 select 版本的服务端骨架，能同时处理多个连接，并在对端断开时及时清理。

// select 多客户端服务端骨架 fd_set readSet; std::vector<SOCKET> clients; while (bRunning) { FD_ZERO(&readSet); FD_SET(listenSock, &readSet); SOCKET maxSock = listenSock; for (SOCKET s : clients) { FD_SET(s, &readSet); if (s > maxSock) maxSock = s; } timeval tv = { 0, 200000 }; // 200ms 超时，便于检查退出标志 int ret = select((int)maxSock + 1, &readSet, nullptr, nullptr, &tv); if (ret <= 0) continue; if (FD_ISSET(listenSock, &readSet)) { SOCKET newClient = accept(listenSock, nullptr, nullptr); if (newClient != INVALID_SOCKET) clients.push_back(newClient); } for (auto it = clients.begin(); it != clients.end(); ) { if (FD_ISSET(*it, &readSet)) { char buf[4096]; int n = recv(*it, buf, sizeof(buf), 0); if (n <= 0) { closesocket(*it); it = clients.erase(it); continue; } // 处理收到的数据，按协议解析 } ++it; } }

逻辑说明：select 每次循环把监听 socket 和所有客户端 socket 加入读集合，超时 200ms 让线程有机会检查退出标志。FD_ISSET判断哪个 socket 可读。accept 新连接加入 vector，recv 返回 0 或负数说明对端关闭，closesocket 后从 vector 移除。参数timeval的 200000 微秒是轮询间隔，太小浪费 CPU，太大断线感知慢，200ms 是折中值。

这个骨架里每个客户端的状态（收到多少、文件句柄）需要单独维护，可以用一个结构体 vector 代替裸 socket vector。文件头解析也要改成状态机：先收 4 字节长度，再收文件名，再收 8 字节大小，再收内容。状态机用枚举标记当前阶段，避免粘包时解析错位。

我自己的习惯是，任何网络实验只要涉及多客户端，先上 select 骨架，再往里填业务逻辑。单线程 select 写起来比多线程直观，断点调试也简单。唯一要注意的是不要在 select 循环里做阻塞操作，比如大文件写盘可以放到独立线程或异步 IO。这个实验做到这一步，基本就覆盖了 MFC 网络编程的主要知识点：Winsock 初始化、阻塞与非阻塞、粘包处理、多路复用、线程与 UI 通信。希望帮到你。

本文还有配套的精品资源，点击获取