簡(jiǎn)介針對(duì)Windows平臺(tái)C socket網(wǎng)絡(luò)開(kāi)發(fā)這份資源演示了如何基于IOCP輸入輸出完成端口在單線程中同時(shí)監(jiān)聽(tīng)多個(gè)端口面向需要處理高并發(fā)連接、又希望降低線程切換開(kāi)銷(xiāo)的中級(jí)網(wǎng)絡(luò)開(kāi)發(fā)者。壓縮包共2個(gè)文件分別為一個(gè)C源文件.cpp和一個(gè)頭文件.h整體僅3KB代碼精簡(jiǎn)便于快速定位核心邏輯。資源已有1649人瀏覽學(xué)習(xí)。實(shí)現(xiàn)圍繞CreateIoCompletionPort創(chuàng)建完成端口、將多個(gè)監(jiān)聽(tīng)套接字關(guān)聯(lián)到同一IOCP、WSARecvFrom發(fā)起異步接收、GetQueuedCompletionStatus循環(huán)獲取完成事件等關(guān)鍵環(huán)節(jié)展開(kāi)并涉及OVERLAPPED結(jié)構(gòu)體使用及錯(cuò)誤處理要點(diǎn)。通過(guò)閱讀這份示例可以直觀理解單線程如何驅(qū)動(dòng)多個(gè)監(jiān)聽(tīng)端口的事件分發(fā)掌握把普通accept邏輯改造為IOCP異步模型的基本方法也可為排查類似網(wǎng)絡(luò)服務(wù)框架問(wèn)題提供參考。1. 單線程同時(shí)監(jiān)聽(tīng)多個(gè)端口為什么還要自己做而不是上框架拿到“單線程實(shí)現(xiàn)同時(shí)監(jiān)聽(tīng)多個(gè)端口windows平臺(tái)c代碼”這個(gè)需求的人通常不是沒(méi)事找事。要么是寫(xiě)一個(gè)輕量級(jí)網(wǎng)關(guān)要同時(shí)接 HTTP 控制口、TCP 數(shù)據(jù)口和內(nèi)部心跳口要么是設(shè)備端程序不能為每個(gè)端口開(kāi)一個(gè)線程去占資源要么是接手了老項(xiàng)目里面就是一個(gè)跑在主循環(huán)里的 socket 轉(zhuǎn)發(fā)邏輯只允許你在單線程里加監(jiān)聽(tīng)。Windows 下的 C 做多端口監(jiān)聽(tīng)常見(jiàn)做法是用 select 模型在一個(gè)線程里輪詢所有 socket而不是給每個(gè)端口起一個(gè) accept 線程——后者線程切換開(kāi)銷(xiāo)、同步鎖、資源占用都上來(lái)了而且程序結(jié)構(gòu)一旦復(fù)雜線程一多排查問(wèn)題的成本遠(yuǎn)比你省下的那幾行代碼多。本文會(huì)把從 WSAStartup 到 bind、listen、select 事件循環(huán)、數(shù)據(jù)收發(fā)、優(yōu)雅退出的完整路徑講清楚每一步都給可抄的代碼和參數(shù)說(shuō)明并把 Windows 平臺(tái)特有的坑單獨(dú)拎出來(lái)講。適合需要自己控制網(wǎng)絡(luò)層、不想為了三個(gè)端口引入全套網(wǎng)絡(luò)框架的 C 開(kāi)發(fā)者。2. Windows 下先把 socket 聽(tīng)上WSAStartup、bind 與 listen 的正確姿勢(shì)2.1 為什么單線程方案在 Windows 上首選 select 而不是 WSAAsyncSelectWindows 上做網(wǎng)絡(luò)編程除了 select還有 WSAAsyncSelect消息驅(qū)動(dòng)、WSAEventSelect事件驅(qū)動(dòng)、IOCP完成端口。單線程同時(shí)監(jiān)聽(tīng)多個(gè)端口為什么說(shuō) select 是最直接、最不需要額外機(jī)制配合的選擇關(guān)鍵在于它把“等事件”這件事收斂到了一個(gè)函數(shù)調(diào)用上你告訴內(nèi)核“我想等這些 socket 的可讀、可寫(xiě)、異常事件”內(nèi)核阻塞地等一旦有事件發(fā)生就返回然后你逐個(gè)檢查哪個(gè) socket 就緒了。一套循環(huán)就完成了多個(gè)端口的 accept、recv、send 調(diào)度不需要窗口消息泵不需要額外開(kāi)線程去處理事件通知。WSAAsyncSelect 依賴窗口句柄消息循環(huán)適合 MFC 或帶消息泵的 GUI 程序放到純控制臺(tái)服務(wù)里就得自己創(chuàng)建一個(gè)隱藏窗口復(fù)雜度不降反升。IOCP 是高性能服務(wù)器的最終歸屬但它的模型是“多個(gè)工作線程 完成回調(diào)”和“單線程”這個(gè)硬約束不匹配。select 雖然在大規(guī)模并發(fā)下被詬病FD_SETSIZE 默認(rèn) 64 個(gè) socket輪詢復(fù)雜度 O(n)但對(duì)于“同時(shí)監(jiān)聽(tīng)?zhēng)讉€(gè)到十幾個(gè)端口每個(gè)端口連接數(shù)也不多”的典型場(chǎng)景它就是最樸素、最少依賴、最容易在單線程里講清楚邏輯的方案。順帶說(shuō)一句如果你監(jiān)聽(tīng)端口數(shù)量超過(guò) 64 個(gè)select 可能直接翻車(chē)這個(gè)問(wèn)題放到第 5 章講排查時(shí)細(xì)說(shuō)。2.2 初始化 WinsockWSAStartup 版本參數(shù)不能隨便填在 Windows 上寫(xiě)任何 socket 程序第一步必然是 WSAStartup這個(gè)調(diào)用把 Winsock 庫(kù)加載進(jìn)進(jìn)程并協(xié)商版本號(hào)。常見(jiàn)的錯(cuò)誤寫(xiě)法是版本號(hào)直接寫(xiě) 2.0 然后不管返回值或者在程序退出時(shí)漏了 WSACleanup。WSAStartup 的第二個(gè)參數(shù)要傳一個(gè)指向 WSADATA 的指針第一個(gè)參數(shù)是請(qǐng)求的版本號(hào)MAKEWORD(2, 2) 是請(qǐng)求 Winsock 2.2這是 Windows XP 之后所有系統(tǒng)都原生支持的版本也是目前最穩(wěn)妥的選擇。winsock2 頭文件和 ws2_32.lib 鏈接庫(kù)是配套的。如果只寫(xiě)#include winsock.h編譯期會(huì)報(bào)一堆重定義錯(cuò)誤或找不到函數(shù)的鏈接錯(cuò)因?yàn)?winsock.h 和 winsock2.h 的 socket 函數(shù)聲明有沖突。VC 里鏈接庫(kù)也要明確加 ws2_32.lib否則癥狀是編譯通過(guò)但 link 階段報(bào) unresolved external symbol 一堆錯(cuò)。下面這段是初始化代碼返回值逐個(gè)檢查任何一步失敗都直接退出避免把帶病狀態(tài)帶到后續(xù)邏輯里。#include winsock2.h #include ws2tcpip.h #include iostream #include vector #pragma comment(lib, ws2_32.lib) bool InitWinsock() { WSADATA wsaData; int ret WSAStartup(MAKEWORD(2, 2), wsaData); if (ret ! 0) { std::cerr WSAStartup failed, code ret std::endl; return false; } // 校驗(yàn)協(xié)商出來(lái)的版本確實(shí)是 2.2 if (LOBYTE(wsaData.wVersion) ! 2 || HIBYTE(wsaData.wVersion) ! 2) { std::cerr Winsock version mismatch: (int)LOBYTE(wsaData.wVersion) . (int)HIBYTE(wsaData.wVersion) std::endl; WSACleanup(); return false; } return true; }邏輯說(shuō)明WSAStartup 成功返回 0但協(xié)商出的版本可能不是你請(qǐng)求的版本老系統(tǒng)上尤其如此。所以初始化后必須校驗(yàn) wsaData.wVersion否則后面用了 2.2 才有的 API 會(huì)在運(yùn)行時(shí)掛掉。#pragma comment(lib, ws2_32.lib)這行是 Visual C 專有的讓鏈接器自動(dòng)帶上 ws2_32.lib不用去“項(xiàng)目屬性 → 鏈接器 → 輸入”里手工加。用 MinGW 或 Clang 編譯時(shí)忽略這行在命令行里加-lws2_32即可。2.3 bind 和 listen 順序、參數(shù)與端口復(fù)用每個(gè)要監(jiān)聽(tīng)的端口對(duì)應(yīng)一個(gè) SOCKET流程是 socket() 創(chuàng)建 → bind() 綁定地址和端口 → listen() 進(jìn)入監(jiān)聽(tīng)狀態(tài)。bind 時(shí)用 sockaddr_in 結(jié)構(gòu)體地址填 INADDR_ANY即 0.0.0.0表示綁定到本機(jī)所有網(wǎng)卡地址端口用 htons() 轉(zhuǎn)換字節(jié)序。字節(jié)序問(wèn)題在 Windows 上一定要認(rèn)真對(duì)待x86 是小端機(jī)器網(wǎng)絡(luò)字節(jié)序是大端端口號(hào)、IP 地址都必須經(jīng)過(guò) htons/htonl 轉(zhuǎn)換漏掉的話 bind 的實(shí)際端口會(huì)變成一個(gè)你沒(méi)預(yù)期的數(shù)字而且 bind 照樣可能成功——這屬于最隱蔽的坑之一。listen 的第二個(gè)參數(shù) backlog 表示內(nèi)核為這個(gè)監(jiān)聽(tīng) socket 排隊(duì)的已完成連接數(shù)上限。Windows 上這個(gè)值不是嚴(yán)格硬上限但建議至少設(shè) 5 或 8。注意一個(gè)細(xì)節(jié)select 監(jiān)聽(tīng)的是“有客戶端 connect 進(jìn)來(lái)”這個(gè)事件不是監(jiān)聽(tīng)“所有客戶端連接”本身。listen 之后的 socket 還是一個(gè)“被動(dòng)”socket它自己不收數(shù)據(jù)需要 accept 出來(lái)一個(gè)新的 socket 才能和客戶端收發(fā)。下面這段創(chuàng)建監(jiān)聽(tīng) socket 的代碼可以直接復(fù)用傳入端口號(hào)返回監(jiān)聽(tīng) SOCKET。SOCKET CreateListenSocket(unsigned short port) { SOCKET s socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); if (s INVALID_SOCKET) { std::cerr socket() failed, error WSAGetLastError() std::endl; return INVALID_SOCKET; } // 配置 SO_REUSEADDR否則 TIME_WAIT 狀態(tài)下端口可能綁不上 BOOL reuse TRUE; setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (const char*)reuse, sizeof(reuse)); sockaddr_in addr{}; addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); // 綁定所有網(wǎng)卡 addr.sin_port htons(port); // 字節(jié)序轉(zhuǎn)換漏了這個(gè)端口就錯(cuò)了 int ret bind(s, (sockaddr*)addr, sizeof(addr)); if (ret SOCKET_ERROR) { std::cerr bind() port port failed, error WSAGetLastError() std::endl; closesocket(s); return INVALID_SOCKET; } ret listen(s, 8); if (ret SOCKET_ERROR) { std::cerr listen() failed, error WSAGetLastError() std::endl; closesocket(s); return INVALID_SOCKET; } return s; }這段代碼里有兩個(gè)參數(shù)值得停下來(lái)看。第一個(gè)是SO_REUSEADDR沒(méi)有它程序退出后端口會(huì)進(jìn)入 TIME_WAIT 狀態(tài)短時(shí)間內(nèi)重啟程序 bind 會(huì)報(bào) WSAEADDRINUSE錯(cuò)誤碼 10048這在調(diào)試循環(huán)里非常煩人。第二個(gè)是addr{}這個(gè)初始化寫(xiě)法在 C11 之后會(huì)把 sockaddr_in 整個(gè)清零避免殘留棧上垃圾數(shù)據(jù)。如果漏了初始化sin_zero 字段里的隨機(jī)字節(jié)可能導(dǎo)致 bind 返回奇奇怪怪的錯(cuò)誤。2.4 兩個(gè)端口綁定到一個(gè) socket 上的黑匣子行為寫(xiě)代碼之前先建立一個(gè)認(rèn)知一個(gè) socket 只能 bind 一個(gè)端口想同時(shí)監(jiān)聽(tīng) N 個(gè)端口你必須創(chuàng)建 N 個(gè) socket。這是一個(gè)經(jīng)常被誤解的點(diǎn)——有人以為一個(gè) SOCKET 可以像文件句柄一樣“偏移”到不同端口實(shí)際上做不到。單線程監(jiān)聽(tīng)多端口的本質(zhì)是持有多個(gè)監(jiān)聽(tīng) SOCKET然后在同一個(gè)循環(huán)里統(tǒng)一等待這些 socket 的事件。這個(gè)“持有 統(tǒng)一等待”的結(jié)構(gòu)會(huì)在第 3 章展開(kāi)它是整個(gè)單線程模型的骨架。還有一個(gè)跟端口綁定相關(guān)的坑監(jiān)聽(tīng)相同端口時(shí)如果兩個(gè)進(jìn)程都開(kāi)了 SO_REUSEADDRWindows 上可能出現(xiàn)兩個(gè)進(jìn)程都成功 bind 的情況但能不能 accept 到連接是未定義的。所以商用程序里端口沖突大概率不是 bind 失敗而是另一個(gè)程序先占了你這個(gè)端口。排查時(shí)用netstat -ano | findstr 端口號(hào)看 PID這是 Windows 上最直接的辦法。3. 單線程同時(shí)監(jiān)聽(tīng)的核心select 事件循環(huán)與 FD_SET 管理3.1 把 N 個(gè)監(jiān)聽(tīng) socket 放進(jìn) FD_SET一次 select 等所有端口select 在單線程多端口模型中的角色相當(dāng)于一個(gè)“交通指揮員”你告訴它一批 socket 的 fd它阻塞在那里直到其中至少一個(gè) socket 有事件發(fā)生返回后你再挨個(gè)檢查是誰(shuí)有事件。在 Windows 上SOCKET 句柄不是小整數(shù)不能假設(shè)它從 0 開(kāi)始連續(xù)排列所以不能像 Linux 那樣把 socket fd 當(dāng)成數(shù)組下標(biāo)用。Windows 的做法是維護(hù) fd_set用 FD_SET/FD_ISSET/FD_ZERO 宏來(lái)管理和檢查。每次調(diào)用 select 前都要重建 fd_set。原因是 select 返回時(shí)會(huì)修改 fd_set 的內(nèi)容只保留有事件的 socket“可讀集”里沒(méi)事件的那些 socket 會(huì)被移出集合。如果復(fù)用同一個(gè) fd_set 不重建第二輪 select 直接丟失之前注冊(cè)的 socket。這是單線程 select 模型最容易寫(xiě)錯(cuò)的點(diǎn)網(wǎng)上很多示例代碼在這個(gè)細(xì)節(jié)上都是錯(cuò)的不重建 fd_set結(jié)果表現(xiàn)是“剛開(kāi)始正常跑一會(huì)兒后某個(gè)端口突然收不到連接了”。fd_set g_readSet; // 全局或局部都可以但必須每次 select 前重建賦值 // 每次循環(huán)重建 FD_ZERO(g_readSet); for (SOCKET s : g_listenSockets) { FD_SET(s, g_readSet); // 把每個(gè)監(jiān)聽(tīng) socket 注冊(cè)進(jìn)可讀集 } // 如果想在同一個(gè)線程里做超時(shí)控制可以把這里的超時(shí)設(shè)為 500ms timeval timeout{0, 500000}; // 0 秒 500 毫秒測(cè)心跳或超時(shí)檢測(cè)用 int ret select(0, g_readSet, nullptr, nullptr, timeout); if (ret SOCKET_ERROR) { // 處理錯(cuò)誤見(jiàn) 5.2 節(jié)的 WSAEINTR 問(wèn)題 } else if (ret 0) { // 超時(shí)沒(méi)有事件做定時(shí)任務(wù)比如清理空閑連接 } else { // 有事件遍歷 g_readSet見(jiàn)下面 3.2 的過(guò)程 }邏輯說(shuō)明select 的第一個(gè)參數(shù)在 Windows 上被忽略填 0 即可它不像 Linux 那樣需要傳“最大 fd 1”。第二個(gè)參數(shù)是讀集合第三個(gè)第四分別是寫(xiě)和異常集合不要在這里傳同一個(gè) fd_set 的地址——Windows 的 select 會(huì)修改傳入的 fd_set同一個(gè)集合被多個(gè)參數(shù)引用時(shí)結(jié)果不可預(yù)測(cè)。最后一個(gè)參數(shù)是超時(shí)傳 nullptr 表示無(wú)限阻塞傳 timeval 則指定最長(zhǎng)等待時(shí)間。單線程模型里建議給一個(gè)非零超時(shí)這樣即使沒(méi)有網(wǎng)絡(luò)事件線程也能定期醒來(lái)執(zhí)行清理任務(wù)。3.2 遍歷就緒集合區(qū)分 accept 事件和普通數(shù)據(jù)事件select 返回后遍歷讀集合中的每個(gè) SOCKET判斷它的類型如果是監(jiān)聽(tīng) socket說(shuō)明有新連接到達(dá)調(diào)用 accept如果是已連接 socket說(shuō)明有數(shù)據(jù)可讀調(diào)用 recv。怎么區(qū)分最簡(jiǎn)單的做法是把監(jiān)聽(tīng) socket 單獨(dú)放在一個(gè) vector 里把已連接 socket 放在另一個(gè)集合里遍歷時(shí)先看當(dāng)前檢查的 SOCKET 是否落在監(jiān)聽(tīng)列表里。有一種常見(jiàn)設(shè)計(jì)是把“區(qū)分”做成查表每次 accept 產(chǎn)生新連接時(shí)記錄 [newSocket, port] 的映射這樣就能在單線程里知道這個(gè)連接是從哪個(gè)端口進(jìn)來(lái)的后續(xù)按端口做不同的協(xié)議處理。這是多端口監(jiān)聽(tīng)的價(jià)值所在——每個(gè)端口的協(xié)議不同才是常態(tài)一個(gè)端口 8080 收 HTTP 控制指令另一個(gè)端口 9090 轉(zhuǎn)發(fā)設(shè)備數(shù)據(jù)單線程模型里只需要在代碼里加一個(gè)GetPortBySocket(acceptSock)的查表函數(shù)。下面這個(gè)片段是事件循環(huán)里 accept 部分的核心邏輯。// 遍歷所有就緒的 socket for (int i 0; i g_readSet.fd_count; i) { SOCKET s g_readSet.fd_array[i]; if (IsListenSocket(s)) { // 監(jiān)聽(tīng) socket 有新連接 sockaddr_in clientAddr{}; int addrLen sizeof(clientAddr); SOCKET client accept(s, (sockaddr*)clientAddr, addrLen); if (client INVALID_SOCKET) { // accept 失敗常見(jiàn)原因連接在 accept 前被客戶端斷開(kāi) // 或 fd_set 已滿超過(guò) FD_SETSIZE繼續(xù)循環(huán)不要崩潰 int err WSAGetLastError(); if (err WSAECONNRESET) { continue; } } else { // 記住這個(gè) client socket 對(duì)應(yīng)的監(jiān)聽(tīng)端口用于協(xié)議分流 int port GetPortByListenSocket(s); g_clientSockets.push_back(client); g_clientPortMap[client] port; } } else { // 普通連接有數(shù)據(jù)到達(dá)調(diào)用 recv 或檢查對(duì)端斷開(kāi) HandleClientRead(s); } }參數(shù)說(shuō)明g_readSet.fd_count 是被 select 修改后的實(shí)際就緒數(shù)量fd_array 是就緒 socket 列表。直接遍歷 fd_array 比每次調(diào)用 FD_ISSET 從頭掃描一遍更高效但在 Windows 上 fd_count 的單位是“就緒數(shù)”而非“總注冊(cè)數(shù)”這個(gè)用法要特別注意。用fd_count直接作為循環(huán)上限是對(duì)的不必?fù)?dān)心漏掉未就緒的 socket。另外這里的 client socket 默認(rèn)是阻塞模式accept 后 recv 會(huì)卡住線程這在單線程模型里是致命的——第 4 章會(huì)講把它設(shè)為非阻塞的必要性以及由此引入的 WSAEWOULDBLOCK 處理。3.3 阻塞還是非阻塞單線程模型的第一個(gè)分岔口監(jiān)聽(tīng) socket 本身的 accept 操作在 socket 有連接事件時(shí)調(diào)用不會(huì)阻塞。但 accept 出來(lái)的 client socket如果不改成非阻塞后續(xù) recv 在數(shù)據(jù)沒(méi)到齊時(shí)會(huì)阻塞直接卡死整個(gè)事件循環(huán)——這是單線程模型里最嚴(yán)重的結(jié)構(gòu)性問(wèn)題。兩個(gè)可選方向一是把 client socket 設(shè)為非阻塞用 select 等它可讀再 recv二是保持阻塞但每次都拿 select 等到可讀后調(diào)用 recvrecv 在“一個(gè)字節(jié)也沒(méi)有”的情況下不會(huì)返回但“有部分?jǐn)?shù)據(jù)”時(shí)會(huì)立即返回當(dāng)前可讀的部分。第二種方式其實(shí)也能用但前提是每次 recv 前都確認(rèn) select 返回“可讀”否則還是有極小概率卡住。實(shí)際工程中更常見(jiàn)、更穩(wěn)妥的是把 client socket 設(shè)為非阻塞。Windows 上設(shè)非阻塞要調(diào)用 ioctlsocket 而不是 fcntl后者是 Linux 的 APIWindows 沒(méi)有。設(shè)置后recv 在沒(méi)有數(shù)據(jù)時(shí)返回 SOCKET_ERROR 且 WSAGetLastError() WSAEWOULDBLOCK這才是“沒(méi)有數(shù)據(jù)”的正常表現(xiàn)不是錯(cuò)誤。代碼里初始化 client socket 就是三行ioctlsocket 設(shè)非阻塞然后注冊(cè)進(jìn) g_clientSet。u_long mode 1; // 1 非阻塞0 阻塞 int ioRet ioctlsocket(client, FIONBIO, mode); if (ioRet SOCKET_ERROR) { std::cerr ioctlsocket failed, error WSAGetLastError() std::endl; closesocket(client); continue; }這里參數(shù)FIONBIO是 ioctlsocket 的命令字表示“設(shè)置/清除非阻塞模式”。mode 為 1 時(shí)非阻塞為 0 時(shí)恢復(fù)阻塞。注意 ioctlsocket 失敗不會(huì)導(dǎo)致進(jìn)程崩潰但 client socket 會(huì)保持它原來(lái)的默認(rèn)行為繼承監(jiān)聽(tīng) socket 的阻塞屬性——監(jiān)聽(tīng) socket 本身就是阻塞的于是后續(xù) recv 可能卡死循環(huán)。所以必須檢查返回值并失敗時(shí)及時(shí) closesocket否則一個(gè)壞連接就毀掉整個(gè)多端口服務(wù)。3.4 完整的事件循環(huán)從 accept 到 recv 的主干代碼把 3.1 到 3.3 的內(nèi)容串起來(lái)事件循環(huán)的主干就是三大段重建 fd_set → select 等待 → 遍歷就緒 sockets。下面是濃縮后的完整循環(huán)其中 HandleClientRead 在第 4 章展開(kāi)這里先用占位函數(shù)保持結(jié)構(gòu)完整。bool g_running true; std::vectorSOCKET g_listenSockets; // 所有監(jiān)聽(tīng) socket std::vectorSOCKET g_clientSockets; // 所有已連接 socket void RunEventLoop() { while (g_running) { fd_set readSet; FD_ZERO(readSet); for (SOCKET s : g_listenSockets) FD_SET(s, readSet); for (SOCKET s : g_clientSockets) FD_SET(s, readSet); timeval tv{0, 500000}; // 500ms 超時(shí)兼顧定時(shí)清理任務(wù) int ret select(0, readSet, nullptr, nullptr, tv); if (ret SOCKET_ERROR) { int err WSAGetLastError(); if (err WSAEINTR) continue; // 被信號(hào)中斷重試 std::cerr select error: err std::endl; break; } if (ret 0) { // 超時(shí)可以做空閑連接超時(shí)檢查或心跳發(fā)送 continue; } // 遍歷就緒集合 for (int i 0; i readSet.fd_count; i) { SOCKET s readSet.fd_array[i]; if (std::find(g_listenSockets.begin(), g_listenSockets.end(), s) ! g_listenSockets.end()) { // 監(jiān)聽(tīng) socket → accept sockaddr_in addr{}; int len sizeof(addr); SOCKET c accept(s, (sockaddr*)addr, len); if (c ! INVALID_SOCKET) { u_long mode 1; ioctlsocket(c, FIONBIO, mode); g_clientSockets.push_back(c); } } else { HandleClientRead(s); } } } }這段代碼里std::find判斷監(jiān)聽(tīng) socket 是 O(n) 的n 是監(jiān)聽(tīng)端口數(shù)量通常不超過(guò)十個(gè)性能無(wú)所謂。但注意g_clientSockets 里如果沒(méi)有暫存就緒的 client socket它的元素會(huì)在這里被 HandleClientRead 處理而 HandleClientRead 內(nèi)部可能需要從 vector 中刪除已經(jīng)斷開(kāi)的 socket——這就是“遍歷時(shí)刪除元素”的經(jīng)典問(wèn)題先標(biāo)記后刪除或直接給 vector 做 swap-pop 都可以但絕對(duì)不能邊遍歷邊擦除。很多人在這個(gè)位置翻車(chē)程序跑著跑著就內(nèi)存崩潰原因就是遍歷完 fd_set 之后又回頭去刪 g_clientSocketsiterator 全失效。4. 收發(fā)數(shù)據(jù)的完整閉環(huán)recv/send 與多端口連接區(qū)分4.1 非阻塞 recv 的三種返回結(jié)果與 WSAEWOULDBLOCK 處理非阻塞 client socket 上調(diào)用 recv返回結(jié)果只有三種大于 0 表示讀到若干字節(jié)等于 0 表示對(duì)端關(guān)閉連接SOCKET_ERROR 且 WSAGetLastError() 返回 WSAEWOULDBLOCK10035表示“沒(méi)有數(shù)據(jù)可讀但連接還在”。單線程模型里凡是走到 recv 分支的都是 select 已經(jīng)告訴你“可讀”的 socket按理說(shuō) WSAEWOULDBLOCK 不該出現(xiàn)但實(shí)際場(chǎng)景中還是會(huì)出現(xiàn)——比如兩個(gè)客戶端幾乎同時(shí)發(fā)數(shù)據(jù)select 返回后你處理第一個(gè) socket 用了稍長(zhǎng)時(shí)間第二個(gè) socket 的數(shù)據(jù)已經(jīng)被內(nèi)核收走一部分你再 recv 時(shí)它已經(jīng)被別的邏輯讀到了此時(shí)返回的也是 WSAEWOULDBLOCK。所以這段代碼里 WSAEWOULDBLOCK 必須當(dāng)作“正常情況”處理不能當(dāng)錯(cuò)誤打印更不能因此 close socket。另一個(gè)處理要點(diǎn)是 recv 的 buffer 大小。一般設(shè) 8KB 或 16KB 都比較合理太大浪費(fèi)內(nèi)存太小讀到一半還得再來(lái)一次 recv。真實(shí)開(kāi)發(fā)里切記不要假設(shè)“一次 recv 就能讀完一幀完整協(xié)議”TCP 是流協(xié)議沒(méi)有消息邊界。所以業(yè)務(wù)層必須自己處理粘包和半包——常見(jiàn)做法是先用固定 4 字節(jié)頭存消息長(zhǎng)度再按長(zhǎng)度循環(huán)讀取剩下的 body。如果只是做轉(zhuǎn)發(fā)或簡(jiǎn)單協(xié)議可以先把數(shù)據(jù)追加到一個(gè) per-socket 的 std::vector 緩沖區(qū)里判斷有沒(méi)有完整幀再解析。// per-socket 接收緩沖區(qū)用 map 維護(hù)不混在不同端口之間 std::mapSOCKET, std::vectorBYTE g_recvBuffers; void HandleClientRead(SOCKET s) { char buf[8192]; int n recv(s, buf, sizeof(buf), 0); if (n 0) { std::vectorBYTE out g_recvBuffers[s]; out.insert(out.end(), buf, buf n); // 按協(xié)議嘗試解包解出完整幀后交給業(yè)務(wù)處理 ProcessProtocol(s, out); } else if (n 0) { // 對(duì)端關(guān)閉連接 CleanupClient(s); } else { int err WSAGetLastError(); if (err WSAEWOULDBLOCK) { // 沒(méi)有數(shù)據(jù)正常跳過(guò) return; } else if (err WSAECONNRESET) { // 對(duì)端異常斷開(kāi)常見(jiàn)于 RST 包 CleanupClient(s); } else { std::cerr recv error on socket s , error err std::endl; CleanupClient(s); } } }邏輯說(shuō)明每個(gè) socket 維護(hù)獨(dú)立的接收緩沖區(qū)這樣可以做到“數(shù)據(jù)按端口分流”。ProcessProtocol 就是 4.2 節(jié)要講的按端口分發(fā)邏輯。WSAECONNRESET10054在 Windows 下非常常見(jiàn)尤其是客戶端進(jìn)程突然被殺掉時(shí)TCP 會(huì)發(fā) RST 而不是 FINrecv 就返回這個(gè)錯(cuò)誤。要養(yǎng)成習(xí)慣收到 WSAECONNRESET 后直接清理連接不要嘗試再往這個(gè) socket 寫(xiě)數(shù)據(jù)。4.2 按端口分流協(xié)議連接與端口的映射管理多端口監(jiān)聽(tīng)的關(guān)鍵價(jià)值在于每個(gè)端口的協(xié)議不同所以收到數(shù)據(jù)后要快速判斷“這個(gè)連接屬于哪個(gè)端口”。實(shí)現(xiàn)上最簡(jiǎn)單的是用兩個(gè) std::map一個(gè)記錄 client socket → 監(jiān)聽(tīng)端口另一個(gè)記錄 client socket → 協(xié)議上下文。在 3.2 節(jié)的 accept 代碼里accept 后立刻做這個(gè)映射。之后 HandleClientRead 里用 socket 在 map 里查到端口號(hào)走到對(duì)應(yīng)的協(xié)議處理函數(shù)。如果監(jiān)聽(tīng)端口不多且協(xié)議都簡(jiǎn)單也可以直接把端口號(hào)編碼進(jìn) socket 對(duì)應(yīng)的連接上下文結(jié)構(gòu)體里避免每次都查 map。常見(jiàn)的做法是定義一個(gè) ClientContext 結(jié)構(gòu)體把 socket、對(duì)端地址、對(duì)應(yīng)監(jiān)聽(tīng)端口、接收緩沖區(qū)、上次活動(dòng)時(shí)間都放進(jìn)去然后用 std::mapSOCKET, ClientContext 統(tǒng)一管理。下面這個(gè)結(jié)構(gòu)體就是一套能直接用的管理單元。struct ClientContext { SOCKET sock; int listenPort; // 這個(gè)連接是從哪個(gè)監(jiān)聽(tīng)端口進(jìn)來(lái)的 std::vectorBYTE recvBuf; std::vectorBYTE sendBuf; DWORD lastActiveTick; // 用于空閑超時(shí)清理 }; std::mapSOCKET, ClientContext g_clients;映射表的三個(gè)操作時(shí)機(jī)必須對(duì)齊accept 成功時(shí)創(chuàng)建 context 并放入 maprecv 返回 0、WSAECONNRESET 或業(yè)務(wù)層判定會(huì)話結(jié)束時(shí)從 map 中移除并 closesocketselect 循環(huán)每次重建 fd_set 時(shí)遍歷 map 的 key 注冊(cè)進(jìn)去。這三個(gè)時(shí)機(jī)漏一個(gè)就會(huì)出現(xiàn)內(nèi)存泄漏或 select 拿著已關(guān)閉的 socket 注冊(cè)導(dǎo)致不可預(yù)期的行為。寫(xiě)過(guò)幾次這種代碼的人都知道崩潰往往不是發(fā)生在主邏輯而是發(fā)生在清理路徑上——清理代碼寫(xiě)不好連接一多就出問(wèn)題。4.3 發(fā)送數(shù)據(jù)的緩沖區(qū)策略不要直接阻塞 send單線程模型下send 也可能阻塞嗎如果 socket 是阻塞模式發(fā)送緩沖區(qū)滿時(shí) send 會(huì)卡住整個(gè)線程這對(duì)多端口服務(wù)來(lái)說(shuō)是致命的。前面把接收分支設(shè)為非阻塞了發(fā)送分支同樣也要注意send 返回 SOCKET_ERROR 且 WSAEWOULDBLOCK 時(shí)說(shuō)明內(nèi)核發(fā)送緩沖區(qū)已滿數(shù)據(jù)還沒(méi)發(fā)完。如果這時(shí)直接丟棄剩余數(shù)據(jù)TCP 層會(huì)切掉半個(gè)包對(duì)端協(xié)議棧直接亂掉如果原地等一會(huì)兒再 retry則可能阻塞線程幾十毫秒等于把整個(gè)多端口服務(wù)都拖慢了。更穩(wěn)的做法是把“沒(méi)發(fā)完的數(shù)據(jù)”緩存到 ClientContext.sendBuf 里在 select 循環(huán)里單獨(dú)為這些 socket 注冊(cè)“可寫(xiě)”事件select 的第三個(gè)參數(shù)可寫(xiě)時(shí)再?gòu)?sendBuf 里取數(shù)據(jù)發(fā)出去。這套結(jié)構(gòu)叫“write buffer 可寫(xiě)事件驅(qū)動(dòng)”在單線程 select 模型里是標(biāo)準(zhǔn)解法。但實(shí)際項(xiàng)目中如果業(yè)務(wù)比較輕、數(shù)據(jù)量不大也有一個(gè)簡(jiǎn)化方案把 client socket 設(shè)成非阻塞后send 用循環(huán)發(fā)送直到全部寫(xiě)完或返回 WSAEWOULDBLOCK返回 WSAEWOULDBLOCK 時(shí)把剩余數(shù)據(jù)放緩存。數(shù)據(jù)量小的時(shí)候dev 階段先簡(jiǎn)化為“寫(xiě)失敗就重試再失敗就斷開(kāi)”能把 main path 跑通后面再補(bǔ)發(fā)送隊(duì)列。問(wèn)題是要知道這個(gè)簡(jiǎn)化方案的邊界只要數(shù)據(jù)量超過(guò)內(nèi)核發(fā)送緩沖這個(gè)方案就會(huì)頻繁觸發(fā)重試進(jìn)而影響同一線程里其他端口的響應(yīng)。int SendNonBlock(SOCKET s, const char* data, int len) { int totalSent 0; while (totalSent len) { int n send(s, data totalSent, len - totalSent, 0); if (n 0) { totalSent n; } else if (n SOCKET_ERROR) { int err WSAGetLastError(); if (err WSAEWOULDBLOCK) { // 發(fā)送緩沖區(qū)滿把余下數(shù)據(jù)緩存等可寫(xiě)事件再發(fā) return totalSent; // 外部把剩余部分存到 sendBuf } else if (err WSAECONNRESET || err WSAECONNABORTED) { return -1; // 連接已壞直接清理 } else { return -1; } } } return totalSent; }這里返回“已發(fā)送字節(jié)數(shù)”而不是返回 bool是因?yàn)檎{(diào)用方需要知道還剩多少數(shù)據(jù)要緩存。如果返回 -1 說(shuō)明連接已經(jīng)不可用調(diào)用方要觸發(fā) CleanupClient。這個(gè)函數(shù)在多端口場(chǎng)景下可以直接復(fù)用給任何端口的數(shù)據(jù)發(fā)送。5. 端口多起來(lái)的坑select 常見(jiàn)問(wèn)題與排查清單5.1 bind 報(bào) 10048端口被占用但你要找的是 PID 而不是重啟程序現(xiàn)象程序啟動(dòng)時(shí) bind 返回 SOCKET_ERRORWSAGetLastError() 得到 10048WSAEADDRINUSE。初學(xué)者第一反應(yīng)是改端口或重啟程序但這往往掩蓋了一個(gè)事實(shí)你根本沒(méi)找到真正占用端口的進(jìn)程。Windows 平臺(tái)排查這個(gè)問(wèn)題的最快方法是在命令行執(zhí)行netstat -ano | findstr 10048把 10048 換成具體端口最后一列是占用進(jìn)程的 PID然后打開(kāi)任務(wù)管理器按 PID 找到那個(gè)進(jìn)程確認(rèn)是不是你自己程序上次沒(méi)退干凈的殘留或者是某個(gè)服務(wù)端口和你沖突。原因最常見(jiàn)的就兩類。一個(gè)是程序上次崩潰或 CtrlC 強(qiáng)制終止沒(méi)來(lái)得及 closesocket端口處于 TIME_WAIT 狀態(tài)另一個(gè)是系統(tǒng)中其他軟件已經(jīng)占用了這個(gè)端口。解決辦法對(duì)應(yīng)也有兩類代碼里加 SO_REUSEADDR第 2 章已寫(xiě)過(guò)能消除 TIME_WAIT 這一類的 bind 失敗如果是其他進(jìn)程占用要么改端口要么停掉對(duì)方。注意SO_REUSEADDR 不是萬(wàn)能藥它只對(duì) TIME_WAIT 狀態(tài)有效對(duì)正在 LISTEN 的端口占用無(wú)能為力——如果另一個(gè)進(jìn)程正監(jiān)聽(tīng)這個(gè)端口你 bind 依然報(bào) 10048。5.2 select 返回 SOCKET_ERROR 但錯(cuò)誤碼是 0 或 WSAEINTR重啟和信號(hào)中斷的處理現(xiàn)象select 返回 SOCKET_ERROR但用 WSAGetLastError() 查出來(lái)的值是 0 或者 10004WSAEINTR。很多人看到 select 報(bào)錯(cuò)就直接 break 退出循環(huán)結(jié)果程序跑一段時(shí)間后莫名其妙退出沒(méi)有任何日志線索。這屬于單線程循環(huán)里最常見(jiàn)的“假錯(cuò)誤”。WSAEINTR 在 Windows 上出現(xiàn)頻率不高但確實(shí)存在——比如另一個(gè)線程調(diào)用了 TerminateThread或者某些系統(tǒng)服務(wù)觸發(fā)了一個(gè)軟中斷select 的阻塞等待被打斷。原因select 是一個(gè)阻塞等待原語(yǔ)當(dāng)它所在的線程被系統(tǒng)或第三方代碼“打斷”比如調(diào)試時(shí)收到 CtrlC或程序里用了消息鉤子內(nèi)核就會(huì)讓它返回 SOCKET_ERROR并把錯(cuò)誤碼設(shè)置成 WSAEINTR 或 0。這不是網(wǎng)絡(luò)錯(cuò)誤也不代表你的選擇和邏輯有 bug更不代表連接出了故障。解決在 select 的錯(cuò)誤分支里只對(duì) WSAEINTR 或 0 做 continue 重試其余錯(cuò)誤才 break 退出。這段邏輯放在 3.4 節(jié)的 RunEventLoop 里正確寫(xiě)法是if (ret SOCKET_ERROR) { int err WSAGetLastError(); if (err WSAEINTR || err 0) { continue; // 被中斷重新 select } // 真錯(cuò)誤記錄并退出或嘗試重建所有 socket LogError(select fatal error: , err); break; }這個(gè)分支是單線程服務(wù)穩(wěn)定性的關(guān)鍵漏掉它服務(wù)會(huì)“隨機(jī)死亡”極其難排查。日志里如果看到 select error: 0 或 10004首先懷疑代碼是否漏了這個(gè) continue。5.3 超過(guò) 64 個(gè) socket 時(shí) select 失效FD_SETSIZE 的硬限制現(xiàn)象當(dāng) g_listenSockets g_clientSockets 的注冊(cè)數(shù)量超過(guò) 64FD_SETSIZE 的默認(rèn)值后select 表現(xiàn)開(kāi)始詭異——有的連接長(zhǎng)時(shí)間沒(méi)有事件有的連接 recv 到一半超時(shí)監(jiān)聽(tīng)端口偶爾 accept 不到新連接。排查時(shí)看 fd_count發(fā)現(xiàn)它始終小于等于 64但實(shí)際注冊(cè)的遠(yuǎn)不止 64 個(gè)。原因Windows 的 fd_set 結(jié)構(gòu)體里 fd_array 是一個(gè)固定大小的數(shù)組大小為 FD_SETSIZE通常 64。在FD_SET(s, set)時(shí)如果數(shù)組已滿這個(gè) socket 根本不會(huì)被加入集合——不報(bào)錯(cuò)不警告只是靜默丟棄。select 自然永遠(yuǎn)看不到這個(gè) socket。解決辦法有兩個(gè)。第一個(gè)在包含 winsock2.h 之前#define FD_SETSIZE 1024把數(shù)組撐大。注意必須在 include 之前 define且所有 .cpp 文件都要保持一致否則鏈接階段結(jié)構(gòu)體大小不一致內(nèi)存踩踏遲早發(fā)生。第二個(gè)換用 WSAPollWindows Vista 之后的系統(tǒng)都支持它沒(méi)有固定數(shù)組限制是 select 的上位替代。如果你要監(jiān)聽(tīng)的 socket 總量可能輕松破百建議直接上 WSAPoll寫(xiě)法幾乎一樣只是把 fd_set 換成 WSAPOLLFD 數(shù)組。這里給一個(gè)保守建議如果只是固定監(jiān)聽(tīng) 35 個(gè)端口同時(shí)在線連接不超過(guò) 30select FD_SETSIZE 默認(rèn)值足夠如果是一個(gè)稍正式的網(wǎng)關(guān)服務(wù)直接上 WSAPoll省得以后擴(kuò)容時(shí)被這個(gè)限制坑到。5.4 WSAStartup 版本協(xié)商失敗老系統(tǒng)上的怪問(wèn)題現(xiàn)象程序在開(kāi)發(fā)機(jī)Windows 10/11上一切正常部署到客戶某個(gè)老 Windows 7 或瘦客戶端上啟動(dòng)時(shí)報(bào)“WSAStartup failed, code 0x0000276C”或版本校驗(yàn)失敗。原因WSAStartup 請(qǐng)求 2.2 版本但系統(tǒng)上只實(shí)現(xiàn)了 1.1 或 2.0 的 Winsock。這種情況在正常更新的 Windows XP SP3 及之后的系統(tǒng)上都很少見(jiàn)但精簡(jiǎn)版系統(tǒng)、某些國(guó)產(chǎn)定制系統(tǒng)上確實(shí)存在。解決開(kāi)局按 2.2 請(qǐng)求失敗后降級(jí)重試 1.1再失敗才報(bào)錯(cuò)退出。這個(gè)降級(jí)邏輯代碼很簡(jiǎn)單但對(duì)部署環(huán)境不統(tǒng)一的項(xiàng)目來(lái)說(shuō)非常有用。注意 Windows 7 的 Winsock 已經(jīng)是 2.2真正的坑往往在“系統(tǒng)組件損壞”或“服務(wù)被精簡(jiǎn)”這類非典型環(huán)境里所以如果 1.1 也初始化失敗直接提示用戶修復(fù)系統(tǒng)或換機(jī)。bool InitWinsockWithFallback() { WSADATA wsa; if (WSAStartup(MAKEWORD(2, 2), wsa) 0) return true; if (WSAStartup(MAKEWORD(1, 1), wsa) 0) return true; std::cerr WSAStartup failed (both 2.2 and 1.1), code WSAGetLastError() std::endl; return false; }這段降級(jí)不是萬(wàn)能的——如果系統(tǒng) Winsock 棧本身?yè)p壞兩次都失敗那就不是代碼能解決的問(wèn)題了。但絕大多數(shù)情況下降級(jí)到 1.1 可以工作。不過(guò)注意1.1 版本下 select 的函數(shù)簽名還是同一套可以繼續(xù)用。另外建議進(jìn)程退出時(shí)記得 WSACleanup雖然操作系統(tǒng)會(huì)回收資源但顯式清理能讓調(diào)試工具看到的資源占用更干凈。5.5 清理 socket 時(shí)的順序問(wèn)題先移出 fd_set 再 closesocket現(xiàn)象客戶端斷開(kāi)后程序偶發(fā)崩潰崩潰點(diǎn)在 select 調(diào)用附近或 FD_SET 時(shí)。查 dump 發(fā)現(xiàn)訪問(wèn)了無(wú)效句柄。原因socket 在關(guān)閉后SOCKET 句柄可能被系統(tǒng)復(fù)用新的連接可能分配同一個(gè)句柄值。如果你在 fd_set 里還留著舊 socket 的值并在 select 前后對(duì)這個(gè)“幽靈句柄”做 FD_SET 或 FD_ISSET行為取決于系統(tǒng)是否已把該句柄分配給新 socket——如果是新 socket誤操作會(huì)干擾新連接如果是無(wú)效句柄select 可能直接返回 WSAENOTSOCK。解決在 CleanupClient 函數(shù)里必須先把它從所有 fd_set 相關(guān)的數(shù)據(jù)結(jié)構(gòu)中移除再 closesocket絕不能先 close 再移除。另外將已關(guān)閉的 SOCKET 立即賦值為 INVALID_SOCKET 是個(gè)好習(xí)慣可以防止重復(fù)調(diào)用 closesocket 導(dǎo)致二次釋放。void CleanupClient(SOCKET s) { // 1. 從所有管理容器中移除 auto it g_clients.find(s); if (it ! g_clients.end()) g_clients.erase(it); // 2. 再關(guān)閉 socket closesocket(s); // 3. 標(biāo)記為無(wú)效防止后續(xù)邏輯誤用 s INVALID_SOCKET; }這段代碼在 4.1 節(jié)的 recv 返回 0 的分支里調(diào)用。第 2 步和第 3 步的順序不能顛倒closesocket 之后 s 的值已經(jīng)無(wú)效但如果你把它重新賦值之前又有人調(diào)用了 FD_CLR就會(huì)操作一個(gè)已關(guān)閉句柄。還有一個(gè)潛在問(wèn)題如果 fd_set 是在 select 循環(huán)里遍歷時(shí)觸發(fā)的 CleanupClient必須注意遍歷中的索引問(wèn)題——第 5.4 節(jié)的完整代碼里用的是“先標(biāo)記、循環(huán)結(jié)束后統(tǒng)一刪除”的方式這是最保險(xiǎn)的。6. 進(jìn)階技巧把 demo 變成長(zhǎng)跑服務(wù)的三個(gè)關(guān)鍵習(xí)慣把 select 循環(huán)跑通只是第一步真正要投到一個(gè) 7×24 小時(shí)跑的服務(wù)里還需要三個(gè)習(xí)慣。第一個(gè)是“看門(mén)狗”思路單線程模型最怕死循環(huán)或永久阻塞所以 select 的超時(shí)不要設(shè)成 nullptr而是 500ms 到 1s 的有限值每次循環(huán)更新一個(gè)心跳時(shí)間戳主線程之外另起一個(gè)監(jiān)控線程或者用系統(tǒng)定時(shí)器檢查這個(gè)時(shí)間戳超過(guò) 3 秒沒(méi)更新就可以判定事件循環(huán)卡死重啟進(jìn)程或自動(dòng)拉起新實(shí)例。這是單線程架構(gòu)最實(shí)用的保命手段——不需要復(fù)雜 IPC一個(gè)時(shí)間戳就能覆蓋“卡死”這個(gè)最大的風(fēng)險(xiǎn)。第二個(gè)習(xí)慣是日志打點(diǎn)要帶 socket 和端口信息。多端口服務(wù)的排查難點(diǎn)在于“某個(gè)端口的流量異?！钡罩局挥浟?socket還得到處查映射關(guān)系。我一般會(huì)在每次 accept、recv 首包、send 失敗、CleanupClient 的地方打上一行含時(shí)間、端口、socket、事件類型的日志。調(diào)試階段把日志直接打到屏幕線上階段切到文件和滾動(dòng)輸出。這個(gè)習(xí)慣可以解決 80% 的連接異常排查——畢竟你看不到內(nèi)核里的數(shù)據(jù)但能看到每次事件的來(lái)龍去脈。第三個(gè)習(xí)慣是壓測(cè)時(shí)不要只測(cè)“能連通”要測(cè)“連了又?jǐn)唷嗔擞诌B”。多端口單線程模型在長(zhǎng)連接穩(wěn)態(tài)下很容易通過(guò)測(cè)試但真正頻繁出問(wèn)題的場(chǎng)景是大量短連接快速建立和斷開(kāi)的壓力。用 Python 或 C 寫(xiě)一個(gè)簡(jiǎn)單壓測(cè)腳本每分鐘建 100 個(gè)連接、每個(gè)連接收發(fā) 1KB 數(shù)據(jù)后斷開(kāi)觀察程序內(nèi)存是否持續(xù)增長(zhǎng)socket 泄漏的典型特征、select 是否還能正常返回、端口是否還能 accept。連續(xù)跑 24 小時(shí)所有問(wèn)題都會(huì)現(xiàn)形。// 簡(jiǎn)單的發(fā)送拆包緩存示例把發(fā)送隊(duì)列和可寫(xiě)事件結(jié)合 // 每次 select 返回可寫(xiě)時(shí)檢查發(fā)送隊(duì)列是否有積壓數(shù)據(jù) if (FD_ISSET(s, writeSet)) { auto ctx g_clients[s]; if (!ctx.sendBuf.empty()) { int n send(s, ctx.sendBuf.data(), (int)ctx.sendBuf.size(), 0); if (n 0) { ctx.sendBuf.erase(ctx.sendBuf.begin(), ctx.sendBuf.begin() n); } else if (n SOCKET_ERROR WSAGetLastError() ! WSAEWOULDBLOCK) { CleanupClient(s); } } }這段“可寫(xiě)事件 發(fā)送隊(duì)列”是單線程模型處理大量下行數(shù)據(jù)的最終形態(tài)前面的簡(jiǎn)化版 send 循環(huán)命中 WSAEWOULDBLOCK 時(shí)會(huì)留下殘余數(shù)據(jù)正是這段代碼需要接管的部分。實(shí)際做的時(shí)候把這段邏輯放在 select 循環(huán)里對(duì) client socket 的處理分支后即可。這里每一步落地的細(xì)節(jié)都是我自己在 Windows 上調(diào)多次踩出來(lái)的select 函數(shù)的第一個(gè)參數(shù)直接寫(xiě) 0、重建 fd_set 的位置、WSAEWOULDBLOCK 必須當(dāng)作正常返回處理、WSAPoll 才是破 64 限制的正解——這些不是教科書(shū)里能一眼看明白的不親手跑一遍源碼很容易在莫名其妙的地方浪費(fèi)時(shí)間。希望這篇筆記能幫你繞開(kāi)那些我走過(guò)的彎直接讓多端口單線程服務(wù)在你自己的工程里跑起來(lái)。本文還有配套的精品資源點(diǎn)擊獲取