简介本资源是一套基于MFC框架实现的TCP客户端-服务器通信完整示例项目面向Windows平台C初学者及网络编程入门者解决Win32底层Socket开发门槛高、MFC网络模块实践案例匮乏的问题。压缩包共59个文件含8个头文件.h定义类接口与消息映射6个源文件.cpp实现核心通信逻辑2个可执行文件.exe可直接运行验证双端交互另有资源文件.rc、.ico、.bmp和调试产物.pdb、.obj整体4.54MB结构清晰、工程完整便于编译调试与代码溯源。已有877人学习下载项目包含独立的客户端与服务器双工程jly_Socket_TCP_Client / jly_Socket_TCP_Server均基于CSocket封装覆盖套接字创建、绑定、监听、连接、收发与关闭全流程并附ReadMe说明与标准MFC对话框界面是理解MFC网络编程机制、掌握Windows桌面级C/S应用开发的典型教学范例。1. MFC_TCP_Socket客户端服务器一个能真正在Windows桌面环境跑通、调试、断点跟踪的TCP通信最小可运行系统你有没有试过在VS里新建一个MFC项目拖几个Edit Control和Button然后照着网上零散博客拼凑CSocket或CAsyncSocket代码——结果连OnConnect()都不触发Send()返回0WSAGetLastError()却只报个10035非阻塞模式下资源暂不可用这不是你代码写错了而是绝大多数“MFCSocket”教程根本没告诉你MFC的Socket类不是独立模块它深度耦合于MFC消息循环、线程模型与资源生命周期。这个MFC_TCP_Socket(客户端服务器)资源包就是我从某高校课程设计源码中完整剥离、验证并重打包的可调试、可断点、可复现的双端工程——它不依赖第三方库不封装黑盒类所有Socket创建、连接、收发、关闭逻辑全部裸露在.cpp文件中且已通过Windows 10/11 VS2019/VS2022实测编译通过。适合两类人一是刚学完Win32 API想过渡到MFC框架的开发者二是需要快速搭建本地调试用TCP通信桩的嵌入式/工控测试人员。它解决的不是“能不能连上”而是“为什么连不上时你能立刻在OnReceive()里看到nErrorCode到底是10053还是10054”。2. 为什么选CAsyncSocket而不是CSocket或原始Winsock API消息驱动模型与MFC生命周期的硬绑定MFC对网络编程的支持并非“加个Socket类就完事”而是一整套与UI线程、消息泵、对象销毁强关联的设计。CSocket是阻塞式封装直接调用会卡死UI线程原始Winsock API虽灵活但需手动WSAStartup/WSACleanup、管理select/WSAEventSelect且无法自然融入MFC消息流。CAsyncSocket是唯一正解——它通过Windows消息WM_SOCKET_NOTIFY将网络事件连接、接收、关闭转为MFC消息由CWnd::OnCommand统一分发天然适配MFC的ON_MESSAGE宏机制。本资源包所有通信逻辑均基于CAsyncSocket派生类实现且严格遵循其生命周期约束Socket对象必须在UI线程创建不能跨线程传递句柄Close()后必须等待OnClose()回调完成才能析构对象。这是很多初学者翻车的第一道坎。2.1 客户端Socket类设计继承CAsyncSocket并重载关键虚函数// ClientSocket.h class CClientSocket : public CAsyncSocket { public: CClientSocket(); virtual ~CClientSocket(); // 必须重载的四个核心回调 virtual void OnConnect(int nErrorCode) override; virtual void OnReceive(int nErrorCode) override; virtual void OnSend(int nErrorCode) override; virtual void OnClose(int nErrorCode) override; // 自定义发送接口带长度校验 BOOL SendData(const BYTE* pData, int nLength); private: CWnd* m_pOwnerWnd; // 持有者窗口指针用于PostMessage通知UI };注意CAsyncSocket的Create()方法默认创建非阻塞Socket且m_hSocket在Create()成功后才有效。若Create()失败如端口被占用m_hSocket仍为INVALID_SOCKET后续调用Connect()会崩溃。本包在Create()后强制检查m_hSocket ! INVALID_SOCKET并在OnConnect()中通过nErrorCode判断连接成败——这是比Connect()返回值更可靠的依据。2.2 服务端Socket类设计监听Socket与工作Socket分离// ServerSocket.h class CServerSocket : public CAsyncSocket { public: CServerSocket(); virtual ~CServerSocket(); virtual void OnAccept(int nErrorCode) override; // 监听Socket不处理数据只负责Accept新连接 // 每个新连接由新CClientSocket对象处理 void SetOwnerWnd(CWnd* pWnd) { m_pOwnerWnd pWnd; } private: CWnd* m_pOwnerWnd; }; // ClientHandler.h —— 真正处理客户端数据的工作Socket class CClientHandler : public CAsyncSocket { public: CClientHandler(); virtual ~CClientHandler(); virtual void OnReceive(int nErrorCode) override; virtual void OnClose(int nErrorCode) override; void SetClientID(int nID) { m_nClientID nID; } int GetClientID() const { return m_nClientID; } private: CWnd* m_pOwnerWnd; int m_nClientID; // 服务端分配的唯一ID用于UI区分多客户端 };逻辑说明服务端采用“监听Socket 多工作Socket”经典模型。CServerSocket仅响应OnAccept()每次Accept()成功即创建一个CClientHandler实例并将其m_hSocket设为新连接句柄。CClientHandler负责该客户端的所有收发逻辑。这种分离避免了单个Socket混杂监听与数据处理逻辑也防止OnAccept()中执行耗时操作阻塞新连接。2.3 主对话框类中Socket对象的声明与生命周期管理// MainDlg.h class CMainDlg : public CDialogEx { // ... 其他成员 private: CClientSocket m_ClientSocket; // 客户端Socket单例 CServerSocket m_ServerSocket; // 服务端监听Socket单例 CListCClientHandler*, CClientHandler* m_ClientList; // 存储所有活动客户端Handler CRITICAL_SECTION m_CS; // 多客户端访问临界区OnReceive可能并发 };// MainDlg.cpp —— 在OnInitDialog中初始化 BOOL CMainDlg::OnInitDialog() { CDialogEx::OnInitDialog(); // 初始化临界区必须否则多客户端OnReceive并发写UI会崩 InitializeCriticalSection(m_CS); // 关联Socket与窗口关键否则OnXXX不会被调用 m_ClientSocket.m_pOwnerWnd this; m_ServerSocket.m_pOwnerWnd this; return TRUE; } // 对话框销毁时清理 void CMainDlg::OnDestroy() { CDialogEx::OnDestroy(); // 强制关闭所有Socket按正确顺序 m_ClientSocket.Close(); // 触发OnClose m_ServerSocket.Close(); // 触发OnClose // 清理所有ClientHandler POSITION pos m_ClientList.GetHeadPosition(); while (pos ! NULL) { CClientHandler* pHandler m_ClientList.GetNext(pos); if (pHandler) { pHandler-Close(); // 触发其OnClose delete pHandler; } } m_ClientList.RemoveAll(); DeleteCriticalSection(m_CS); }参数说明m_pOwnerWnd是自定义成员用于在OnReceive()等回调中通过PostMessage()向主窗口发送自定义消息如WM_CLIENT_DATA_RECEIVED避免在Socket回调中直接操作UI控件MFC控件非线程安全。CRITICAL_SECTION用于保护m_ClientList因为多个CClientHandler::OnReceive()可能同时触发需互斥访问列表。3. 连接建立与数据收发的核心流程从Create到OnReceive的完整链路MFC的CAsyncSocket不是“开箱即用”它的每一步都依赖正确的调用顺序和错误检查。本包所有流程均按微软官方文档《Asynchronous Socket Classes》推荐路径实现且增加了关键日志与断点标记。3.1 客户端连接流程Create → Connect → OnConnect// 用户点击“连接”按钮时触发 void CMainDlg::OnBnClickedBtnConnect() { CString strIP, strPort; GetDlgItemText(IDC_EDIT_IP, strIP); GetDlgItemText(IDC_EDIT_PORT, strPort); UINT nPort _ttoi(strPort); if (nPort 0 || nPort 65535) { AfxMessageBox(_T(端口号必须是1-65535之间的整数)); return; } // 1. 创建Socket非阻塞 if (!m_ClientSocket.Create()) { int nErr WSAGetLastError(); AfxMessageBox(_T(Create失败错误码) CString(nErr)); return; } // 2. 发起连接异步 if (!m_ClientSocket.Connect(strIP, nPort)) { int nErr WSAGetLastError(); // 10035是正常现象非阻塞模式下连接未立即完成 if (nErr ! WSAEWOULDBLOCK) { AfxMessageBox(_T(Connect调用失败错误码) CString(nErr)); m_ClientSocket.Close(); return; } // WSAEWOULDBLOCK连接正在进行等待OnConnect回调 } else { // Connect立即成功极罕见通常发生在localhost // 此时OnConnect会同步触发无需额外处理 } }逻辑说明Connect()返回FALSE不等于失败WSAEWOULDBLOCK10035表示连接正在后台进行必须等待OnConnect()回调。若返回其他错误码如WSAEADDRNOTAVAIL则应立即Close()并报错。本包在OnConnect()中统一处理成败void CClientSocket::OnConnect(int nErrorCode) { if (nErrorCode 0) { // 连接成功可开始Send/Receive AfxGetMainWnd()-PostMessage(WM_CLIENT_CONNECTED, 0, 0); } else { // 连接失败nErrorCode即WSAGetLastError() AfxGetMainWnd()-PostMessage(WM_CLIENT_CONNECT_FAILED, nErrorCode, 0); this-Close(); // 必须Close否则Socket处于无效状态 } }3.2 服务端监听与接受连接Create → Listen → OnAccept// 用户点击“启动服务”按钮 void CMainDlg::OnBnClickedBtnStartServer() { CString strPort; GetDlgItemText(IDC_EDIT_SERVER_PORT, strPort); UINT nPort _ttoi(strPort); if (nPort 0 || nPort 65535) { AfxMessageBox(_T(服务端口必须是1-65535之间的整数)); return; } // 1. 创建监听Socket if (!m_ServerSocket.Create(nPort, SOCK_STREAM, FD_ACCEPT)) { int nErr WSAGetLastError(); AfxMessageBox(_T(监听Socket创建失败错误码) CString(nErr)); return; } // 2. 开始监听 if (!m_ServerSocket.Listen()) { int nErr WSAGetLastError(); AfxMessageBox(_T(Listen失败错误码) CString(nErr)); m_ServerSocket.Close(); return; } // 成功更新UI状态 GetDlgItem(IDC_BTN_START_SERVER)-EnableWindow(FALSE); GetDlgItem(IDC_BTN_STOP_SERVER)-EnableWindow(TRUE); }参数说明CAsyncSocket::Create()的第三个参数nEventType必须指定FD_ACCEPT服务端或FD_CONNECT | FD_RECEIVE | FD_CLOSE客户端。若遗漏对应事件将不会触发OnXXX()。Listen()成功后OnAccept()会在有新连接请求时被自动调用。3.3 数据接收与解析OnReceive中的缓冲区管理与粘包处理void CClientHandler::OnReceive(int nErrorCode) { if (nErrorCode ! 0) { // 网络错误主动关闭 AfxGetMainWnd()-PostMessage(WM_CLIENT_DISCONNECTED, m_nClientID, nErrorCode); this-Close(); return; } // 1. 预分配缓冲区避免频繁new/delete static BYTE s_RecvBuf[4096]; int nBytes this-Receive(s_RecvBuf, sizeof(s_RecvBuf) - 1); if (nBytes 0) { s_RecvBuf[nBytes] \0; // 确保字符串安全 // 2. 粘包处理本包采用“行协议”\r\n分隔 // 将接收到的数据追加到客户端专属缓冲区 EnterCriticalSection(((CMainDlg*)m_pOwnerWnd)-m_CS); CString strBuf ((CMainDlg*)m_pOwnerWnd)-m_ClientBuffers[m_nClientID]; strBuf CString((char*)s_RecvBuf, nBytes); // 3. 提取完整行 int nPos 0; while ((nPos strBuf.Find(_T(\r\n))) ! -1) { CString strLine strBuf.Left(nPos); strBuf strBuf.Mid(nPos 2); // 移除已处理行及\r\n // 4. 向UI发送完整消息 ((CMainDlg*)m_pOwnerWnd)-PostMessage( WM_CLIENT_DATA_RECEIVED, (WPARAM)m_nClientID, (LPARAM)(LPCTSTR)strLine); } LeaveCriticalSection(((CMainDlg*)m_pOwnerWnd)-m_CS); } else if (nBytes 0) { // 对端关闭连接优雅关闭 AfxGetMainWnd()-PostMessage(WM_CLIENT_DISCONNECTED, m_nClientID, 0); this-Close(); } else { // 接收错误 int nErr WSAGetLastError(); if (nErr ! WSAEWOULDBLOCK) // 非阻塞模式下无数据是正常现象 { AfxGetMainWnd()-PostMessage(WM_CLIENT_RECEIVE_ERROR, m_nClientID, nErr); this-Close(); } } }逻辑说明OnReceive()可能一次收到多条消息粘包也可能一条消息分多次到达拆包。本包采用简单有效的“行协议”\r\n分隔在内存中维护每个客户端的接收缓冲区m_ClientBuffers持续追加直到提取出完整行。EnterCriticalSection确保多客户端并发接收时缓冲区操作安全。nBytes 0表示对端调用了shutdown(SD_SEND)或closesocket()是标准的连接关闭信号。4. 常见问题排查五个真实踩坑记录与血泪解决方案开发MFC TCP应用时80%的问题不是逻辑错误而是对MFC Socket生命周期、线程模型、错误码含义的误解。以下是本包实测过程中最典型的五类翻车现场每一条都来自真实调试日志。4.1 现象点击“连接”按钮无反应OnConnect()死活不触发原因CAsyncSocket::Create()失败但代码未检查返回值后续Connect()在m_hSocket INVALID_SOCKET状态下被调用导致静默失败。解决Create()后必须检查m_hSocket ! INVALID_SOCKET并用WSAGetLastError()获取具体错误。常见原因是未调用AfxSocketInit()MFC Socket初始化函数或重复调用WSAStartup()。本包在CWinApp::InitInstance()中已强制调用AfxSocketInit()。4.2 现象服务端OnAccept()被调用但Accept()返回INVALID_SOCKETWSAGetLastError()为10038原因CServerSocket对象在栈上创建如CServerSocket sock;OnAccept()回调时该对象已被析构this指针悬空Accept()操作在无效对象上调用。解决所有CAsyncSocket派生类对象必须动态创建new或作为类成员变量绝不能是局部栈变量。本包中m_ServerSocket是CMainDlg的成员变量生命周期与对话框一致。4.3 现象客户端发送数据后服务端OnReceive()收到乱码或长度异常原因发送方使用CString::GetBuffer()获取指针但未调用ReleaseBuffer()导致CString内部缓冲区状态异常或发送时未指定长度Send(pData, nLength)导致Send()以pData为起点一直发送到内存中第一个\0为止。解决SendData()必须显式传入长度参数并确保pData指向的内存区域在发送期间有效。本包CClientSocket::SendData()内部使用memcpy拷贝到临时缓冲区再发送规避生命周期问题。4.4 现象多客户端连接后某个客户端断开OnClose()未被调用m_ClientList中残留无效指针原因CClientHandler::OnClose()中直接delete this但m_ClientList仍持有该指针后续遍历时访问已释放内存。解决OnClose()中只调用Close()和delete this不在OnClose()中操作m_ClientList。本包在CMainDlg::OnClose()中统一清理列表或在CClientHandler::OnClose()中通过PostMessage通知主窗口移除自身ID。4.5 现象程序退出时崩溃调用堆栈显示在CAsyncSocket::~CAsyncSocket()中访问非法地址原因CAsyncSocket对象析构时其底层m_hSocket可能仍在异步IO中MFC试图取消未完成的操作但句柄已失效。解决必须在析构前显式调用Close()并确保OnClose()回调完成后再delete对象。本包在CMainDlg::OnDestroy()中按顺序调用Close()→等待→delete并通过CRITICAL_SECTION保护清理过程。5. 进阶技巧用Wireshark验证通信行为与自定义协议头解析当你的MFC TCP程序在本地能通但对接硬件设备或第三方服务时失败问题往往出在协议细节——比如对方要求固定长度包头、特定字节序、或心跳保活。此时脱离代码看真实网络包是唯一可信手段。本包附带一套轻量级协议头解析方案配合Wireshark可快速定位差异。5.1 Wireshark抓包配置精准过滤MFC程序流量启动Wireshark后在捕获过滤器Capture Filter中输入tcp and (host 127.0.0.1 or host 你的本机IP)这能排除无关流量。开始捕获后运行你的MFC客户端和服务端执行一次完整连接-发送-接收-关闭流程。停止捕获在显示过滤器Display Filter中输入tcp.stream eq 00是当前会话的流编号可在任意TCP包上右键→Follow→TCP Stream查看此时你将看到完整的ASCII/HEX双向通信记录包括SYN、ACK、FIN握手包以及你发送的明文数据。技巧若发送的是二进制数据如结构体在Follow TCP Stream窗口中切换到Hex Dump视图可逐字节核对协议头字段。例如某设备要求前4字节为0x12345678魔数后2字节为数据长度大端序你可在Wireshark中直接搜索12 34 56 78确认是否发出。5.2 自定义协议头封装在SendData中注入结构化头部#pragma pack(push, 1) // 禁用字节对齐 struct ProtocolHeader { DWORD dwMagic; // 0x12345678 WORD wDataLen; // 实际数据长度不含头 BYTE byCmdType; // 命令类型 BYTE byReserved; // 保留字节 }; #pragma pack(pop) // 修改CClientSocket::SendData以支持协议头 BOOL CClientSocket::SendData(const BYTE* pData, int nLength, BYTE byCmdType) { if (nLength 0 || nLength 65535) return FALSE; // 1. 构造协议头 ProtocolHeader hdr; hdr.dwMagic 0x12345678; hdr.wDataLen htons((WORD)nLength); // 转换为网络字节序大端 hdr.byCmdType byCmdType; hdr.byReserved 0; // 2. 合并头数据到临时缓冲区 std::vectorBYTE sendBuf; sendBuf.insert(sendBuf.end(), (BYTE*)hdr, (BYTE*)hdr sizeof(hdr)); sendBuf.insert(sendBuf.end(), pData, pData nLength); // 3. 发送整块 return CAsyncSocket::Send(sendBuf[0], (int)sendBuf.size()) (int)sendBuf.size(); }参数说明#pragma pack(push, 1)确保结构体按1字节对齐避免编译器插入填充字节导致头长度不一致。htons()将WORD转换为网络字节序大端这是TCP协议栈的标准要求。Send()返回值必须与期望长度比较而非仅判断是否大于0——因为部分数据可能已发送剩余需等待下次OnSend()。5.3 服务端协议头解析在OnReceive中校验并分发void CClientHandler::OnReceive(int nErrorCode) { // ... [省略基础错误检查与缓冲区追加] ... // 粘包处理后strBuf中可能有多条完整消息 // 现在按协议头解析假设头长8字节 while (strBuf.GetLength() 8) { // 1. 提取头前8字节 const BYTE* pBuf (const BYTE*)(LPCTSTR)strBuf; DWORD dwMagic *(DWORD*)pBuf; WORD wDataLen ntohs(*(WORD*)(pBuf 4)); // 转回主机字节序 // 2. 校验魔数与长度 if (dwMagic ! 0x12345678 || wDataLen 4000) // 长度上限防攻击 { // 协议错误丢弃此包从缓冲区移除前8字节 strBuf strBuf.Mid(8); continue; } // 3. 检查完整包是否已到齐 int nTotalLen 8 wDataLen; if (strBuf.GetLength() nTotalLen) { // 数据未收全等待下次OnReceive break; } // 4. 提取完整包头数据 CString strPacket strBuf.Left(nTotalLen); strBuf strBuf.Mid(nTotalLen); // 移除已处理包 // 5. 解析数据部分跳过头8字节 const BYTE* pData (const BYTE*)(LPCTSTR)strPacket 8; ProcessCommand(pData, wDataLen); // 业务逻辑处理 } }关键点协议解析必须在内存缓冲区中进行不能直接对Receive()返回的原始指针操作因为粘包导致数据跨越多次OnReceive()。ntohs()将网络字节序转回主机序是解析二进制协议的必备步骤。ProcessCommand()是纯业务函数与Socket解耦便于单元测试。从那以后我每次调试TCP通信问题第一件事就是打开Wireshark抓包对照协议文档一行行核对字节——而不是在代码里加一百个AfxMessageBox。因为网络层的真相永远在网卡驱动和TCP栈之间不在你的OnReceive()函数里。希望帮到你。本文还有配套的精品资源点击获取