简介这份资源面向学习网络编程与MFC框架的C开发者尤其是需要完成课程实验或想动手实践Socket通信的初学者。内容围绕基于MFC的CSocket类实现客户端与服务端文件传输展开涵盖连接建立、文件读取、数据收发与本地保存等完整流程帮助读者理解TCP/IP通信与Windows GUI编程的结合方式。压缩包共63个文件约109.68MB包含cpp与h源码、vcxproj与sln工程文件、exe可执行程序以及obj、pdb、tlog等编译中间产物和资源文件可直接编译运行或对照研究。目前已有316人学习。通过这份源码读者能获得一套可运行的客户端与服务端双端工程掌握CSocket的Connect、Send、Receive、Bind、Listen、Accept等关键接口用法并参考文件I/O与连接释放的代码组织方式为后续网络应用开发打下基础。1. 从一份 MFC 文件传输源码包说起它到底能跑通什么如果你手头正好有一份MFCFileUpload.zip解压后看到MFCFileUpload1S服务端和MFCFileUpload1C客户端两个工程目录外加.vs、Debug、.sln这些 Visual Studio 的标配文件夹那基本可以确认这是一套用 MFC 的CSocket类做 TCP 文件传输的教学级完整工程。它的价值不在于代码有多复杂而在于把「网络编程」里最核心的几件事——Socket 创建、连接、监听、收发、文件落盘——用 C 和 MFC 串成了一条能直接编译运行的链路。适合正在学网络编程、需要交实验报告、或者想拿一个能跑的最小 C/S 模型去改造成自己工具的人。但要注意这类源码包通常默认在局域网、小文件、单连接场景下工作直接搬到公网或大文件场景会翻车后面几章会把边界和坑一条条拆开。2. 拆开工程看结构两个 sln 怎么分工CSocket 在哪一层2.1 服务端与客户端的工程边界解压后你会看到两个独立的解决方案文件MFCFileUpload1S.sln和MFCFileUpload1C.sln。这种「一个功能拆成两个 sln」的做法在教学工程里很常见好处是两边可以分别编译、分别调试互不干扰坏处是你得开两个 Visual Studio 实例或者至少开两个窗口来回切。服务端MFCFileUpload1S负责绑定端口、监听、接受连接、接收数据、写文件客户端MFCFileUpload1C负责选文件、连服务端、读文件、发数据、关连接。两边共享的只有 TCP 协议和端口号约定代码层面没有直接依赖所以你可以单独改客户端而不动服务端。.vs目录是 Visual Studio 的本地缓存里面存的是 IntelliSense 数据库、调试配置、窗口布局这类东西跟源码逻辑无关。Debug目录是编译产物里面是.exe、.pdb、.obj这些。如果你拿到的是别人编译过的包Debug 里可能已经有能直接双击运行的 exe但更稳妥的做法是自己用 Release 或 Debug 重新编译一遍避免路径和运行时库不匹配。2.2 CSocket 与 CAsyncSocket 的选型理由MFC 对 Windows Socket API 的封装主要有两个类CAsyncSocket和CSocket。这份工程里两者都会出现因为它们的职责不同。CAsyncSocket是更底层的封装所有操作都是异步的你需要自己处理OnConnect、OnReceive、OnAccept这些回调适合需要精细控制事件流的场景。CSocket继承自CAsyncSocket但把阻塞式操作和消息泵结合了起来调用Send、Receive、Accept时会在内部处理消息循环写起来更像同步代码适合教学和快速原型。服务端通常用CAsyncSocket做监听套接字因为Accept需要异步响应新连接客户端用CSocket做连接和发送因为流程是线性的连上、读文件、发完、关闭。这种混用不是必须的但能让你看清两种封装的差异。如果你把服务端也改成CSocket在单连接场景下也能跑但多客户端并发时消息泵的调度会变得难以预测。2.3 编译前必须确认的三件事在动手改代码之前先确认环境。第一Visual Studio 安装时勾选了「使用 C 的桌面开发」和「MFC 支持」。MFC 不是默认组件很多人装完 VS 发现找不到afxwin.h就是漏了这一步。第二两个 sln 的平台工具集要一致比如都是v143或都是v142否则一边编译通过、另一边报链接错误。第三字符集设置要统一MFC 工程默认用 Unicode如果你的文件路径里有中文CString和std::string之间的转换要显式处理不然会出现乱码或打开文件失败。提示如果你打开 sln 后提示「无法打开项目文件」或「找不到 MFC 头文件」先检查 VS Installer 里的 MFC 组件再检查 sln 里的工具集版本是否和你本机安装的匹配。3. 服务端实现Bind、Listen、Accept 与文件落盘3.1 监听套接字的创建与绑定服务端的启动流程是创建套接字、绑定地址和端口、开始监听、等待连接。在 MFC 里如果你用CAsyncSocket通常会在对话框或主窗口的初始化函数里完成前三步。端口号一般选 1024 以上避免和系统服务冲突。绑定地址可以用INADDR_ANY表示监听本机所有网卡也可以指定具体 IP。教学工程里常见的是绑定INADDR_ANY端口写死一个值比如 6000 或 8888。// 服务端创建监听套接字并绑定端口 BOOL CServerDlg::InitSocket() { // 创建异步套接字用于监听 if (!m_listenSocket.Create(6000, SOCK_STREAM, NULL)) { AfxMessageBox(_T(创建监听套接字失败)); return FALSE; } // 绑定到本机所有网卡的 6000 端口 if (!m_listenSocket.Bind(6000, _T(0.0.0.0))) { AfxMessageBox(_T(绑定端口失败可能被占用)); return FALSE; } // 开始监听等待队列长度 5 if (!m_listenSocket.Listen(5)) { AfxMessageBox(_T(监听失败)); return FALSE; } return TRUE; }Create的第二个参数SOCK_STREAM表示 TCP第三个参数留空表示默认协议。Bind的第二个参数写0.0.0.0等价于INADDR_ANY意思是接受任意网卡进来的连接。Listen的参数是等待队列长度5 表示最多允许 5 个未处理的连接排队超过的会被拒绝。教学场景下这个值够用但如果你要做压力测试需要调大并且考虑多线程或Accept循环。3.2 Accept 与新连接套接字的管理Accept是服务端最关键的调用。它从监听队列里取出一个已完成三次握手的连接并创建一个新的套接字专门和这个客户端通信。原来的监听套接字继续监听不受影响。在CAsyncSocket里Accept通常写在OnAccept回调里由框架在消息循环中触发。// 服务端响应新连接 void CServerDlg::OnAccept() { // 创建一个新的套接字对象处理这个客户端 CClientSocket* pClient new CClientSocket(this); // 接受连接把新套接字和客户端绑定 if (m_listenSocket.Accept(*pClient)) { // 保存到列表便于后续管理和清理 m_clientList.AddTail(pClient); // 通知界面有新客户端接入 UpdateStatus(_T(有新客户端连接)); } else { delete pClient; } }这里用new创建套接字对象是因为Accept需要一个已经构造好的CAsyncSocket派生对象来承载新连接。如果你在栈上创建函数返回后对象析构连接就断了。所以必须用堆分配并在连接关闭时delete。m_clientList是一个链表用来保存所有活跃的客户端套接字方便在程序退出时统一清理。如果你不做这个列表程序关闭时可能残留套接字导致端口在一段时间内无法重新绑定。3.3 接收数据与文件写入的边界处理接收文件数据比发送复杂因为 TCP 是字节流没有消息边界。你不能假设一次Receive就能拿到一个完整文件也不能假设每次收到的数据长度固定。常见做法是先发一个固定长度的文件头包含文件名和文件大小然后再发文件内容服务端先收文件头解析出大小再循环接收直到收满为止。// 服务端接收文件头并准备落盘 void CClientSocket::OnReceive(int nErrorCode) { if (nErrorCode ! 0) return; if (!m_bHeaderReceived) { // 先收固定长度的文件头 char header[256] {0}; int n Receive(header, sizeof(header)); if (n 0) return; // 解析文件名和文件大小这里假设用 name|size 格式 CString strHeader(header); int pos strHeader.Find(_T(|)); m_strFileName strHeader.Left(pos); m_nFileSize _ttoi(strHeader.Mid(pos 1)); m_bHeaderReceived TRUE; // 打开本地文件准备写入 m_file.Open(m_strFileName, CFile::modeCreate | CFile::modeWrite); m_nReceived 0; } else { // 循环接收文件内容 char buffer[4096]; int n Receive(buffer, sizeof(buffer)); if (n 0) { m_file.Write(buffer, n); m_nReceived n; if (m_nReceived m_nFileSize) { m_file.Close(); UpdateStatus(_T(文件接收完成)); } } else if (n 0) { // 对端关闭连接 m_file.Close(); } } CAsyncSocket::OnReceive(nErrorCode); }Receive返回 0 表示对端正常关闭返回SOCKET_ERROR表示出错。这里用m_bHeaderReceived标志位区分「收头」和「收体」两个阶段。文件头长度固定 256 字节是为了简化解析实际工程里更稳妥的做法是先发 4 字节的长度字段再发变长的头内容。CFile的modeCreate会覆盖同名文件如果你不想覆盖需要先检查文件是否存在。m_nReceived用来累计已收字节数和m_nFileSize比较判断是否收完。这个逻辑在单文件、小文件场景下没问题但如果你要传多个文件需要在文件头里加序号或结束标志。注意Receive的缓冲区大小不要设得太小4096 是常见值但如果你传大文件可以调到 8192 或 16384 减少调用次数。不过缓冲区越大单次阻塞时间可能越长需要根据实际网络状况权衡。4. 客户端实现选文件、Connect、Send 与进度反馈4.1 文件选择与路径处理客户端的第一步是让用户选一个本地文件。MFC 里用CFileDialog就能搞定返回的CString是完整路径。拿到路径后你需要打开文件、获取大小、读取内容。这里有个容易忽略的点如果文件很大一次性读进内存会占用大量堆空间甚至导致程序崩溃。更稳妥的做法是分块读取、分块发送。// 客户端选择文件并获取基本信息 void CClientDlg::OnBnClickedBtnSelect() { CFileDialog dlg(TRUE, NULL, NULL, OFN_HIDEREADONLY, _T(所有文件 (*.*)|*.*||)); if (dlg.DoModal() IDOK) { m_strFilePath dlg.GetPathName(); // 获取文件名用于发给服务端 m_strFileName dlg.GetFileName(); // 打开文件获取大小 CFile file; if (file.Open(m_strFilePath, CFile::modeRead)) { m_nFileSize (int)file.GetLength(); file.Close(); UpdateData(FALSE); } } }CFileDialog的第一个参数TRUE表示打开文件对话框FALSE表示保存对话框。GetPathName返回完整路径GetFileName只返回文件名。CFile::GetLength返回ULONGLONG这里强转成int是因为教学工程通常只传小文件如果你要传超过 2GB 的文件必须用 64 位类型并且协议里的文件大小字段也要相应扩展。4.2 Connect 与发送流程连接服务端用CAsyncSocket::Connect或CSocket::Connect。CAsyncSocket的Connect是异步的调用后立即返回实际连接结果在OnConnect回调里通知。CSocket的Connect会阻塞直到连接成功或失败写起来更直观。教学工程里客户端常用CSocket因为流程简单。// 客户端连接服务端并发送文件 void CClientDlg::OnBnClickedBtnSend() { if (m_strFilePath.IsEmpty()) { AfxMessageBox(_T(请先选择文件)); return; } // 创建套接字并连接 if (!m_socket.Create()) { AfxMessageBox(_T(创建套接字失败)); return; } if (!m_socket.Connect(_T(127.0.0.1), 6000)) { AfxMessageBox(_T(连接服务端失败)); return; } // 发送文件头文件名|大小 CString strHeader; strHeader.Format(_T(%s|%d), m_strFileName, m_nFileSize); char header[256] {0}; strcpy_s(header, CT2A(strHeader)); m_socket.Send(header, sizeof(header)); // 分块读取并发送文件内容 CFile file; if (!file.Open(m_strFilePath, CFile::modeRead)) { AfxMessageBox(_T(打开文件失败)); return; } const int BUFFER_SIZE 4096; char buffer[BUFFER_SIZE]; UINT nRead 0; while ((nRead file.Read(buffer, BUFFER_SIZE)) 0) { m_socket.Send(buffer, nRead); // 更新进度条 m_nSent nRead; m_progress.SetPos(m_nSent * 100 / m_nFileSize); // 处理消息避免界面卡死 MSG msg; while (PeekMessage(msg, NULL, 0, 0, PM_REMOVE)) { TranslateMessage(msg); DispatchMessage(msg); } } file.Close(); m_socket.Close(); AfxMessageBox(_T(发送完成)); }Connect的第二个参数是端口号必须和服务端Bind的端口一致。strcpy_s是安全版本的字符串拷贝CT2A把CString转成char*这里假设工程用的是多字节字符集如果是 Unicode需要用CT2A或WideCharToMultiByte做转换。发送循环里用PeekMessage处理消息队列是为了让进度条能刷新、按钮能响应否则界面会在发送大文件时假死。m_progress是进度条控件SetPos设置当前位置范围是 0 到 100。4.3 进度反馈与界面响应进度反馈不只是好看它能帮你判断程序是不是卡住了。如果进度条长时间不动可能是Send阻塞了也可能是服务端没收。Send在 TCP 里并不保证数据立即到达它只是把数据交给内核发送缓冲区。如果缓冲区满了Send会阻塞阻塞模式或返回WSAEWOULDBLOCK非阻塞模式。教学工程里通常用阻塞模式所以大文件发送时界面会卡需要手动泵消息。提示如果你发现发送速度远低于网络带宽先检查是不是每次Send的块太小或者消息泵调用太频繁。把BUFFER_SIZE调到 8192 或 16384 通常能明显改善。5. 避坑与排查端口占用、粘包、中文路径与调试断点5.1 端口被占用导致 Bind 失败现象服务端启动时弹窗提示「绑定端口失败」或者Bind返回FALSE。原因通常是上一次运行的服务端进程没有完全退出端口还处于TIME_WAIT状态或者被其他程序占用了。解决方法是先确认没有残留进程在任务管理器里结束掉旧的 exe如果还不行换一个端口号比如从 6000 改成 6001。更彻底的做法是在Bind之前设置SO_REUSEADDR选项允许重用本地地址。// 设置 SO_REUSEADDR避免 TIME_WAIT 导致绑定失败 int nOpt 1; m_listenSocket.SetSockOpt(SO_REUSEADDR, nOpt, sizeof(nOpt), SOL_SOCKET);SetSockOpt的第二个参数是选项值第三个是长度第四个是选项名第五个是协议层级。SO_REUSEADDR在 Windows 上的行为和 Linux 略有不同但教学场景下够用。5.2 TCP 粘包导致文件内容错位现象服务端收到的文件比原文件大或者内容开头多了几个字节甚至文件名解析错误。原因是 TCP 是字节流发送端连续调用两次Send接收端可能一次Receive就把两次的数据都收上来了这就是粘包。解决方法是定义明确的消息边界要么固定长度要么在每条消息前加长度字段。这份工程用固定 256 字节的文件头来分隔但如果文件头本身没发满 256 字节或者发送端和接收端的结构体对齐方式不同仍然会错位。更稳妥的做法是先发 4 字节的int表示文件头长度再发文件头内容服务端先收 4 字节解析出长度再收对应长度的头。这样无论头内容多长边界都是清晰的。5.3 中文路径与字符集不匹配现象选择带中文路径的文件后服务端收到的文件名是乱码或者CFile::Open失败。原因是客户端和服务端的字符集设置不一致或者CString转char*时用了错误的转换函数。MFC 工程默认是 UnicodeCString内部是wchar_t而Send发送的是字节流。如果你直接strcpy到char数组中文会丢失。解决方法是统一用 UTF-8 或 GBK 编码传输文件名并在两端做对应的转换。简单做法是在工程属性里把字符集改成「使用多字节字符集」这样CString和char*可以直接互转但这不是长久之计。更好的做法是显式调用WideCharToMultiByte和MultiByteToWideChar指定代码页。5.4 调试断点导致连接超时现象在OnReceive或OnAccept里下断点后程序卡在断点处客户端提示连接断开或发送失败。原因是 MFC 的套接字依赖消息泵断点暂停了消息循环套接字事件无法及时处理对端等不到响应就超时了。解决方法是在调试网络代码时尽量用日志输出代替断点或者把断点下在不会阻塞消息循环的地方。如果必须用断点先把超时时间调大或者用非阻塞模式。5.5 文件大小超过 int 范围现象传大文件时进度条显示负数或者服务端收到的文件不完整。原因是CFile::GetLength返回ULONGLONG但代码里强转成了int超过 2GB 就溢出。解决方法是用ULONGLONG或__int64存储文件大小协议里的长度字段也用 8 字节。进度条的计算也要相应调整避免整数溢出。6. 进阶改造多客户端并发与断点续传的落地思路把这份教学工程改造成能用的工具最常走的两条路是多客户端并发和断点续传。多客户端并发的核心是把Accept放到循环里每个新连接分配一个独立线程或独立套接字对象互不阻塞。MFC 里可以用AfxBeginThread创建工作线程在线程里处理该客户端的收发。但要注意MFC 对象不能跨线程直接访问界面更新要用PostMessage发回主线程。断点续传的关键是记录已收字节数。服务端在接收前先检查本地是否已有同名文件如果有把已收大小发给客户端客户端从该偏移量开始读文件并发送。协议里需要增加一个「续传请求」和「续传响应」的消息类型。下面是一个简化的续传判断逻辑// 服务端检查是否存在未完成的文件返回已收大小 ULONGLONG CClientSocket::GetReceivedSize(const CString strFileName) { CFileStatus status; if (CFile::GetStatus(strFileName, status)) { // 文件存在返回当前大小作为续传起点 return status.m_size; } return 0; }CFile::GetStatus能拿到文件大小和修改时间。如果文件存在但大小小于预期就从该大小开始追加写入。客户端收到已收大小后用CFile::Seek跳到对应位置继续读。这个逻辑在单文件、单连接场景下能跑通但多客户端同时续传同一个文件时会冲突需要加锁或按客户端隔离临时文件。验证改造是否成功最直接的方法是传一个 500MB 以上的文件中途手动断开客户端再重新连接看服务端是否从断点继续。如果服务端重新从头接收说明续传逻辑没生效如果文件最终大小和原文件一致且能正常打开说明改造成功。从那以后我每次拿到这类教学源码都会先跑一遍小文件确认链路通再传一个大文件看边界最后断一次网验证续传。这套习惯帮我省了很多「看起来能跑、实际一上量就崩」的后悔药。希望帮到你。本文还有配套的精品资源点击获取