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