簡介這份壓縮包面向Windows平臺網(wǎng)絡編程入門與進階學習者圍繞基于Socket的TCP通信用MFC搭建客戶端/服務器C/S架構示例幫助理解連接建立、數(shù)據(jù)收發(fā)與連接關閉的完整流程適合課程實驗、自學練習和項目原型參考。包內共4個文件以2個cpp源文件和2個h頭文件組成整體約6KB體量輕便便于直接對照閱讀與二次練習。已有1264人學習下載說明其在MFC網(wǎng)絡編程練習場景中具有一定參考價值。代碼圍繞CSocket對象的使用展開覆蓋Winsock初始化、服務器綁定監(jiān)聽與接受連接、客戶端連接服務器以及Send/Receive收發(fā)數(shù)據(jù)和Close釋放資源等關鍵環(huán)節(jié)能夠幫助讀者把抽象協(xié)議概念落到具體調用上。讀者可借此梳理MFC對Winsock的封裝方式理解客戶端與服務器對話框類的職責劃分并在此基礎上調試、擴展自己的TCP通信程序。1. 從一次“連不上”的調試說起這套 MFC TCP 程序到底解決什么問題把 MFC、TCP、Socket 三個詞湊進同一個工程真正卡人的往往不是 API 名字記不住而是 MFC 的消息循環(huán)、線程模型和窗口生命周期怎么跟網(wǎng)絡收發(fā)共存。這套 C/S 架構程序把服務端監(jiān)聽、客戶端連接、消息收發(fā)、日志顯示拆成幾個職責清晰的類用 CAsyncSocket 的異步事件模型驅動收發(fā)適合做局域網(wǎng)聊天、設備指令下發(fā)、上位機通信這類小體量工具的原型也適合剛接觸網(wǎng)絡編程、想看清一次連接從建立到斷開完整鏈路的開發(fā)者。它不追求高并發(fā)指標追求的是結構清楚、每一步都能打斷點看明白。2. 工程結構與選型先定 CAsyncSocket 和 CSocket 的邊界動手寫代碼之前工程怎么切分、用哪套 socket 封裝比后面寫多少行都關鍵。很多人一上來就把CAsyncSocket塞進對話框類里結果一個OnReceive里既有界面刷新又有協(xié)議解析改到第三個功能就再也理不清了。2.1 一份可以直接編譯的雙工程目錄這個項目按“共享協(xié)議 服務端 客戶端”三塊切Common放兩端都要用的頭文件Server和Client各是一個獨立的 MFC 對話框工程編出來的兩個 exe 可以分別跑在兩臺機器上也可以在同一臺機器上開兩個實例自測。MfcTcpCS/ ├── Common/ │ ├── Protocol.h // 包頭結構、消息類型枚舉、字節(jié)序轉換 │ └── PacketBuffer.h // 收包緩沖區(qū)負責粘包/半包切分 ├── Server/ │ ├── ServerApp.h/.cpp // CWinApp 派生InitInstance 里調 AfxSocketInit │ ├── ServerDlg.h/.cpp // 主對話框日志、在線列表、廣播下發(fā) │ ├── ListenSocket.h/.cpp // CAsyncSocket 派生只負責 accept │ └── ClientSocket.h/.cpp // 每個連接一個實例負責收、發(fā)、切包 └── Client/ ├── ClientApp.h/.cpp ├── ClientDlg.h/.cpp └── ClientSocket.h/.cppListenSocket和ClientSocket都從CAsyncSocket派生但職責完全不同前者一輩子只干一件事——把新連接從內核隊列里撈出來后者是“一線工人”一個實例對應一條 TCP 連接負責這條鏈路上的全部讀寫和異常處理。把這兩件事拆開后面加“最大連接數(shù)限制”“IP 黑名單”才有地方插。ServerDlg只做三件事接按鈕、寫日志、維護在線列表。它不直接持有 socket 的讀寫邏輯所有網(wǎng)絡事件通過自定義窗口消息回到這里這樣界面線程永遠不會被阻塞。類基類職責生命周期CListenSocketCAsyncSocket監(jiān)聽端口處理 OnAccept與主對話框同壽CClientSocketCAsyncSocket單連接收發(fā)、切包、斷線檢測連接建立時 new連接關閉后 deleteCServerDlgCDialogExUI、日志、連接表托管整個進程PacketBuffer無自寫粘包拆包歸屬 CClientSocket2.2 三種寫法怎么選原生 Winsock、CAsyncSocket、CSocket原生 Winsock 最透明WSAStartup、socket、bind、listen、select全部自己管代價是事件分發(fā)要手寫一個select循環(huán)套著幾十行FD_ISSET判斷新手很容易在錯誤處理上栽跟頭。CAsyncSocket是 MFC 對 Winsock 的薄封裝底層通過異步窗口消息把FD_ACCEPT、FD_READ、FD_WRITE、FD_CLOSE轉成虛函數(shù)回調也就是常說的OnAccept、OnConnect、OnReceive、OnSend、OnClose。它不會阻塞調用線程天然適合掛在對話框上跑。CSocket又往下派生了一層內部自帶一個隱藏窗口和阻塞循環(huán)配合CSocketFileCArchive能寫出接近文件讀寫的代碼。上手最快但坑也集中阻塞特性會卡住 UI 線程和CArchive搭配時Receive讀到的字節(jié)數(shù)和對端Send的字節(jié)數(shù)沒有一一對應關系半包一來就拋異常而且異常棧往往看不出真正原因。這個項目選CAsyncSocket理由很實際協(xié)議體就是二進制塊和字符串沒有復雜的對象序列化需求異步回調配上自己維護的收包緩沖區(qū)控制權在我手里。常見做法是——消息頻率低、協(xié)議簡單CAsyncSocket足夠真要傳大文件、需要做背壓控制反過來用獨立工作線程加阻塞 socket把收發(fā)和 UI 徹底隔離反而更省心。3. 服務端拆解監(jiān)聽、accept 和多連接托管服務端是整條鏈路的起點它出問題的表現(xiàn)往往很隱蔽——客戶端那邊只看到“連接被拒絕”或者“連上三秒就斷”真正的原因藏在服務端的初始化順序和對象生命周期里。3.1 初始化和監(jiān)聽AfxSocketInit 到 ListenAfxSocketInit()必須在任何 socket 調用之前執(zhí)行它內部完成了WSAStartup并把版本號協(xié)商好。放到CWinApp::InitInstance的最前面是最省事的做法漏掉這一步后面所有 socket 調用都會返回WSAStartup未執(zhí)行的錯誤而且錯誤碼不直觀。// ServerApp.cpp BOOL CServerApp::InitInstance() { // 必須在任何 socket 調用之前完成 Winsock 初始化 if (!AfxSocketInit()) { AfxMessageBox(_T(Winsock 初始化失敗程序退出)); return FALSE; } CWinApp::InitInstance(); CServerDlg dlg; m_pMainWnd dlg; dlg.DoModal(); return FALSE; // 對話框關閉即結束不再進入默認消息循環(huán) }InitInstance的返回值這里特意給了FALSE。原因是主界面是模態(tài)對話框DoModal返回意味著用戶已經(jīng)關窗此時如果再進CWinApp::Run的消息循環(huán)進程會卡在一個沒有窗口的循環(huán)里任務管理器里看著像僵尸進程。真正開始監(jiān)聽的動作放在對話框的按鈕響應里方便反復啟停// ServerDlg.cpp —— “開始監(jiān)聽”按鈕 void CServerDlg::OnBnClickedBtnListen() { if (m_pListen ! nullptr) return; // 防重復點擊 m_pListen new CListenSocket(this); if (!m_pListen-Create(m_nPort, SOCK_STREAM)) { DWORD err GetLastError(); AppendLog(_T(創(chuàng)建監(jiān)聽套接字失敗錯誤碼 %u), err); delete m_pListen; m_pListen nullptr; return; } if (!m_pListen-Listen(5)) { AppendLog(_T(Listen 失敗錯誤碼 %u), GetLastError()); m_pListen-Close(); delete m_pListen; m_pListen nullptr; return; } AppendLog(_T(已在 %u 端口開始監(jiān)聽), m_nPort); GetDlgItem(IDC_BTN_LISTEN)-EnableWindow(FALSE); }Create的第一個參數(shù)是端口傳 0 會讓系統(tǒng)隨機分配一個可用端口這在做多實例自測時很有用通過GetSockName能拿回實際端口。第二個參數(shù)SOCK_STREAM對應 TCPSOCK_DGRAM是 UDP寫錯了不會編譯報錯但行為完全不同。Listen的參數(shù)是 backlog指的是內核等待隊列的長度不是最大并發(fā)連接數(shù)很多人以為調大它就等于提高并發(fā)上限實際上它只影響“三次握手完成但還沒被 accept 取走”的連接能排多長隊。這個值一般給 5 到 10 就夠局域網(wǎng)工具用。GetLastError返回 10048 是端口被占用八成是上一次調試時進程沒退干凈返回 10013 是權限不夠通常是端口號小于 1024。3.2 OnAccept一次事件里把隊列收干凈CAsyncSocket的OnAccept是邊沿觸發(fā)式的通知——內核告訴你“有連接進來了”但不會告訴你“有幾個”。如果回調里只Accept一次而恰好同一瞬間來了三個客戶端剩下的兩個就會一直躺在隊列里直到下一次有新連接觸發(fā)事件才被順手取走。表現(xiàn)出來就是“客戶端連上了但服務端列表里沒有”或者“第二個客戶端連不上”。// ListenSocket.cpp void CListenSocket::OnAccept(int nErrorCode) { if (nErrorCode ! 0) { m_pDlg-AppendLog(_T(OnAccept 錯誤碼 %d), nErrorCode); CAsyncSocket::OnAccept(nErrorCode); return; } // 循環(huán) accept直到隊列里沒有待處理連接 for (;;) { CClientSocket* pClient new CClientSocket(m_pDlg); if (!Accept(*pClient)) // 失敗說明隊列空了或者出錯 { delete pClient; // 這里必須回收否則每來一次事件泄漏一個對象 break; } m_pDlg-AddClient(pClient); // 交給主對話框托管進入在線列表 } CAsyncSocket::OnAccept(nErrorCode); }Accept的第一個參數(shù)是“用來承載新連接的CAsyncSocket對象”所以必須在調用前 new 出來。失敗時一定要delete這是最容易漏的一行——每次空 accept 都會泄漏一個對象和它內部持有的 SOCKET 句柄跑一晚上能把句柄耗光最后表現(xiàn)成“新連接全都失敗”。循環(huán)的退出條件就是Accept返回FALSE此時GetLastError通常是WSAEWOULDBLOCK意思是隊列已經(jīng)空了正常情況不用當錯誤處理。3.3 連接對象托管和銷毀誰 new 誰 delete服務端的連接表放在CServerDlg里用CArrayCClientSocket*, CClientSocket*或者std::vector都行。關鍵約定只有一條對象由對話框創(chuàng)建、由對話框刪除CClientSocket自己絕不delete this。斷線時OnClose會被觸發(fā)但此時對象還在 MFC 的異步通知鏈路里直接刪自己會導致回調返回后訪問已釋放內存典型表現(xiàn)是關閉客戶端后服務端彈“內存不能為 read”。// ClientSocket.cpp void CClientSocket::OnClose(int nErrorCode) { // 不能在這里 delete this拋回 UI 線程統(tǒng)一釋放 if (m_pDlg ! nullptr) m_pDlg-PostMessage(WM_CLIENT_GONE, (WPARAM)this, 0); CAsyncSocket::OnClose(nErrorCode); } // ServerDlg.cpp —— 自定義消息的處理 LRESULT CServerDlg::OnClientGone(WPARAM wParam, LPARAM) { CClientSocket* pClient reinterpret_castCClientSocket*(wParam); RemoveClient(pClient); // 從在線列表移除 pClient-Close(); // 先關句柄 delete pClient; // 再刪對象 return 0; }PostMessage和SendMessage在這里有本質區(qū)別PostMessage只是投遞立即返回不會在 socket 回調里同步執(zhí)行刪除邏輯SendMessage會等待消息處理完才返回等于在回調里就把自己刪了必崩。注意Close()要和delete分開寫順序反了會導致CAsyncSocket析構時去關一個已失效的句柄調試版會彈斷言。4. 收發(fā)層拆解粘包、半包和跨線程回 UITCP 是字節(jié)流不是消息流。這條常識誰都背得出但真寫起來Receive一次讀到半條消息、或者兩條消息粘在一起的情況幾乎每個人都會遇到一次。收發(fā)層的設計目標就一個讓上層拿到的一定是完整的一條消息。4.1 定長包頭加變長包體協(xié)議頭固定 12 字節(jié)包體長度可變這樣切包邏輯最簡單也最不容易出錯。// Protocol.h #pragma once #include WinSock2.h #define PKT_MAGIC 0x4D464354 // MFCT用來快速判斷是不是自己的協(xié)議 #pragma pack(push, 1) // 必須 1 字節(jié)對齊否則 sizeof 會帶上填充字節(jié) struct PacketHeader { UINT32 magic; // 魔數(shù)防串協(xié)議 UINT32 length; // 包體字節(jié)數(shù)網(wǎng)絡字節(jié)序 UINT16 type; // 消息類型 UINT16 reserved; // 預留方便以后擴展 }; #pragma pack(pop) enum PacketType : UINT16 { MSG_LOGIN 1, // 客戶端上線 MSG_TEXT 2, // 文本消息 MSG_HEART 3, // 心跳 MSG_LOGOUT 4 // 主動下線 }; static const UINT32 MAX_BODY_LEN 1024 * 1024; // 單包上限 1MB防惡意超長包#pragma pack(push, 1)這行不能省。默認對齊下UINT32 UINT32 UINT16 UINT16剛好 12 字節(jié)沒問題但只要以后加一個UINT8字段編譯器就會補 3 個填充字節(jié)兩端算出來的sizeof不一致切包直接錯位而且錯得很隨機——改了結構體的人自己測沒事別人拉下來就崩。length字段走網(wǎng)絡字節(jié)序發(fā)送前htonl收到后ntohl。x86 是小端兩端都是 Windows 時看著“不轉也能跑”一旦以后接個 ARM 板子或者用別的語言寫客戶端立刻翻車。這個轉換成本幾乎為零沒有理由省。4.2 OnReceive 里循環(huán)讀到 WSAEWOULDBLOCKOnReceive同樣是“有數(shù)據(jù)了”的邊沿通知一次回調里內核緩沖區(qū)可能已經(jīng)堆了好幾 KB。只Receive一次的話剩下的數(shù)據(jù)要等下一次事件而如果對端就發(fā)了這一批然后不說話剩下的字節(jié)會一直卡著表現(xiàn)成“消息只收到一半就沒了”。// ClientSocket.cpp void CClientSocket::OnReceive(int nErrorCode) { if (nErrorCode ! 0) { OnPeerGone(); return; } char buf[4096]; for (;;) { int n Receive(buf, sizeof(buf)); if (n SOCKET_ERROR) { int err GetLastError(); if (err WSAEWOULDBLOCK) break; // 讀空了正常退出 OnPeerGone(); // 其他錯誤按斷線處理 return; } if (n 0) { OnPeerGone(); // 對端正常關閉 return; } m_recvBuf.Append(buf, n); } ParseBuffer(); // 緩沖夠了就切包分發(fā) CAsyncSocket::OnReceive(nErrorCode); }三個退出條件要分清楚WSAEWOULDBLOCK是“暫時沒數(shù)據(jù)了”屬于正常n 0是 FIN 包對端主動關了其他錯誤碼才是真異常比如 10054 是連接被對端重置。ParseBuffer負責把緩沖區(qū)里的字節(jié)按包頭切開// ClientSocket.cpp void CClientSocket::ParseBuffer() { while (m_recvBuf.GetSize() (int)sizeof(PacketHeader)) { PacketHeader hdr; memcpy(hdr, m_recvBuf.GetData(), sizeof(hdr)); if (hdr.magic ! PKT_MAGIC) { Close(); return; } // 不是本協(xié)議直接斷 UINT32 bodyLen ntohl(hdr.length); if (bodyLen MAX_BODY_LEN) { Close(); return; } // 防御性檢查 int total sizeof(hdr) (int)bodyLen; if (m_recvBuf.GetSize() total) break; // 半包等下一批數(shù)據(jù) Dispatch(hdr.type, m_recvBuf.GetData() sizeof(hdr), (int)bodyLen); m_recvBuf.RemoveHead(total); // 消費掉這一包 } }bodyLen的合法性檢查看起來多余實際上是一條防線如果對端發(fā)來一個聲稱 4GB 長度的包頭沒有這行判斷后面的GetSize() total永遠為真緩沖區(qū)會一路漲到內存爆掉而日志里什么都不會打印屬于典型的黑匣子問題。4.3 Send 只發(fā)出去一部分怎么辦Send的返回值是“本次實際寫進內核發(fā)送緩沖區(qū)的字節(jié)數(shù)”它可能小于你請求的長度。局域網(wǎng)內幾乎不會發(fā)生但在批量廣播或者對端接收窗口滿的時候就會出現(xiàn)。忽略返回值、直接認為發(fā)送成功是這類程序最常見的隱性 bug。// ClientSocket.cpp bool CClientSocket::SendPacket(UINT16 type, const void* body, UINT32 bodyLen) { if (m_hSocket INVALID_SOCKET) return false; PacketHeader hdr; hdr.magic PKT_MAGIC; hdr.length htonl(bodyLen); hdr.type type; hdr.reserved 0; // 先把包頭和包體拼成一個連續(xù)緩沖區(qū)再發(fā)避免兩次 Send 之間插進別的包 CByteArray pkt; pkt.SetSize(sizeof(hdr) bodyLen); memcpy(pkt.GetData(), hdr, sizeof(hdr)); if (bodyLen 0) memcpy(pkt.GetData() sizeof(hdr), body, bodyLen); int total (int)pkt.GetSize(); int sent 0; while (sent total) { int n Send(pkt.GetData() sent, total - sent); if (n SOCKET_ERROR) { int err GetLastError(); if (err WSAEWOULDBLOCK) { // 發(fā)送緩沖區(qū)滿簡單項目里直接視為失敗交給上層重連 return false; } return false; } sent n; // 必須累加否則會重復發(fā)送同一段數(shù)據(jù) } return true; }把包頭和包體拼成一次Send是刻意的如果先發(fā)頭、再發(fā)體中間被別的線程插進來發(fā)了一個包對端就會按“頭-別人的頭-別人的體-自己的體”切直接錯亂。要么拼成整塊發(fā)要么加發(fā)送隊列串行化簡單項目選前者。WSAEWOULDBLOCK在發(fā)送側的處理要按場景定聊天工具可以失敗重試廣播場景最好維護一個發(fā)送隊列等OnSend回調來了再繼續(xù)。這里為了代碼量控制直接返回失敗由上層提示“發(fā)送失敗”。4.4 跨線程回 UIPostMessage 加堆對象CAsyncSocket的回調運行在 MFC 的異步通知線程里直接在這些回調里操作控件輕則界面卡頓重繪異常重則彈斷言。穩(wěn)妥做法是把數(shù)據(jù)打包用PostMessage投遞到主線程。// ClientSocket.cpp void CClientSocket::Dispatch(UINT16 type, const void* body, int len) { // 堆上分配接收方負責 delete避免跨線程共享 CString CString* pMsg new CString((LPCSTR)body, len); switch (type) { case MSG_TEXT: m_pDlg-PostMessage(WM_PEER_TEXT, (WPARAM)pMsg, (LPARAM)m_hSocket); break; case MSG_HEART: m_pDlg-PostMessage(WM_PEER_HEART, (WPARAM)m_hSocket, 0); delete pMsg; // 心跳不帶內容立刻回收 break; default: delete pMsg; break; } } // ServerDlg.cpp —— 主線程處理 LRESULT CServerDlg::OnPeerText(WPARAM wParam, LPARAM lParam) { CString* pMsg reinterpret_castCString*(wParam); AppendLog(_T([%u] %s), (unsigned)lParam, *pMsg); delete pMsg; // 誰接收誰釋放 return 0; }堆對象是必須的PostMessage是異步的如果用棧對象地址消息還沒被處理函數(shù)地址就失效了。同理不能直接傳CString引用。約定好“接收方負責 delete”代碼里每一處都照做就不會漏。CString這里按LPCSTR構造意味著協(xié)議體按 ANSI 處理。如果客戶端要發(fā)中文又不想踩編碼坑統(tǒng)一改成 UTF-8發(fā)送端把CStringW轉 UTF-8 字節(jié)流接收端用MultiByteToWideChar轉回來再顯示兩端一致就行最怕的是一端用CStringA一端用CStringW。5. 避坑與排查MFC Socket 最容易出問題的四個位置這一節(jié)的現(xiàn)象都是我在調試這套結構時真實撞過的順序按“從啟動到退出”排。5.1 連接建立階段的坑現(xiàn)象一點了“連接”客戶端界面直接卡死幾秒然后提示超時。原因在 UI 線程里用了CSocket的阻塞式Connect或者用CAsyncSocket::Connect之后立刻彈了個模態(tài)框。前者會把消息循環(huán)堵死后者會讓OnConnect永遠進不來——CAsyncSocket的事件是靠窗口消息驅動的模態(tài)對話框自己跑了一套消息循環(huán)異步通知被吞掉了。解決連接動作只調Connect立即返回結果全在OnConnect里處理用nErrorCode判斷成功與否。非要在等待期間給用戶反饋用非模態(tài)對話框或者直接置灰按鈕加一句“連接中”。超時交給系統(tǒng)Connect本身有內核級超時想要更短就自己起個定時器超時后Close掉重來?，F(xiàn)象二服務端顯示監(jiān)聽成功客戶端就是連不上錯誤碼 10061。原因Windows 防火墻攔了。第一次運行編出來的 exe系統(tǒng)會彈一個“是否允許訪問網(wǎng)絡”的框如果當時點了取消之后這個程序的所有入站連接都會被靜默丟棄而且不會再彈第二次。解決到防火墻的“允許應用通過”里把這個 exe 勾上或者調試期間臨時關掉專用網(wǎng)絡的防火墻。順帶一個經(jīng)驗調試時用 127.0.0.1 先確認邏輯通不通再換局域網(wǎng) IP 測能把“防火墻問題”和“代碼問題”分開。綁定地址用INADDR_ANY而不是127.0.0.1后者只接受本機連接別的機器連過來會被拒。5.2 收發(fā)階段的坑現(xiàn)象三中文消息收到一半是亂碼或者最后幾個字變成方塊。原因發(fā)送端按CString的GetLength()算字節(jié)數(shù)接收端按字節(jié)構造CString。CString在 Unicode 工程里是寬字符GetLength()返回的是字符數(shù)一個漢字算 1占內存卻是 2 字節(jié)長度對不上。另一個常見原因是直接用strlen算 UTF-8 字符串長度遇到中文也會偏。解決協(xié)議體一律按字節(jié)流處理。發(fā)送前明確轉成std::string或者CByteArray長度取字節(jié)數(shù)接收端用MultiByteToWideChar(CP_UTF8, ...)轉回寬字符再顯示。兩端的編碼約定寫進Protocol.h的注釋里誰改誰負責?，F(xiàn)象四客戶端發(fā) 10 條消息服務端日志里只有 3 條內容還是拼接的。原因OnReceive只調了一次Receive剩下的字節(jié)留在內核緩沖區(qū)等下次事件而客戶端是連續(xù)Send的短時間內不會再觸發(fā)新事件數(shù)據(jù)就一直卡著。另一種情況是切包邏輯里RemoveHead的長度算錯把下一包的頭也吃掉了。解決按 4.2 的寫法Receive循環(huán)到WSAEWOULDBLOCK為止切包時嚴格用sizeof(PacketHeader) ntohl(length)作為消費長度別憑感覺寫常量。調試期在ParseBuffer里加一行日志打印緩沖區(qū)當前長度和切出來的包長跑十幾條消息就能看出規(guī)律。5.3 關閉和退出階段的坑現(xiàn)象五關掉客戶端之后服務端再啟動就報端口被占用10048。原因TIME_WAIT狀態(tài)主動關閉的一方會在這個狀態(tài)停留幾十秒。調試時反復啟停端口就一直被上一個進程占著。解決監(jiān)聽前給 socket 設SO_REUSEADDRMFC 里用SetSockOpt// ListenSocket.cpp —— 在 Create 之前或之后都可以但必須在 Listen 之前 int opt 1; m_pListen-SetSockOpt(SO_REUSEADDR, opt, sizeof(opt), SOL_SOCKET);注意SO_REUSEADDR只是讓綁定不被TIME_WAIT擋住不是讓兩個進程同時監(jiān)聽同一端口。真正同時監(jiān)聽要靠SO_REUSEPORTWindows 上的語義和 Linux 不一致跨平臺項目別指望它。另外退出時記得按“先Close所有連接再Close監(jiān)聽最后讓CWinApp正常返回”的順序收尾。漏掉某一步的表現(xiàn)是進程在任務管理器里掛著不退下一次調試端口還是占著。6. 二次開發(fā)把它改成一個真能干活的工具這套骨架跑通之后改造成本主要花在三個地方按投入產(chǎn)出比排。第一是加心跳和超時踢人。協(xié)議里已經(jīng)留了MSG_HEART服務端維護一個mapSOCKET, time_t起一個SetTimer每 30 秒掃一遍超過 90 秒沒更新的連接直接Close并從在線列表移除。沒有這一步客戶端拔網(wǎng)線、進程被強殺這類情況服務端完全感知不到在線列表會一直掛著一堆僵尸連接廣播時還要往死連接上寫。第二是把廣播做對。別在 UI 線程里循環(huán)調SendPacket客戶端一多界面就卡。做法是給每個CClientSocket掛一個std::dequeCByteArray發(fā)送隊列UI 線程只負責push真正的Send放在各自的OnSend回調里推進寫不動了就停等下一次可寫事件繼續(xù)。這個改造大概幾十行但決定了這套東西能帶 5 個客戶端還是 50 個。第三是換成二進制協(xié)議?，F(xiàn)在包體是文本解析靠字符串字段一多就難維護。把MSG_LOGIN的包體定義成struct同樣#pragma pack(push, 1)讀寫時逐字段memcpy配合包頭里的type做分發(fā)擴展新消息只要在Protocol.h里加一個枚舉值和一個結構體。改造點改動位置大致工作量解決的問題心跳超時CServerDlg 定時器半天僵尸連接、在線狀態(tài)不準發(fā)送隊列CClientSocket一天UI 卡頓、大廣播丟包二進制協(xié)議Protocol.h ParseBuffer一天字段擴展、解析性能驗證方法上我會準備兩個客戶端實例再加一個用腳本寫的假客戶端。腳本那邊故意一次只發(fā) 3 個字節(jié)把包頭拆成兩批送專門驗證半包處理再故意連上不登錄驗證服務端的超時邏輯最后用taskkill強殺客戶端看服務端多久能從在線列表里把它清掉。這三種病態(tài)輸入跑過一遍基本就敢往設備上掛了。從那以后我每次寫這類帶網(wǎng)絡的小工具都會先把“發(fā)包不完整、收包不完整、連接突然消失”這三件事的日志打點加進第一版而不是等出問題了再回來補。調試網(wǎng)絡問題最貴的是信息日志里多一行緩沖區(qū)長度可能省掉一整晚。希望幫到你。本文還有配套的精品資源點擊獲取