简介基于套接字通信利用MFC类库实现TCP协议的客户端-服务器架构程序是一份适合Windows平台C网络开发者的示例工程面向正在学习MFC网络编程或需要快速搭建TCP通信原型的人员也适用于课程设计与项目起步阶段能够帮助理解CSocket在客户端与服务器端的基本用法。压缩包共4个文件包含2个cpp源文件与2个头文件分别对应客户端连接对话框和服务端监听对话框代码覆盖套接字库初始化、套接字对象创建、绑定、监听、接受、连接、发送、接收及关闭等完整流程。整个包仅6KB结构轻量便于直接阅读和改造。目前已有1261人学习下载说明该示例在同类资源中具有一定参考价值。借助这份代码可清晰看到MFC封装Windows套接字后如何简化网络编程步骤并以此为基础扩展出业务通信模块。1. 基于 socket 通信的 MFC TCP 程序这套 C/S 方案到底解决什么问题MFC TCP Socket 这三个词放在一起很多人第一反应是过时。但真正做 Windows 桌面通信的人心里清楚工控机、老笔记本、不能乱装运行库的目标机器UI 又必须沿用旧对话框时这一套反而是最快能落地的。这个资源是一套完整的 C/S 架构程序服务端通过监听 Socket 接受连接用异步回调方式收发数据客户端用同一套消息模型发起连接、维护心跳。它解决的并不是协议栈本身而是让你在 MFC 界面里不卡线程地把 TCP 通信跑起来。适合两类人要维护老 MFC 项目的在职工程师以及做课程设计但不想从零搭框架的学生。2. MFC 网络选型CAsyncSocket 与 CSocket 选哪个先想清楚再动手动手写代码前最该先定的是网络模型。MFC 下做 TCP 通信路径就那么几条选错了后面全是返工。这里把三套方案的差别摊开讲你就知道为什么这套程序会落在 CAsyncSocket 上。2.1 三套方案对比裸 WinSock、CSocket、CAsyncSocket第一类是直接包 WinSock。WSAStartup、socket、bind、listen、accept、select 全部自己管控制力最强但对话框程序里要把 FD_ACCEPT、FD_READ 这些网络事件投递到窗口代码量会多出不少而且大部分代码和业务无关。如果你只是要在 MFC 对话框里做一个控制台工具裸写 WinSock 的维护成本偏高除非你打算把它改造成跨平台库。第二类是 CSocket。它是 MFC 对阻塞 Socket 的封装调用模型接近 C 语言的 read/writeByte 流收发非常直观。但它的阻塞特性很致命一个 CSocket 在读数据时会卡住当前线程放在 UI 线程里界面直接谈不上响应只能在每个连接上配一个线程去伺候它。线程一多资源消耗和同步问题就来了。第三类就是我在这套程序里用的 CAsyncSocket。它封装了 Windows Socket 的 WSAAsyncSelect 机制把 FD_READ、FD_WRITE、FD_ACCEPT、FD_CLOSE 包装成 OnReceive、OnSend、OnAccept、OnClose 四个回调。Socket 创建在哪个线程回调就分发到哪个线程。对话框里创建的 Socket回调天然跑在 UI 线程可以直接更新编辑框和列表控件省掉自己 PostMessage 的麻烦。一个小项目一个线程就能管住所有客户端连接。方案阻塞特性多客户端处理超时控制适合场景裸 WinSock可阻塞可非阻塞自己管理自己设 SO_RCVTIMEO偏底层、跨平台封装CSocket阻塞一线程一连接按线程阻塞串口式小流量、教学CAsyncSocket非阻塞回调单线程多连接依赖业务计时器MFC 对话框 C/S需要注意CAsyncSocket 不替你解决并发和性能它只是把回调模型简化了。客户端数量不大、单包不超过几 KB 的场景下它的表现足够稳定真正几十万并发的服务端没有人会用 MFC 写这一点先放在心里后面设计代码的时候就不会过度设计。2.2 先定协议再写代码三种数据边界方案很多初学 MFC TCP 的人一上来就收发字符串等两包数据粘在一起才开始查资料。TCP 是字节流没有消息边界所以程序的第一步不是写 Socket是定协议。常见做法有三种定长包、特殊分隔符、长度前缀。定长包适合指令固定不变的设备比如每包固定 64 字节实现最简单但业务字段不固定时带宽浪费严重。特殊分隔符适合文本协议比如用 \r\n 结尾但 body 里出现分隔符要转义处理起来琐碎。长度前缀适合二进制协议也是这套程序采用的方式。协议格式是前两个字节固定魔数 0xAA 0x55后面两个字节是小端序长度长度值表示紧随其后的负载字节数。收到数据后先找魔数确认包头再读长度知道整包在哪结束最后按长度截取负载。魔数的作用是快速发现错位数据长度字段的作用是解决半包粘包。协议定了拆包逻辑才写得干净。注意协议里最好再带一个字节的校验和或 CRC。设备端数据经常出现偶发干扰没有校验会把脏数据当业务数据处理排查时你是看不出来的。2.3 程序骨架四个类、一个对话框、两条关键线程一个典型的 MFC TCP C/S 程序文件不会太多。服务端拆成两类 Socket监听类 CListenSocket 和通信类 CCommSocket客户端单独一个 CTcpClient对话框 CMainDlg 负责承载 UI 和业务。收发数据量不大的时候这些类全部在 UI 线程创建消息回调也都在 UI 线程代码最简单也最容易被新手接受。类 / 模块职责所属线程CListenSocket监听端口接受新连接UI 线程CCommSocket服务端与客户端的数据收发UI 线程CTcpClient客户端连接服务端UI 线程CMainDlg定时器、拆包、业务处理UI 线程CWorkThread大量数据时的解析/入库工作线程如果数据量一大OnReceive 里就不能做解析和入库否则界面还是会卡。常见做法是把字节流原样交给工作线程由工作线程负责拆包和业务处理再通过 PostMessage 回到 UI 线程更新界面。这套程序的核心骨架就是这个结构后面几章的代码都围绕这里展开。3. 服务器端实现监听、接收、拆包、发送队列一块块拆开讲服务端是整个通信链路里风险最集中的一端。监听得对、收得全、拆得开、发得出去才算把 TCP 通信真正跑通。下面按类拆开讲代码可以直接照着建工程验证。3.1 监听类与通信类分开写避免回调里堆业务服务端最容易犯的错误是把所有逻辑都塞进 CAsyncSocket 的派生类。CAsyncSocket 回调只是网络事件的入口不是业务层。CListenSocket 只做一件事监听端口、接受连接。收到 OnAccept 后 new 一个 CCommSocket交给 CMainDlg 登记不在回调里做任何 UI 操作。// ListenSocket.h #pragma once #include afxsock.h class CMainDlg; class CListenSocket : public CAsyncSocket { public: CListenSocket(); virtual ~CListenSocket(); void SetOwner(CMainDlg* pOwner); protected: virtual void OnAccept(int nErrorCode); private: CMainDlg* m_pOwner; };// ListenSocket.cpp void CListenSocket::OnAccept(int nErrorCode) { if (nErrorCode ! 0) { // nErrorCode 是 accept 失败的错误码记录日志后返回即可 return; } // 每个连接独立一个 CCommSocket生命周期超过 OnAccept CCommSocket* pClient new CCommSocket; pClient-SetOwner(m_pOwner); // Accept 会为 pClient 内部创建并绑定一个新的 SOCKET if (!Accept(*pClient)) { delete pClient; return; } // 交给对话框统一保存断线时统一关闭和释放 m_pOwner-OnClientAccepted(pClient); }这段代码有两个关键点。第一pClient 必须 new 出来而不是用栈对象因为 Accept 之后连接还要继续存在OnAccept 一旦返回栈对象就析构了。第二m_pOwner 是一个弱引用只用来把新连接通知到 UI 层Socket 对象本身的清理由对话框负责避免回调里既管网络又管对象释放。3.2 OnReceive 读数据一次回调把缓冲区读干净OnReceive 是网络数据进来的唯一入口。很多人在这里只调一次 Receive拿到一点数据就返回导致高频数据流下程序处理不过来。标准做法是循环读取一直读到 WSAEWOULDBLOCK 为止把所有到达的数据先追加到接收缓冲区。void CCommSocket::OnReceive(int nErrorCode) { if (nErrorCode ! 0) { ShutDown(2); // 禁止收发 Close(); return; } BYTE buf[4096] {0}; int nRead Receive(buf, sizeof(buf)); if (nRead SOCKET_ERROR) { int err GetLastError(); if (err WSAEWOULDBLOCK) { // 内核缓冲暂时没有更多数据系统会在下次数据到达时再回调 return; } Close(); return; } if (nRead 0) { // 对端正常关闭连接 Close(); return; } // 把读到的字节追加到公共接收缓冲区交给上层拆包 m_rxBuffer.Append(buf, nRead); m_pOwner-OnSocketReceive(this, m_rxBuffer); }这里有三个容易理解错的地方。Receive 返回 0 表示对端关闭不是没数据返回 SOCKET_ERROR 时要看 GetLastError只有 WSAEWOULDBLOCK 可以安全返回等下次回调其他错误都要关闭连接局部 buf 每回调一次分配一次是低效但直观的写法性能敏感时改成成员变量即可。3.3 拆包逻辑半包、粘包和错位数据的处理接收缓冲区攒的是原始字节流必须按协议拆出一包一包的完整数据。拆包函数放在 CMainDlg 里统一调用这样 CCommSocket 不用关心业务协议只负责往上送原始数据。void CMainDlg::OnSocketReceive(CCommSocket* pSocket, CByteArray buffer) { const int HEADER_SIZE 4; while (buffer.GetSize() HEADER_SIZE) { BYTE* p buffer.GetData(); // 帧头固定 0xAA 0x55用于识别数据起点 if (p[0] ! 0xAA || p[1] ! 0x55) { // 数据错位时逐字节后移重新找帧头 buffer.RemoveAt(0); continue; } // 长度字段为小端序低字节在前高字节在后 int nPayloadLen p[2] | (p[3] 8); int nTotal HEADER_SIZE nPayloadLen; if (buffer.GetSize() nTotal) { // 这属于半包字节还没收齐等下一次 OnReceive 再拼 return; } // 截取完整负载交给业务处理函数 std::vectorBYTE payload(p HEADER_SIZE, p nTotal); OnBusinessPacket(pSocket, payload); // 移出已处理完的整包 buffer.RemoveAt(0, nTotal); } }这段逻辑把 TCP 的三种坑都覆盖了。粘包时 while 循环连续拆出多包半包时 buffer 长度不够直接 return 等下轮拼接错位时通过魔数逐字找到真正的包头。参数上注意小端序的拼法和 p[3] 8 的优先级括号不能省。3.4 发送队列处理 WSAEWOULDBLOCK 和部分发送服务端往外发数据同样不能直接裸调 Send。对方接收窗口一旦满了Send 会返回 WSAEWOULDBLOCK如果你忽略它继续发送数据就悄悄丢了。标准解法是给每个 CCommSocket 挂一个发送队列Send 失败就把数据暂存等 OnSend 回调再继续发。void CCommSocket::FireSend() { // FireSend 用于主动触发一次发送尝试 if (m_hSocket ! INVALID_SOCKET) { OnSend(0); } } void CCommSocket::OnSend(int nErrorCode) { if (nErrorCode ! 0) { return; } // 发送队列中还有数据就继续发发完即止 while (m_sendQueue.GetSize() 0) { int nSent Send(m_sendQueue.GetData(), m_sendQueue.GetSize()); if (nSent SOCKET_ERROR) { if (GetLastError() WSAEWOULDBLOCK) { // 窗口满了停下来等下一次 OnSend 通知 break; } Close(); break; } if (nSent 0) { break; } // 已发出的部分从队列头部移除 m_sendQueue.RemoveAt(0, nSent); } }主动发送时先在业务层把数据 Append 到 m_sendQueue再调一次 FireSend 尝试如果发不出去数据留在队列系统会在可写时回调 OnSend。这套机制保证字节顺序不被打乱也不会因为窗口阻塞而丢包。参数上只有一个 nSent它代表本次实际写入内核缓冲的字节数可能小于你传入的长度所以队列移除必须按 nSent 而不是整包。4. 客户端实现连接、心跳、自动重连如何优雅地维持一条 TCP 链路客户端的难点不在收发在状态管理。连不上要重试连上了要保持断了要能自动找回。下面这四小节基本覆盖了一个稳定客户端该有的全部状态。4.1 客户端也只用一个派生类客户端不需要拆监听和通信两个类一个 CTcpClient 从 CAsyncSocket 派生就够。它内部维护三个状态正在连接、已连接、等待重连。业务层通过一个枚举或者布尔变量感知状态变化。class CTcpClient : public CAsyncSocket { public: void SetOwner(CMainDlg* pOwner); void ConnectToServer(const CString strHost, UINT nPort); BOOL IsConnected() const { return m_bConnected; } protected: virtual void OnConnect(int nErrorCode); virtual void OnReceive(int nErrorCode); virtual void OnClose(int nErrorCode); private: CMainDlg* m_pOwner; BOOL m_bConnecting; // 正在连接中防止重复 Connect BOOL m_bConnected; // 当前链路是否可用 };状态放成员变量里定时器和回调共同访问时要注意同步。MFC 默认单线程事件分发只要 socket 在 UI 线程创建回调就不会和工作线程抢数据可以放心读这两个标志位。4.2 非阻塞 Connect 与 OnConnect 错误码客户端的 Connect 在非阻塞模式下返回值不能直接当结果判断。连接发起后系统在后台完成三次握手成功与否通过 OnConnect 通知。void CTcpClient::ConnectToServer(const CString strHost, UINT nPort) { if (m_hSocket ! INVALID_SOCKET) { // 已有 socket 未释放先 Close 再重新创建 Close(); } if (!Create()) { // 创建失败GetLastError() 可拿到 SOCKET_ERROR 原因 return; } m_bConnecting TRUE; BOOL bOk Connect(strHost, nPort); if (!bOk) { int err GetLastError(); if (err ! WSAEWOULDBLOCK) { // 只有 WSAEWOULDBLOCK 表示连接正在进行 m_bConnecting FALSE; Close(); } } }这里最关键的判断是Connect 返回 FALSE 且错误码是 WSAEWOULDBLOCK不是连接失败而是“连接正在建立”。很多新手在这里直接关 socket导致永远连不上。OnConnect 中拿到的 nErrorCode0 表示成功非 0 对应 Winsock 错误码。void CTcpClient::OnConnect(int nErrorCode) { m_bConnecting FALSE; if (nErrorCode 0) { m_bConnected TRUE; m_pOwner-OnConnected(); return; } m_bConnected FALSE; switch (nErrorCode) { case WSAETIMEDOUT: // 对端不可达常见原因是防火墙拦截或网段不通 break; case WSAECONNREFUSED: // 端口没在听或服务端 backlog 已满 break; default: // 其他错误统一走重连策略 break; } m_pOwner-OnConnectFailed(nErrorCode); }WSAECONNREFUSED 对应 10061WSAETIMEDOUT 对应 10060这两个是现场出现最多的连接错误码。记录下来后面排查少走弯路。4.3 心跳包设计定时器加超时计数TCP 链路建立后谁都无法保证链路永远可用。运营商 NAT 空闲连接、服务端半开连接都可能让通信“看起来正常实际已死”。解决方式是在应用层加心跳。void CMainDlg::OnTimer(UINT_PTR nIDEvent) { if (nIDEvent TIMER_HEARTBEAT) { if (m_client.IsConnected()) { // 心跳包也走自定义协议0xAA 0x55 长度 4 内容 PING BYTE ping[8] {0xAA, 0x55, 0x00, 0x04, P, I, N, G}; m_client.Send(ping, sizeof(ping)); // 连续多次未收到任何数据判定链路已死 m_nHeartbeatTimeout; if (m_nHeartbeatTimeout 3) { m_nHeartbeatTimeout 0; m_client.ShutDown(2); m_client.Close(); m_bNeedReconnect TRUE; } } } else if (nIDEvent TIMER_RECONNECT) { if (m_bNeedReconnect !m_bConnecting) { m_bNeedReconnect FALSE; m_client.ConnectToServer(m_strServer, m_nPort); } } CDialogEx::OnTimer(nIDEvent); }心跳周期按业务实时性定一般 3 到 10 秒发一次。收到任何服务端数据时把 m_nHeartbeatTimeout 清零即可不必单独回 PONG 包。这比“发心跳、等响应”省一半逻辑也足够判断链路活性。4.4 重连策略防止重复 Connect 和回调撞车自动重连最容易翻车的点是重入。定时器还没触发用户又点了连接按钮或者 OnClose 之后立刻重连而旧 socket 还没清干净都会造成重复 Connect。解决方式是在 ConnectToServer 入口检查 m_hSocket 和 m_bConnecting。m_bConnecting 为 TRUE 时直接忽略新的连接请求OnConnect 回调无论成败都把它复位。重连定时器只做“发起方”不做“判断方”状态判断全部集中在状态机里。重连间隔建议用递增退避第一次 1 秒第二次 2 秒最多 10 秒避免服务端一重启就把客户端请求全冲垮。5. 避坑MFC TCP 开发里最容易翻车的五个问题这块内容是整套程序里最值钱的部分。每个问题我都按现象、原因、解决三部分写对照你自己的现象就能定位。5.1 界面卡死Connect 或 Receive 阻塞了 UI 线程现象程序一启动点连接按钮窗口立刻无响应拖动标题栏都卡杀掉进程才好。或者在收发数据过程中界面间歇性白屏。原因CSocket 的 Connect 和 Receive 都是阻塞调用。把它们放在按钮点击的响应函数里UI 线程就被挂住了。数据量大时即使偶尔不卡用户也会觉得程序“像死了一样”。解决改用 CAsyncSocket所有网络操作都走回调。如果业务上绕不开阻塞模型就把 CSocket 丢到 AfxBeginThread 创建的工作线程里通过 PostMessage 把结果传回 UI。我遇到这种问题基本不修直接替换方案。5.2 粘包半包屏幕上数据对不上现象两个设备同时上报数据服务端收到的字符串黏在一起或者一条完整指令被截成两半解析出来的内容错位。原因TCP 是字节流接收方拿到的是内核缓冲区的连续字节不是应用层消息。没有协议边界就无法区分“这是一个完整包”还是“半个包”。解决严格按第 3 章的拆包逻辑做固定魔数加长度字段缓冲区内循环拆包。每次 OnReceive 都把数据追加进 CByteArray不要收到一段处理一段。5.3 OnReceive 不触发或收到的数据不完整现象客户端确实发了数据服务端 OnReceive 一次也没进或者偶尔进一次数据短一截。用抓包工具能看到数据确实到了网卡。原因CAsyncSocket 的消息分发依赖创建它的线程的消息泵。如果 socket 是在 AfxBeginThread 创建的而那个工作线程没有消息循环FD_READ 事件就一直排在队列里回调节点迟迟不来。解决确保 socket 创建在具备消息泵的线程。MFC 对话框线程自带消息循环所以最简单的方式是让所有 socket 都在 UI 线程创建。如果必须用工作线程在线程函数里加一个 PeekMessage 循环保证消息分发。5.4 退出程序崩溃Socket 析构顺序与重复 Close现象关闭程序时崩溃或者报“Debug Assertion Failed”定位到 CAsyncSocket 的析构函数里。原因OnClose 回调里 Close 了一次外部 CMainDlg 销毁时又 Close 并 delete 一次重复释放句柄导致断言失败。另外new 出来的 CCommSocket 如果用完不 delete关闭程序时会先析构 UI 再析构 socket调用顺序错乱。解决统一由 CMainDlg 负责删除 socket 对象。约定“连接失败或断开后socket 对象进入待删除列表UI 空闲时统一 delete”。析构函数里只判断句柄是否有效再 Close不要和 OnClose 形成互相调用。5.5 长时间运行后掉线保活和防火墙双重夹击现象程序跑一晚上第二天过来链路已经断了重连也连不上必须重启程序才恢复。原因很多路由器或系统防火墙会回收空闲 TCP 连接。如果应用层长时间没有数据交互链路在内核层面已经被静默释放而客户端不知道还在傻等。解决应用层心跳是必备的同时可以设置 TCP keepalive。Windows 上通过 setsockopt 开启 SO_KEEPALIVE并调整 keepalive 时间为一个较短周期。更可靠的做法是心跳超时后主动 Close 连接让重连逻辑走一遍而不是抱着旧 socket 不放。6. 进阶用法协议日志、小压测工具与上线前验证这套程序跑通只是第一步真正敢把通信模块交到生产环境还要补三块验证能力。6.1 给收发数据加一层二进制日志在 CMainDlg 的 OnSocketReceive 和 FireSend 里各加一个日志回调按十六进制把每个方向的数据写进文件。这样出问题时可以回放协议流而不是靠猜。日志文件按天滚动记录时间戳、方向、socket 句柄和长度。相信我一次线上数据对不上的问题能靠日志一小时定位没有日志可能耗一整天。6.2 写一个最小压测客户端压测不复杂循环发包加统计就行。一个定时器每 10 毫秒按协议格式发一包负载数据另一个计数器统计服务端回包数量。重点关注两个值单包吞吐量和累计 5 分钟的丢包率。如果压测 5 分钟出现一次 WSAEWOULDBLOCK 且发送队列持续增长就要检查协议设计或者系统 Socket 缓冲配置了。6.3 上线前验证清单验证项验证方法预期结果端口监听命令行执行 netstat -an服务端 LISTENING 状态基础连接客户端连服务端OnConnect 回调 nErrorCode 为 0粘包场景连续发送 1000 包不等间隔服务端拆包计数等于 1000半包场景发送一包拆成两次 Send服务端只上报一次完整业务包断线恢复服务端强杀进程客户端 10 秒内重连成功这一套验证走完通信模块才有底气交给别人用。从那以后我每次新接一个带网络通信的任务都强制先写协议日志、再写业务代码最后压一遍心跳场景。希望帮到你。本文还有配套的精品资源点击获取