简介基于 VS2010 的 MFC Socket 编程示例压缩包包含 SocketTest_Client 与 SocketTest_Server 两个完整工程面向学习 Windows 网络编程的初学者以及需要快速搭建客户端/服务器通信框架的开发者。压缩包共 48 个文件以 h/cpp 源码文件为主13 个头文件、9 个 C 源文件另含解决方案、项目配置、资源脚本、日志与调试缓存等整体大小约 59.89MB。目前已有 535 人学习/下载该资源。示例覆盖 Winsock 初始化、socket 创建、bind/listen/accept/connect 以及 send/recv 数据交换的完整流程并展示了 CServerApp 与 CClientApp 的类设计代码注释清晰、目录结构直观便于对照理解服务器端监听与客户端连接的全过程也可作为后续扩展多线程或异步 Socket 的基础模板。1. 为什么我用 VS2010 MFC 写 Socket 通信从学习到落地的最后一公里做 MFC 界面开发遇到 Socket 通信需求十个人里有八个会先想到用 CAsyncSocket 或者更底层的 Winsock API 去封装但真到自己动手写一个能跑的客户端 服务器端程序时坑远比想象中多。这份基于 VS2010 环境的 MFC Socket 编程资源核心价值在于把「客户端 服务器端」完整打通服务器端监听、多客户端接入、数据收发、界面线程刷新每一步都有可以直接抄的代码结构。适合刚学完 C 语法、想用 MFC 做毕业设计或企业内部小工具的开发者你不需要重新发明轮子只需要照着这套框架把业务逻辑填进去。我拆完这份资源后最大的感受是它解决的并不是「能不能连通」的问题而是「连上之后怎么稳定跑、崩了怎么查」的问题。2. MFC 里选 Socket 模型先看 CAsyncSocket、CSocket 和阻塞 Winsock 的边界在哪2.1 为什么这份资源选了 CAsyncSocket 而不是 CSocketMFC 编程里 Socket 封装有三条常见路线直接用 WinSock API、用 CAsyncSocket 派生类、用 CSocket 派生类。这份资源选择的是 CAsyncSocket 这一层而不是更上层的 CSocket原因很实际CSocket 虽然把阻塞模式封装得更省心但它内部依赖窗口消息机制在 VS2010 默认的 MFC 工程里如果主线程被界面操作卡住CSocket 的阻塞调用会把整个消息循环堵死。CAsyncSocket 是非阻塞的它把 Socket 事件映射到窗口消息比如 FD_READ、FD_WRITE、FD_ACCEPT通过重载 OnReceive、OnSend、OnAccept 这些虚函数来触发业务逻辑。这套机制的好处是当服务器端 accept 了一个新连接OnAccept 会被自动调用你不需要自己开一个线程去死循环等 connect。坏处是你一旦在 OnReceive 里处理数据的时间过长后续的消息会被延迟界面照样会卡。所以资源里给出的做法是CAsyncSocket 只管收发触发真正的数据解析放在工作线程或者用 PostMessage 丢给主线程。2.2 客户端和服务器端的类结构划分服务器端需要两个类一个是监听类继承 CAsyncSocket重载 OnAccept另一个是连接类同样继承 CAsyncSocket负责具体某个客户端连接的数据收发。客户端只需要一个类继承 CAsyncSocket重载 OnReceive 和 OnConnect。我用表格把这份资源里的类职责梳理一下方便你对照自己的工程类角色基类需要重载的关键函数职责边界监听类CAsyncSocketOnAccept只负责 accept不管收发连接类服务器端CAsyncSocketOnReceive、OnClose服务某个客户端保存该连接的 socket 句柄客户端类CAsyncSocketOnConnect、OnReceive主动发起连接接收服务器数据一个容易被忽略的设计点服务器端每次 OnAccept 之后要 new 一个连接类对象出来这个对象的指针要保存在一个数组或者列表里用于后续广播数据。删除时机也很关键OnClose 触发时不能马上 delete因为消息循环里可能还有针对这个 socket 的后续消息我一般习惯用一个标记先挂起等 PostMessage 到主线程之后统一清理。2.3 端口、地址和协议参数的设置资源里的服务器端初始化代码大致是// 服务器端监听初始化 BOOL CMyServerDlg::InitSocket() { // 创建监听套接字 if (!m_listenSocket.Create(9527, SOCK_STREAM, FD_ACCEPT)) { AfxMessageBox(_T(创建监听套接字失败)); return FALSE; } // 开始监听 if (!m_listenSocket.Listen(5)) { AfxMessageBox(_T(监听失败)); return FALSE; } return TRUE; }这里 Create 函数的三个参数分别是端口号、Socket 类型、触发的事件掩码。端口号选 9527 只是为了演示实际项目里要避开 0 到 1024 的知名端口也要避开常用的 8080、3306 这类已经被占用的端口。SOCK_STREAM 表示 TCP 流式套接字如果你要做 UDP 就换成 SOCK_DGRAM但要注意 CAsyncSocket 对 UDP 的 ReceiveFrom 和 SendTo 处理方式不一样这份资源只覆盖了 TCP 场景。Listen(5) 里面的 5 是 backlog也就是内核允许的最大挂起连接数。这个数不是越大越好如果业务上同时连接的客户端不会超过三个设 5 就足够了设太大反而会占用内核内存。客户端那边的 Create 不需要指定端口因为客户端端口是系统动态分配的你只需要用 Connect 去连接服务器的 IP 和端口。3. 从零搭建一个可通信的对话框程序服务器端与客户端的具体实现3.1 服务器端对话框工程的创建与控件布局用 VS2010 新建一个基于对话框的 MFC 工程工程名可以取某通信测试工具。资源里给了一个很标准的主界面布局左上角是本地 IP 和端口号的显示框中间是连接日志的列表控件底部是一个消息发送框和发送按钮右侧是可连接客户端列表。控件不需要多华丽关键是逻辑划分清楚。你需要给工程添加两个新类一个是监听类一个是连接类。监听类的头文件里核心代码// 监听类头文件核心部分 class CListenSocket : public CAsyncSocket { public: CListenSocket(); virtual ~CListenSocket(); virtual void OnAccept(int nErrorCode); // 重载接受连接事件 };连接类的头文件则需要保存一个指向主对话框的指针因为 OnReceive 触发后要把数据送回界面线程显示。这里有个关键点CAsyncSocket 的回调是在界面线程的消息循环里触发的所以直接通过主对话框指针操作控件是合法的不需要跨线程保护。但如果你的业务逻辑里有耗时解析依然要小心界面卡顿。3.2 服务器端核心事件处理OnAccept、OnReceive 和 OnCloseOnAccept 的实现逻辑是每有一个客户端连上来就 new 一个连接对象然后调用它的 Accept 函数。代码长这样// 监听类 OnAccept 实现 void CListenSocket::OnAccept(int nErrorCode) { CString strMsg; // 通过主对话框指针访问界面 CMyServerDlg* pDlg (CMyServerDlg*)AfxGetMainWnd(); // 创建新的连接对象 CConnectSocket* pSocket new CConnectSocket(pDlg); if (pSocket-Accept(*this)) { // 把新连接加入列表 pDlg-m_connList.AddTail(pSocket); strMsg.Format(_T(客户端接入当前连接数: %d), pDlg-m_connList.GetCount()); pDlg-ShowMsg(strMsg); } else { delete pSocket; strMsg _T(Accept 失败); pDlg-ShowMsg(strMsg); } CAsyncSocket::OnAccept(nErrorCode); }这段代码有一个很隐蔽的坑Accept 失败的时候 delete 掉 pSocket但如果失败的原因只是暂时性的资源不足这种做法会导致后续无法重试。我一般会改成先保留对象等 OnClose 或者下一次 OnAccept 时再判断。另外m_connList 用的是 MFC 的 CList它在界面线程里操作是安全的但如果你后续要把连接列表传给工作线程做数据广播需要先快照出所有 socket 句柄再传给线程函数绝不能直接在线程里遍历 CList。OnReceive 是数据接收的核心实现如下// 连接类 OnReceive 实现 void CConnectSocket::OnReceive(int nErrorCode) { char buffer[4096] { 0 }; int nLen Receive(buffer, 4096, 0); if (nLen 0) { CString strData; CString strIP; UINT nPort 0; // 获取对端 IP 和端口 GetPeerName(strIP, nPort); strData.Format(_T([%s:%d] %s), strIP, nPort, CString(buffer, nLen)); // 回调主对话框显示 m_pDlg-ShowMsg(strData); } else if (nLen 0) { // 对端正常关闭 delete this; return; } else { // 出错情况 delete this; return; } CAsyncSocket::OnReceive(nErrorCode); }Receive 的返回值有几种情况大于 0 表示收到数据等于 0 表示对端关闭了连接小于 0 表示网络出错。很多人容易忽略 nLen 等于 0 的场景认为只有出错才需要关闭 socket实际上 TCP 的半关闭状态如果不处理服务器端会一直持有无效连接。另外接受数据用的 buffer 最好用栈上数组如果你用 new 分配堆内存要记得在函数尾部 delete否则三次 OnReceive 之后内存就泄漏了。pDlg 指针在 OnReceive 里使用有一个隐患如果用户关闭了主对话框但 CAsyncSocket 对象还存在pDlg 就变成野指针。标准做法是重载主对话框的 OnDestroy主动关闭所有 socket 并清空列表这样回调不会再触发。3.3 客户端连接与数据发送实现客户端核心就是 Connect 和 Send。Connect 的调用方式不是阻塞的你调用 Connect 之后要等 OnConnect 回调确认成功或失败不能立刻判断连接结果。资源里的实现是// 客户端发起连接 void CMyClientDlg::OnBtnConnect() { CString strServer; UINT nPort 0; // 从界面编辑框取值 GetDlgItemText(IDC_EDIT_SERVER, strServer); nPort GetDlgItemInt(IDC_EDIT_PORT); // 创建客户端 socket m_clientSocket.Create(); // 发起连接 BOOL bRet m_clientSocket.Connect(strServer, nPort); if (!bRet GetLastError() ! WSAEWOULDBLOCK) { AfxMessageBox(_T(连接失败)); m_clientSocket.Close(); } }这里最关键的是 GetLastError() 的检查。因为 CAsyncSocket 是非阻塞模式Connect 调用后如果没有立即成功会返回 FALSE 并设置错误码为 WSAEWOULDBLOCK这不算真正的失败而是代表连接正在建立中真正的连接结果会通过 OnConnect 回调通知你。很多初学者把 bRet 为 FALSE 当成连接失败直接弹错误框就是没有处理这个假失败场景。数据发送相对简单// 客户端发送数据 void CMyClientDlg::OnBtnSend() { CString strMsg; GetDlgItemText(IDC_EDIT_SEND, strMsg); // 发送数据 int nLen m_clientSocket.Send(strMsg, strMsg.GetLength(), 0); if (nLen SOCKET_ERROR) { AfxMessageBox(_T(发送失败)); } }要注意 Send 的返回值并不一定等于你传入的字节数TCP 下如果发送缓冲区暂时满了Send 可能只发送一部分数据。这时候需要你把剩余的数据缓存起来等待下一次 FD_WRITE 消息触发时继续发送。这份资源里没有做这种断点续传处理因为示例场景的数据量很小但你在做文件传输时一定要考虑到这个边界。4. 连接管理、数据粘包处理与界面刷新策略4.1 未处理的消息链为什么 OnClose 里不能 delete this服务器端 OnClose 触发时机是对端关闭连接或者网络异常导致连接断开。很多人在 OnClose 里直接 delete this随后程序崩溃或者闪现随机错误原因在于 CAsyncSocket 内部的消息机制还没清理完。OnClose 触发之后socket 句柄可能还在消息队列里挂着 FD_CLOSE 消息你 delete 了对象之后消息循环再访问这个对象就成野指针了。我习惯的解决方式是不在 OnClose 里直接删除对象而是把要删除的 socket 指针 PostMessage 给主对话框让主对话框在 OnCustomMessage 里统一删除。这样把销毁动作延迟到消息循环的安全点。同时要从 CList 里把这个节点移除避免遍历时访问到已释放的指针。4.2 TCP 粘包问题的三种处理策略用 CAsyncSocket 的 OnReceive 接收数据时同一个回调里拿到的数据不一定对应应用层的一条完整消息这就是粘包。资源里的演示代码直接按字节流显示这在调试阶段没问题但如果你要传结构化数据就必须做分包。常见做法是自定义帧格式比如每条消息的开头 4 字节存消息长度后面是消息内容。接收端先收够 4 字节长度再根据长度收完整的数据体用循环接收来拼帧。另一种策略是用分隔符比如以换行符或者特殊字符结尾收到分隔符才认为一条消息完整。这种方法适合行文本协议简单但不适合二进制数据。第三种是定长消息协议每条消息都固定大小接收端只按固定长度截取。资源里没有给专门的封包类结构这算一个留白你需要根据业务场景补一个收包缓冲区类。4.3 界面刷新的线程安全PostMessage 是万金油虽然监听类和连接类的回调都在界面线程但如果你在 OnReceive 里做了解析工作或者你自己额外开了工作线程去算数据再回主界面刷新就必须用 PostMessage。直接在工作线程里操作控件会触发断言或者随机崩溃。我在这份资源的基线上改了一版把所有界面更新统一收敛到一个自定义消息处理函数里#define WM_UPDATE_MSG (WM_USER 100) // 在对话框头文件中声明消息处理函数 afx_msg LRESULT OnUpdateMsg(WPARAM wParam, LPARAM lParam);然后在消息映射表里加入 ON_MESSAGE(WM_UPDATE_MSG, OnUpdateMsg)工作线程通过 PostMessage 把字符串指针传进来主线程在 OnUpdateMsg 里做 setWindowText 或者 list control 插入。这里有一个内存管理细节传给 PostMessage 的字符串指针必须是 new 出来的否则工作线程的局部变量在函数返回后就被释放了主线程收到的是一个悬空指针。4.4 一个完整的收包缓冲区实现为了应对粘包我写了一个简单的 CBuffer 类补丁你可以直接嵌到资源代码里// 收包缓冲区基类 class CRecvBuffer { public: CRecvBuffer() : m_nDataLen(0) {} // 往缓冲区追加原始数据 void AppendData(const char* pData, int nLen) { memcpy(m_buffer m_nDataLen, pData, nLen); m_nDataLen nLen; } // 尝试从缓冲区取出一条完整消息 // 帧格式: 前4字节为小端长度, 后跟消息体 BOOL GetPacket(CString strPacket) { if (m_nDataLen 4) return FALSE; int nBodyLen 0; memcpy(nBodyLen, m_buffer, 4); if (nBodyLen 0 || nBodyLen MAX_PACKET_SIZE) { // 长度非法清空缓冲区 m_nDataLen 0; return FALSE; } if (m_nDataLen 4 nBodyLen) return FALSE; // 数据不完整继续等待 // 取出完整的消息内容 strPacket CString(m_buffer 4, nBodyLen); // 把剩余数据移到缓冲区头部 int nRemain m_nDataLen - 4 - nBodyLen; memmove(m_buffer, m_buffer 4 nBodyLen, nRemain); m_nDataLen nRemain; return TRUE; } private: char m_buffer[MAX_PACKET_SIZE 4]; // 预留长度字段空间 int m_nDataLen; };这个缓冲区的设计逻辑是每次 OnReceive 拿到原始数据后先 AppendData然后循环调用 GetPacket直到返回 FALSE 才停止。长度字段非法的场景一定要清空缓冲区否则恶意客户端发一个超大长度字段你的服务器端会因为等待永远收不满的数据而把内存耗尽。这一条对做内网工具而言尤为重要因为内网环境里偶尔也会有错误进程往你的端口发垃圾数据。5. 避坑与排查四个反复踩的 Socket 编程问题5.1 程序启动监听失败提示端口被占用现象服务器端执行 Create 和 Listen 之后返回失败界面上没有任何提示调试器输出窗口显示错误码。原因上一次关闭程序时 socket 没有正确 Close或者另一个进程占用了同一个端口。TCP 的连接还有一个 TIME_WAIT 状态主动关闭连接的一端会保留端口一段时间导致相同端口被重复绑定时失败。解决在 Create 之前调用 SetSockOpt 设置 SO_REUSEADDR或者干脆在创建时加上这个选项。在 MFC 里可以这样操作// 设置端口重用防止 TIME_WAIT 绑定失败 BOOL bReuse TRUE; m_listenSocket.SetSockOpt(SO_REUSEADDR, bReuse, sizeof(BOOL)); m_listenSocket.Create(9527, SOCK_STREAM, FD_ACCEPT);注意 SetSockOpt 必须在 Create 之前调用因为 Create 底层是 bind 操作bind 完成之后选项就失效了。5.2 服务器端 OnReceive 收到的数据是乱码现象客户端发送中文字符串服务器端显示出来是乱码英文字符正常。原因MFC 工程中字符串可能是宽字符集也可能是多字节字符集。客户端用 CString 发送时如果工程配置是 UnicodeCString 内部是 UTF-16直接发送的是宽字节数据服务器端如果用窄字节解析就会乱码。解决统一收发编码。我建议双方都把要发送的内容用 UTF-8 编码后再发送。发送端这样处理// 使用 UTF-8 发送避免中文乱码 int nLen WideCharToMultiByte(CP_UTF8, 0, strMsg, strMsg.GetLength(), sendBuffer, sizeof(sendBuffer), NULL, NULL); m_clientSocket.Send(sendBuffer, nLen, 0);接收端也相应用 MultiByteToWideChar 把 UTF-8 转回 CString。这份资源里的代码没有做编码转换因为它在英文环境下跑没问题但你的实际项目里只要涉及中文就必须把编码问题一次性处理掉。5.3 界面卡死移动窗口时程序无响应现象服务器端和客户端能连通但发送数据频繁之后拖动窗口非常卡顿有时候直接卡死。原因OnReceive 回调里做了大量计算或者把 CAsyncSocket 的 Receive 返回的数据直接送到 ListBox 控件控件刷新频率太高导致消息队列被占满。解决把数据处理逻辑拆到工作线程或者对界面刷新做节流例如限制一秒内最多刷新 10 次。资源里给的是直接把数据显示在编辑框和列表控件里这种实现只适合低频率测试高频率收发时一定要改成节流刷新。5.4 服务器端同时只处理了一个客户端第二个客户端连不上现象第一个客户端正常通信第二个客户端 Connect 一直没有回调重开。原因OnAccept 里 new 出来的连接对象指针丢失旧连接没有正确处理 OnClose导致新连接虽然被 accept但无法正常进入回调。解决第一步确认 OnAccept 确实被触发在函数入口加断点或者输出日志。第二步检查新连接对象是否成功加入 m_connList。第三步确认旧连接 OnClose 时已经异排除了对象并且从链表中删除了节点。如果链表里堆积了无效对象新连接能建立但旧的占用了大量 GDI 资源系统会逐渐变慢。6. 给这套代码加上心跳检测与自动重连机制通信程序最怕的不是收发错数据而是连接死了两边都还不知道。TCP 虽然有心跳包机制但系统默认的 TCP KeepAlive 时间太长通常是两个小时根本不适合短连接的实时场景。我在这份资源的基础上补了一个应用层心跳客户端每隔一定时间发送一个特定格式的包服务器端收到后回复确认心跳如果服务器端连续多次没收到客户端心跳就判定该连接失效并主动关闭。心跳检测的线程结构我一般放在一个独立的工作线程里// 心跳检测线程入口 UINT HeartbeatThread(LPVOID pParam) { CMyServerDlg* pDlg (CMyServerDlg*)pParam; while (!pDlg-m_bExitFlag) { Sleep(3000); // 每3秒检查一次 // 遍历客户端连接 POSITION pos pDlg-m_connList.GetHeadPosition(); while (pos ! NULL) { CConnectSocket* pConn pDlg-m_connList.GetNext(pos); // 检查最后心跳时间 if (pConn-m_nLastHeartBeat HEARTBEAT_TIMEOUT GetTickCount()) { pConn-Close(); // 标记待移除 pConn-m_bDeleted TRUE; } } } return 0; }之所以要添加心跳是因为很多公司内网的交换机与防火墙会把长时间没有数据流动的 TCP 连接给静默回收掉连接双方等下一次 Send 时才发现发送失败。有了心跳机制这种问题可以在几十秒内被探测到。关于心跳包和业务包的分离最好把包类型放在长度字段之后这样接收端在解析完长度后还能再读 1 字节判断是业务消息还是心跳消息。还有自动重连的逻辑常见做法是客户端侧每 5 秒重试一次连接直到连上或用户手动取消。需要特别注意的是重连成功后要重新初始化序列号或者状态变量否则可能出现上次连接的遗留状态影响新连接。我一般会在 Connect 成功回调里做一次完整的界面刷新和状态清零。运行时验证这套代码除了用资源自带的客户端和服务器端互连之外我还有一个习惯是用命令行工具做简单的压力发包检查服务器端的 CPU 和内存占用变化。如果不方便安装外部工具直接在客户端循环发送一万次小数据包观察服务器端列表控件刷新的流畅度就能大致判断收包缓冲区的效率。从那以后我每次拿到新的通信框架都会强制自己先写一个心跳检测再加上收包缓冲区再往里面填业务逻辑这个顺序绕开能避开一多半的隐性问题。希望帮到你。本文还有配套的精品资源点击获取