简介一套基于 Windows Socket 与重叠 I/O 完成例程的 TCP 通信工程示例完整包含 TCPClient 与 TCPServer 两端代码。资源以 Visual Studio 工程形式打包适合 C 网络编程初学者进阶也适合需要处理高并发连接的服务端开发者用来理解异步 I/O 在多线程模型中的实际落地方式。压缩包共 28 个文件除核心 cpp 源码外还包含 vcproj/sln 项目配置、exe 可运行程序、pdb 调试符号等整体仅 6.66MB解压后可直接编译运行。客户端在 connect/send 之后不阻塞等待发送与接收可并行推进服务端通过 bind/listen/accept 接收连接并借助重叠 I/O 完成例程管理多个客户端请求降低同步模型下线程频繁切换带来的性能开销。完整示例展示了重叠 I/O 的初始化、请求投递、完成例程回调等关键步骤便于对照调试并改造为正式服务框架目前已有 284 人学习浏览适合将重叠 I/O 的理论讲解与 Windows 工程实践相结合。 搞Windows网络编程的人迟早会碰到“重叠IO完成例程”这个词。我第一次在项目里真正用完成例程是因为要写一个socket服务端给多个客户端推送文件的工具——连接数不算特别多但每个连接都要持续收发大文件用阻塞IO一个线程卡一个连接连接一多线程切换开销就很明显直接上IOCP又觉得有点重协议逻辑还没写几行光管理完成端口和上下文就够喝一壶。后来把重叠IO的完成例程吃透了才发现这东西刚好处在中间档位既有异步IO的高吞吐又不用像IOCP那样维护一大堆自定义结构体代码直白很多。这篇文章围绕一个实际跑通的重叠IO完成例程工程来展开把核心原理、数据结构、文件收发流程、以及那些文档里不写但实际必踩的坑全捋一遍。适合已经把socket基础API过了一遍、正被异步IO绕晕的初学者也适合想快速在项目里落地完成例程的朋友。我尽量不讲废话直接给你能抄作业的东西。1. 重叠IO完成例程它到底是怎么转起来的1.1 同样是异步为什么我不选IOCP很多人在选型时会在重叠IO和IOCP之间纠结。以我在实际工程里的感受两者的底层机制其实相通都依赖操作系统帮你把IO操作提交后异步完成数据到了内核就主动通知你。区别在于通知方式——IOCP用一个独立的内核对象完成端口集中分发所有IO完成事件你需要在多个线程里循环GetQueuedCompletionStatus去捞事件而完成例程Completion Routine走的是APC异步过程调用队列IO完成时系统把回调函数塞进发起IO那个线程的APC队列线程只要进入可告警等待状态alertable wait回调就会在用户态线程上下文中执行。选型的核心依据是连接规模和编码习惯。连接数几百上千、每个连接都有大量并发IOIOCP是标准答案因为它能用少量线程处理海量完成事件回调在任意线程触发也不怕。但如果场景是几十个连接、每个连接频繁收发大文件完成例程的优势就出来了不需要额外的完成端口对象不需要锁保护共享队列回调天然绑定在发起IO的线程上很多辅助状态直接放线程本地变量都行写起来和同步模型非常像心智负担小一截。1.2 回调到底是在谁的线程里执行的理解完成例程的关键在于明白“发起IO的线程”和“执行回调的线程”是同一个。你调用WSARecv提交一个异步读这个调用会立刻返回IO操作由内核在后台完成。当数据到达、IO完成之后系统不会自动帮你执行回调而是把这个回调函数和参数打包成一个APC对象插入到发起WSARecv那个线程的APC队列中。这个线程如果正处于SleepEx、WaitForSingleObjectEx、WSAWaitForMultipleEvents这类可告警等待状态系统就会在当前线程里执行APC队列里的回调如果线程正在忙别的事情没进入可告警等待那回调就一直躺在队列里直到这个线程下一次主动进入可告警状态。这是一个非常容易踩坑的点——很多新手写了完成例程发现回调根本不触发原因就是主线程在WaitForSingleObject而不是WaitForSingleObjectEx系统没有机会执行APC。用生活化类比来说这就跟你叫了个外卖外卖员到了但你小区门禁不响应他只能在门口等着。你什么时候把门禁打开进入可告警等待外卖什么时候才能送到你手上回调开始执行。2. 工程里的三块基石结构体、API、线程模式2.1 WSAOVERLAPPED和WSABUF一个都不能乱写重叠IO绕不开两个核心结构体。第一个是WSAOVERLAPPED本质上就是Windows的OVERLAPPED它承载一次异步IO的上下文。注意这个结构体在IO未完成前必须一直存活不能是栈上的临时变量否则回调触发时访问到的内存可能已经被覆盖。我习惯把它和缓冲区、socket句柄、操作类型一起塞进一个自定义上下文结构体里用CONTAINING_RECORD宏从WSAOVERLAPPED*反推整个结构体这是工程里最通用也最不容易出错的做法。第二个是WSABUF它本质上就是一个指针加长度typedef struct _WSABUF { ULONG len; // 缓冲区长度 CHAR* buf; // 缓冲区指针 } WSABUF;很多人在提交读写时传了WSABUF但回调里需要使用WSAGetOverlappedResult获取实际传输的字节数这个函数会把WSABUF、WSAOVERLAPPED和lpNumberOfBytesRecvd关联起来。实际操作中我总结出一个经验不要把WSABUF临时构造而是作为上下文结构体的成员随上下文一起分配这样回调里随时可以拿到它也避免悬垂指针。2.2 提交IO的关键APIWSASend和WSARecv完成例程模式的核心就是这两个函数。先看原型int WSASend( SOCKET s, LPWSABUF lpBuffers, // 可以传一个WSABUF数组做散射写 DWORD dwBufferCount, LPDWORD lpNumberOfBytesSent, // 同步完成时返回发送字节数 DWORD dwFlags, LPWSAOVERLAPPED lpOverlapped, LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine // 完成例程 );WSARecv的原型几乎一样只是语义从发送变成接收。当函数返回0时说明IO操作立刻完成了数据已经复制到缓冲区当返回SOCKET_ERROR且WSAGetLastError()为WSA_IO_PENDING时说明IO操作已经提交给内核正在后台执行回调稍后会触发。这里有个很关键的工程细节无论返回0还是WSA_IO_PENDING都必须把lpOverlapped和lpCompletionRoutine传进去不能因为操作同步完成了就省略因为代码路径在编译期无法确定哪一次是异步的漏传会导致回调永远不触发。2.3 可告警等待让APC有机会跑起来完成例程要执行发起线程必须在一定时机进入可告警状态。Windows下常用的函数有函数说明注意点SleepEx(ms, TRUE)线程休眠指定毫秒数适合没有其他事件需要等待的场景WaitForSingleObjectEx(handle, ms, TRUE)等待一个内核对象常用于等待退出事件WaitForMultipleObjectsEx(handles, count, FALSE, ms, TRUE)等待多个内核对象适合同时监听多个socket事件WSAWaitForMultipleEvents(events, count, FALSE, ms, TRUE)Winsock封装的等待和上面的本质相同但能配合WSAEventSelect我自己的习惯是写一个while (!bExit)循环循环里调用WSAWaitForMultipleEvents等待一个“退出事件”超时设为无限或100ms轮询第三个参数是TRUE——这样循环每转一圈都处于可告警状态APC队列里的回调就有机会被系统执行。这种方式干净利落退出时SetEvent即可让循环跳出。3. 从一个文件传输例程看完整实现3.1 服务端主流程监听、接收、提交第一次读这个例程的目标很简单服务端启动后监听端口客户端连上来之后服务端用完成例程的方式把指定文件推给客户端。整个工程我只维护了三个核心文件server.cpp、client.cpp、common.h。先说服务端主流程// 初始化socket并监听 SOCKET listenSock socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); SOCKADDR_IN addr { 0 }; addr.sin_family AF_INET; addr.sin_port htons(9527); addr.sin_addr.s_addr htonl(INADDR_ANY); bind(listenSock, (SOCKADDR*)addr, sizeof(addr)); listen(listenSock, 5); // 主事件循环 while (!bExit) { SOCKET client accept(listenSock, NULL, NULL); if (client INVALID_SOCKET) continue; // 为每个客户端创建一个带上下文的IO对象 PerIoContext* ctx CreateIoContext(client); // 提交第一个异步读等待客户端发来的请求 PostRecv(ctx); }注意这里我把等待退出的事件和探测新连接分开处理了。实际工程中不会在主循环里阻塞accept因为那样主线程就进不了可告警状态。更常见的做法是用WSAEventSelect监听listenSock上的FD_ACCEPT事件把它和退出事件一起放到WSAWaitForMultipleEvents的数组里等到了事件再循环accept。这也是我在例程里最终采用的方式保证主线程永远有机会处理APC回调。3.2 完成例程里怎么切换“收请求”和“发文件”这是全工程最核心的部分。我定义了两个操作类型OP_RECV_REQ表示正在等待客户端请求OP_SEND_FILE表示正在发送文件数据。回调函数根据上下文里的操作类型决定下一步动作。void CALLBACK FileSendCompletionRoutine( DWORD dwError, DWORD cbTransferred, LPWSAOVERLAPPED lpOverlapped, DWORD dwFlags) { PerIoContext* ctx CONTAINING_RECORD( lpOverlapped, PerIoContext, overlapped); if (dwError ! 0) { // 对方关闭或网络错误清理资源 CloseClient(ctx); return; } switch (ctx-opType) { case OP_RECV_REQ: HandleClientRequest(ctx, cbTransferred); break; case OP_SEND_FILE: if (cbTransferred 0) { // 文件发完了 // 发送“文件结束”标记然后关闭 SendFinish(ctx); } else { // 继续发送文件剩余部分 PrepareNextFileChunk(ctx); PostSend(ctx); } break; } }回调里最忌讳的就是做耗时操作。文件分块发送时我定义一个固定大小的缓冲区例程里用的8KB你也可以用64KB测试吞吐差异每次从文件里读一块填进缓冲区构造WSABUF后调用WSASend。下一个块什么时候读不是在回调里同步读而是等下一次OP_SEND_FILE回调触发时再读取并提交下一轮发送。这样IO一直是流水线式的系统在读磁盘时上一轮发送已经完成吞吐要好很多。在实际项目中如果直接用ReadFile读文件再WSASend这个“读文件”动作本身也是阻塞的会影响APC回调执行。更好的方案是把文件句柄也设成重叠模式用ReadFile提交异步读再在ReadFile的完成例程里继续WSASend。但例程里为了聚焦socket重叠IO我先用了阻塞读文件你要追求极致性能可以按上面思路扩展。3.3 客户端怎么收文件才不容易出问题客户端这边的逻辑比服务端简单但也有很多细节。我用同步socket接收每收一块就写一次磁盘直到收到“文件结束”标记。同步接收虽然不够“高级”但作为例程的另一端完全够用也能验证服务端异步发送的数据是否完整。// 客户端发送文件请求比如文件名 send(sock, send:test.bin, 14, 0); // 循环接收数据 std::ofstream outFile(received.bin, std::ios::binary); char buf[8192]; int total 0; while (true) { int n recv(sock, buf, sizeof(buf), 0); if (n 0) break; // 连接关闭 if (n SOCKET_ERROR) break; outFile.write(buf, n); total n; // 长度达到预期文件大小则结束 if (total expectedSize) break; }这里有个非常关键的点recv返回的字节数不代表一个完整的“包”。TCP是字节流协议服务端的8KB分块发过来接收端可能一次recv就收到16KB两块粘在一起也可能只收到2KB一块被拆成好几次。所以客户端如果按固定n8192判断“一块文件数据接收完整”那必然出问题。例程简单起见直接把收到的所有字节都写入文件靠总大小来判断是否结束——这在实际工程里也够用但如果你想在文件后面追加“结束标记”或“校验和”那就需要自己在字节流里做封包解析这是另一个话题。3.4 文件发送的“下一步”到底该怎么做前面提到PrepareNextFileChunk这个函数我再展开讲一下。它做的事情是从文件当前位置读取最多8KB数据到缓冲区更新缓冲区长度然后构造WSABUF并调用WSASend提交异步发送。void PrepareNextFileChunk(PerIoContext* ctx) { DWORD bytesRead 0; BOOL ok ReadFile(ctx-fileHandle, ctx-buffer, FILE_CHUNK_SIZE, bytesRead, NULL); if (!ok) { // 文件读完了准备结束 ctx-opType OP_FINISH; return; } ctx-bufferLen bytesRead; }注意ReadFile是同步读。同步读会阻塞回调线程如果是单线程完成例程模型等于“同一时刻只有一个IO在推进”性能会打折。但正因为完成例程固定在线程上下文中执行你绝不能在回调里无限等待一个永远不会来的事件否则整个连接直接卡死。这是完成例程模型最大的局限——所有回调串行化一旦某个回调阻塞该线程上的所有IO都停摆。所以我在例程里特意把“读完一块就提交发送”压缩到最小化让文件读取和网络发送尽量在同一时间片内完成。4. 实战中踩过的坑和排查思路4.1 WSA_IO_PENDING不是错误是常态第一次写的时候我看到WSAGetLastError()返回WSA_IO_PENDING就当成失败处理结果连接一建立就被我关掉。实际上这个错误码恰恰说明操作被成功提交了正在后台排队执行。你在调试时要区分清楚如果WSASend/WSARecv返回SOCKET_ERROR且错误码是WSA_IO_PENDING这属于正常路径什么都不用做等着回调触发如果是其他错误码如WSAECONNABORTED、WSAENETRESET那才是真出问题了要主动清理连接。4.2 回调不触发多半是线程没进入可告警等待我在实际开发过程中被这个问题坑过整整一个下午。现象很简单client连上服务端服务端提交了异步读但回调就是不执行。后来排查才发现主循环里我用的是WaitForSingleObject而不是WaitForSingleObjectEx系统根本没有机会投递APC。排查方法很简单在回调入口加一条OutputDebugString然后看调试输出里有没有它。没有的话检查三个点一是线程是否有可告警等待函数在跑二是提交IO时的lpCompletionRoutine是否传了有效地址三是lpOverlapped指向的内存是否被提前释放。这三个问题各占我踩坑案例的三分之一。4.3 连接意外关闭的两种表现客户端断开时服务端的回调会收到dwError不为0常见的是WSAECONNRESET或WSAECONNABORTED。我习惯在回调开头统一判断dwError非零就回收上下文、关闭句柄、返回。另一个表现是cbTransferred为0这代表对方正常关闭——在文件发送场景里如果文件还没发完就遇到cbTransferred 0也要当作异常关闭处理。热词里那句“socket connection was closed unexpectedly”基本就是这类问题的典型报错。定位这种问题我的经验是在服务端记录“已发送字节/文件总字节”如果客户端报连接关闭且服务端已发送字节小于文件总大小那基本可以确认是客户端主动断开或网络中间层断链而不是服务端代码逻辑问题。4.4 缓冲区生命周期异步IO最大的坑一个比较隐蔽的错误是提交异步操作后函数返回到主流程ctx指针被错误释放导致回调触发时访问到野指针。Windows不会因为你把重叠结构体的内存释放了就取消IO它只会在IO完成时尝试“写入”这个内存位置。你提前释放了轻则崩溃重则内存被系统回调覆盖、产生诡异数据。解决方法就是我一直强调的per-connection的上下文结构体必须和socket生命周期绑定socket关闭、回调确认不会再触发之后才能释放。我在例程里用一个原子引用计数来做这件事每次提交一个异步IO前AddRef每次回调结束时Release引用计数归零才真正delete上下文。这个技巧在短连接频繁建连断连的场景下特别管用。注意这段代码里接收客户端请求和发送文件使用了同一个上下文结构体如果你在回调里既操作opType又操作buffer一定要确认逻辑上不会冲突。单线程完成例程模型下不会并发基本安全但一旦你后续改成IOCP多线程模型这里就需要加锁或改用队列了。4.5 发送大文件时内存和SSD都扛不住做文件传输例程最常被忽略的是发送方向的背压问题。客户端接收慢、服务端发送快服务端的发送缓冲区会越积越大最终内存暴涨。我在例程里用最简单的背压方案每次只允许一个8KB的异步发送在飞行中也就是说必须等上一次发送的回调返回了才继续提交下一个8KB。这样虽损失了一些吞吐但内存占用是严格可控的。如果你要更大的吞吐可以改成“允许N个8KB同时飞行”但这就需要在回调里维护一个飞行计数复杂度会明显上升。实测下来单飞行块在千兆局域网里大概能跑到六七百兆bps左右对大多数内部工具场景完全够用。5. 最后再聊几句心得重叠IO完成例程这套模型最让我舒服的一点是它保留了同步编程的直觉——你在回调里按顺序处理逻辑不需要像IOCP那样在任意线程里switch上下文。但它的天花板也很明显所有回调都在发起IO的同一个线程上串行执行一旦某个回调里做了阻塞操作比如访问数据库、读大文件整个线程的IO全堵住了。所以选型之前一定要想清楚连接规模和回调里的操作类型。如果你现在面临的选择是“连接数不大、但单连接有持续双向数据流、代码想写得简单直白”完成例程非常合适如果连接数可能涨到几千、甚至需要动态伸缩线程数那还是老老实实上IOCP。工具没有好坏只有匹配不匹配场景。我的server.cpp和client.cpp加起来也就四百多行却把文件推送这个需求完整跑通了这就是完成例程模型省心的最好证明。本文还有配套的精品资源点击获取
重叠IO完成例程实战：原理、踩坑与文件传输实现
简介一套基于 Windows Socket 与重叠 I/O 完成例程的 TCP 通信工程示例完整包含 TCPClient 与 TCPServer 两端代码。资源以 Visual Studio 工程形式打包适合 C 网络编程初学者进阶也适合需要处理高并发连接的服务端开发者用来理解异步 I/O 在多线程模型中的实际落地方式。压缩包共 28 个文件除核心 cpp 源码外还包含 vcproj/sln 项目配置、exe 可运行程序、pdb 调试符号等整体仅 6.66MB解压后可直接编译运行。客户端在 connect/send 之后不阻塞等待发送与接收可并行推进服务端通过 bind/listen/accept 接收连接并借助重叠 I/O 完成例程管理多个客户端请求降低同步模型下线程频繁切换带来的性能开销。完整示例展示了重叠 I/O 的初始化、请求投递、完成例程回调等关键步骤便于对照调试并改造为正式服务框架目前已有 284 人学习浏览适合将重叠 I/O 的理论讲解与 Windows 工程实践相结合。 搞Windows网络编程的人迟早会碰到“重叠IO完成例程”这个词。我第一次在项目里真正用完成例程是因为要写一个socket服务端给多个客户端推送文件的工具——连接数不算特别多但每个连接都要持续收发大文件用阻塞IO一个线程卡一个连接连接一多线程切换开销就很明显直接上IOCP又觉得有点重协议逻辑还没写几行光管理完成端口和上下文就够喝一壶。后来把重叠IO的完成例程吃透了才发现这东西刚好处在中间档位既有异步IO的高吞吐又不用像IOCP那样维护一大堆自定义结构体代码直白很多。这篇文章围绕一个实际跑通的重叠IO完成例程工程来展开把核心原理、数据结构、文件收发流程、以及那些文档里不写但实际必踩的坑全捋一遍。适合已经把socket基础API过了一遍、正被异步IO绕晕的初学者也适合想快速在项目里落地完成例程的朋友。我尽量不讲废话直接给你能抄作业的东西。1. 重叠IO完成例程它到底是怎么转起来的1.1 同样是异步为什么我不选IOCP很多人在选型时会在重叠IO和IOCP之间纠结。以我在实际工程里的感受两者的底层机制其实相通都依赖操作系统帮你把IO操作提交后异步完成数据到了内核就主动通知你。区别在于通知方式——IOCP用一个独立的内核对象完成端口集中分发所有IO完成事件你需要在多个线程里循环GetQueuedCompletionStatus去捞事件而完成例程Completion Routine走的是APC异步过程调用队列IO完成时系统把回调函数塞进发起IO那个线程的APC队列线程只要进入可告警等待状态alertable wait回调就会在用户态线程上下文中执行。选型的核心依据是连接规模和编码习惯。连接数几百上千、每个连接都有大量并发IOIOCP是标准答案因为它能用少量线程处理海量完成事件回调在任意线程触发也不怕。但如果场景是几十个连接、每个连接频繁收发大文件完成例程的优势就出来了不需要额外的完成端口对象不需要锁保护共享队列回调天然绑定在发起IO的线程上很多辅助状态直接放线程本地变量都行写起来和同步模型非常像心智负担小一截。1.2 回调到底是在谁的线程里执行的理解完成例程的关键在于明白“发起IO的线程”和“执行回调的线程”是同一个。你调用WSARecv提交一个异步读这个调用会立刻返回IO操作由内核在后台完成。当数据到达、IO完成之后系统不会自动帮你执行回调而是把这个回调函数和参数打包成一个APC对象插入到发起WSARecv那个线程的APC队列中。这个线程如果正处于SleepEx、WaitForSingleObjectEx、WSAWaitForMultipleEvents这类可告警等待状态系统就会在当前线程里执行APC队列里的回调如果线程正在忙别的事情没进入可告警等待那回调就一直躺在队列里直到这个线程下一次主动进入可告警状态。这是一个非常容易踩坑的点——很多新手写了完成例程发现回调根本不触发原因就是主线程在WaitForSingleObject而不是WaitForSingleObjectEx系统没有机会执行APC。用生活化类比来说这就跟你叫了个外卖外卖员到了但你小区门禁不响应他只能在门口等着。你什么时候把门禁打开进入可告警等待外卖什么时候才能送到你手上回调开始执行。2. 工程里的三块基石结构体、API、线程模式2.1 WSAOVERLAPPED和WSABUF一个都不能乱写重叠IO绕不开两个核心结构体。第一个是WSAOVERLAPPED本质上就是Windows的OVERLAPPED它承载一次异步IO的上下文。注意这个结构体在IO未完成前必须一直存活不能是栈上的临时变量否则回调触发时访问到的内存可能已经被覆盖。我习惯把它和缓冲区、socket句柄、操作类型一起塞进一个自定义上下文结构体里用CONTAINING_RECORD宏从WSAOVERLAPPED*反推整个结构体这是工程里最通用也最不容易出错的做法。第二个是WSABUF它本质上就是一个指针加长度typedef struct _WSABUF { ULONG len; // 缓冲区长度 CHAR* buf; // 缓冲区指针 } WSABUF;很多人在提交读写时传了WSABUF但回调里需要使用WSAGetOverlappedResult获取实际传输的字节数这个函数会把WSABUF、WSAOVERLAPPED和lpNumberOfBytesRecvd关联起来。实际操作中我总结出一个经验不要把WSABUF临时构造而是作为上下文结构体的成员随上下文一起分配这样回调里随时可以拿到它也避免悬垂指针。2.2 提交IO的关键APIWSASend和WSARecv完成例程模式的核心就是这两个函数。先看原型int WSASend( SOCKET s, LPWSABUF lpBuffers, // 可以传一个WSABUF数组做散射写 DWORD dwBufferCount, LPDWORD lpNumberOfBytesSent, // 同步完成时返回发送字节数 DWORD dwFlags, LPWSAOVERLAPPED lpOverlapped, LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine // 完成例程 );WSARecv的原型几乎一样只是语义从发送变成接收。当函数返回0时说明IO操作立刻完成了数据已经复制到缓冲区当返回SOCKET_ERROR且WSAGetLastError()为WSA_IO_PENDING时说明IO操作已经提交给内核正在后台执行回调稍后会触发。这里有个很关键的工程细节无论返回0还是WSA_IO_PENDING都必须把lpOverlapped和lpCompletionRoutine传进去不能因为操作同步完成了就省略因为代码路径在编译期无法确定哪一次是异步的漏传会导致回调永远不触发。2.3 可告警等待让APC有机会跑起来完成例程要执行发起线程必须在一定时机进入可告警状态。Windows下常用的函数有函数说明注意点SleepEx(ms, TRUE)线程休眠指定毫秒数适合没有其他事件需要等待的场景WaitForSingleObjectEx(handle, ms, TRUE)等待一个内核对象常用于等待退出事件WaitForMultipleObjectsEx(handles, count, FALSE, ms, TRUE)等待多个内核对象适合同时监听多个socket事件WSAWaitForMultipleEvents(events, count, FALSE, ms, TRUE)Winsock封装的等待和上面的本质相同但能配合WSAEventSelect我自己的习惯是写一个while (!bExit)循环循环里调用WSAWaitForMultipleEvents等待一个“退出事件”超时设为无限或100ms轮询第三个参数是TRUE——这样循环每转一圈都处于可告警状态APC队列里的回调就有机会被系统执行。这种方式干净利落退出时SetEvent即可让循环跳出。3. 从一个文件传输例程看完整实现3.1 服务端主流程监听、接收、提交第一次读这个例程的目标很简单服务端启动后监听端口客户端连上来之后服务端用完成例程的方式把指定文件推给客户端。整个工程我只维护了三个核心文件server.cpp、client.cpp、common.h。先说服务端主流程// 初始化socket并监听 SOCKET listenSock socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); SOCKADDR_IN addr { 0 }; addr.sin_family AF_INET; addr.sin_port htons(9527); addr.sin_addr.s_addr htonl(INADDR_ANY); bind(listenSock, (SOCKADDR*)addr, sizeof(addr)); listen(listenSock, 5); // 主事件循环 while (!bExit) { SOCKET client accept(listenSock, NULL, NULL); if (client INVALID_SOCKET) continue; // 为每个客户端创建一个带上下文的IO对象 PerIoContext* ctx CreateIoContext(client); // 提交第一个异步读等待客户端发来的请求 PostRecv(ctx); }注意这里我把等待退出的事件和探测新连接分开处理了。实际工程中不会在主循环里阻塞accept因为那样主线程就进不了可告警状态。更常见的做法是用WSAEventSelect监听listenSock上的FD_ACCEPT事件把它和退出事件一起放到WSAWaitForMultipleEvents的数组里等到了事件再循环accept。这也是我在例程里最终采用的方式保证主线程永远有机会处理APC回调。3.2 完成例程里怎么切换“收请求”和“发文件”这是全工程最核心的部分。我定义了两个操作类型OP_RECV_REQ表示正在等待客户端请求OP_SEND_FILE表示正在发送文件数据。回调函数根据上下文里的操作类型决定下一步动作。void CALLBACK FileSendCompletionRoutine( DWORD dwError, DWORD cbTransferred, LPWSAOVERLAPPED lpOverlapped, DWORD dwFlags) { PerIoContext* ctx CONTAINING_RECORD( lpOverlapped, PerIoContext, overlapped); if (dwError ! 0) { // 对方关闭或网络错误清理资源 CloseClient(ctx); return; } switch (ctx-opType) { case OP_RECV_REQ: HandleClientRequest(ctx, cbTransferred); break; case OP_SEND_FILE: if (cbTransferred 0) { // 文件发完了 // 发送“文件结束”标记然后关闭 SendFinish(ctx); } else { // 继续发送文件剩余部分 PrepareNextFileChunk(ctx); PostSend(ctx); } break; } }回调里最忌讳的就是做耗时操作。文件分块发送时我定义一个固定大小的缓冲区例程里用的8KB你也可以用64KB测试吞吐差异每次从文件里读一块填进缓冲区构造WSABUF后调用WSASend。下一个块什么时候读不是在回调里同步读而是等下一次OP_SEND_FILE回调触发时再读取并提交下一轮发送。这样IO一直是流水线式的系统在读磁盘时上一轮发送已经完成吞吐要好很多。在实际项目中如果直接用ReadFile读文件再WSASend这个“读文件”动作本身也是阻塞的会影响APC回调执行。更好的方案是把文件句柄也设成重叠模式用ReadFile提交异步读再在ReadFile的完成例程里继续WSASend。但例程里为了聚焦socket重叠IO我先用了阻塞读文件你要追求极致性能可以按上面思路扩展。3.3 客户端怎么收文件才不容易出问题客户端这边的逻辑比服务端简单但也有很多细节。我用同步socket接收每收一块就写一次磁盘直到收到“文件结束”标记。同步接收虽然不够“高级”但作为例程的另一端完全够用也能验证服务端异步发送的数据是否完整。// 客户端发送文件请求比如文件名 send(sock, send:test.bin, 14, 0); // 循环接收数据 std::ofstream outFile(received.bin, std::ios::binary); char buf[8192]; int total 0; while (true) { int n recv(sock, buf, sizeof(buf), 0); if (n 0) break; // 连接关闭 if (n SOCKET_ERROR) break; outFile.write(buf, n); total n; // 长度达到预期文件大小则结束 if (total expectedSize) break; }这里有个非常关键的点recv返回的字节数不代表一个完整的“包”。TCP是字节流协议服务端的8KB分块发过来接收端可能一次recv就收到16KB两块粘在一起也可能只收到2KB一块被拆成好几次。所以客户端如果按固定n8192判断“一块文件数据接收完整”那必然出问题。例程简单起见直接把收到的所有字节都写入文件靠总大小来判断是否结束——这在实际工程里也够用但如果你想在文件后面追加“结束标记”或“校验和”那就需要自己在字节流里做封包解析这是另一个话题。3.4 文件发送的“下一步”到底该怎么做前面提到PrepareNextFileChunk这个函数我再展开讲一下。它做的事情是从文件当前位置读取最多8KB数据到缓冲区更新缓冲区长度然后构造WSABUF并调用WSASend提交异步发送。void PrepareNextFileChunk(PerIoContext* ctx) { DWORD bytesRead 0; BOOL ok ReadFile(ctx-fileHandle, ctx-buffer, FILE_CHUNK_SIZE, bytesRead, NULL); if (!ok) { // 文件读完了准备结束 ctx-opType OP_FINISH; return; } ctx-bufferLen bytesRead; }注意ReadFile是同步读。同步读会阻塞回调线程如果是单线程完成例程模型等于“同一时刻只有一个IO在推进”性能会打折。但正因为完成例程固定在线程上下文中执行你绝不能在回调里无限等待一个永远不会来的事件否则整个连接直接卡死。这是完成例程模型最大的局限——所有回调串行化一旦某个回调阻塞该线程上的所有IO都停摆。所以我在例程里特意把“读完一块就提交发送”压缩到最小化让文件读取和网络发送尽量在同一时间片内完成。4. 实战中踩过的坑和排查思路4.1 WSA_IO_PENDING不是错误是常态第一次写的时候我看到WSAGetLastError()返回WSA_IO_PENDING就当成失败处理结果连接一建立就被我关掉。实际上这个错误码恰恰说明操作被成功提交了正在后台排队执行。你在调试时要区分清楚如果WSASend/WSARecv返回SOCKET_ERROR且错误码是WSA_IO_PENDING这属于正常路径什么都不用做等着回调触发如果是其他错误码如WSAECONNABORTED、WSAENETRESET那才是真出问题了要主动清理连接。4.2 回调不触发多半是线程没进入可告警等待我在实际开发过程中被这个问题坑过整整一个下午。现象很简单client连上服务端服务端提交了异步读但回调就是不执行。后来排查才发现主循环里我用的是WaitForSingleObject而不是WaitForSingleObjectEx系统根本没有机会投递APC。排查方法很简单在回调入口加一条OutputDebugString然后看调试输出里有没有它。没有的话检查三个点一是线程是否有可告警等待函数在跑二是提交IO时的lpCompletionRoutine是否传了有效地址三是lpOverlapped指向的内存是否被提前释放。这三个问题各占我踩坑案例的三分之一。4.3 连接意外关闭的两种表现客户端断开时服务端的回调会收到dwError不为0常见的是WSAECONNRESET或WSAECONNABORTED。我习惯在回调开头统一判断dwError非零就回收上下文、关闭句柄、返回。另一个表现是cbTransferred为0这代表对方正常关闭——在文件发送场景里如果文件还没发完就遇到cbTransferred 0也要当作异常关闭处理。热词里那句“socket connection was closed unexpectedly”基本就是这类问题的典型报错。定位这种问题我的经验是在服务端记录“已发送字节/文件总字节”如果客户端报连接关闭且服务端已发送字节小于文件总大小那基本可以确认是客户端主动断开或网络中间层断链而不是服务端代码逻辑问题。4.4 缓冲区生命周期异步IO最大的坑一个比较隐蔽的错误是提交异步操作后函数返回到主流程ctx指针被错误释放导致回调触发时访问到野指针。Windows不会因为你把重叠结构体的内存释放了就取消IO它只会在IO完成时尝试“写入”这个内存位置。你提前释放了轻则崩溃重则内存被系统回调覆盖、产生诡异数据。解决方法就是我一直强调的per-connection的上下文结构体必须和socket生命周期绑定socket关闭、回调确认不会再触发之后才能释放。我在例程里用一个原子引用计数来做这件事每次提交一个异步IO前AddRef每次回调结束时Release引用计数归零才真正delete上下文。这个技巧在短连接频繁建连断连的场景下特别管用。注意这段代码里接收客户端请求和发送文件使用了同一个上下文结构体如果你在回调里既操作opType又操作buffer一定要确认逻辑上不会冲突。单线程完成例程模型下不会并发基本安全但一旦你后续改成IOCP多线程模型这里就需要加锁或改用队列了。4.5 发送大文件时内存和SSD都扛不住做文件传输例程最常被忽略的是发送方向的背压问题。客户端接收慢、服务端发送快服务端的发送缓冲区会越积越大最终内存暴涨。我在例程里用最简单的背压方案每次只允许一个8KB的异步发送在飞行中也就是说必须等上一次发送的回调返回了才继续提交下一个8KB。这样虽损失了一些吞吐但内存占用是严格可控的。如果你要更大的吞吐可以改成“允许N个8KB同时飞行”但这就需要在回调里维护一个飞行计数复杂度会明显上升。实测下来单飞行块在千兆局域网里大概能跑到六七百兆bps左右对大多数内部工具场景完全够用。5. 最后再聊几句心得重叠IO完成例程这套模型最让我舒服的一点是它保留了同步编程的直觉——你在回调里按顺序处理逻辑不需要像IOCP那样在任意线程里switch上下文。但它的天花板也很明显所有回调都在发起IO的同一个线程上串行执行一旦某个回调里做了阻塞操作比如访问数据库、读大文件整个线程的IO全堵住了。所以选型之前一定要想清楚连接规模和回调里的操作类型。如果你现在面临的选择是“连接数不大、但单连接有持续双向数据流、代码想写得简单直白”完成例程非常合适如果连接数可能涨到几千、甚至需要动态伸缩线程数那还是老老实实上IOCP。工具没有好坏只有匹配不匹配场景。我的server.cpp和client.cpp加起来也就四百多行却把文件推送这个需求完整跑通了这就是完成例程模型省心的最好证明。本文还有配套的精品资源点击获取
