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