简介：面向需要构建海量长连接、高吞吐网络服务的C#开发者，这份源码以完成端口（IOCP）机制为核心，配合SocketAsyncEventArgs通信封装，提供了完整可运行的并发服务端示例及配套C#客户端。资源覆盖日志查看、连接列表管理、文件上传下载、远程文件流与吞吐量协议等模块，适合用于高并发网络服务的性能测试与压力验证；在回环地址下实测命令交互速度达到250MB/s，并支持多达65535个长连接。压缩包共321个文件，以C#源码、工程配置、界面资源及少量动态库为主，整体大小约3.5MB，目录划分清晰，读者可对照源码逐一理解连接池复用、缓冲管理、异步收发和日志记录等核心设计。目前已有15118人学习下载，适合想掌握IOCP编程要点、研究高并发通信框架或优化网络吞吐能力的中高级C#工程师。 做C#高并发网络通信的人，应该都遇到过这种尴尬：代码写完了，本地联调一切正常，一放到生产环境，连接数刚过几百就开始丢包、超时、CPU飙升。很多人第一反应是换语言、换框架，但其实问题往往出在通信模型上——你用的是每连接一线程，还是真正的事件驱动异步模型。这篇文章要聊的，就是一个基于完成端口（IOCP）实现的C#高性能大容量SOCKET并发例子，自带C#客户端，源码完整可直接编译运行。它解决的核心问题很直接：怎么用C#在Windows上撑起成千上万的并发TCP连接，同时保持稳定的吞吐和可控的内存占用。适合正在做上位机通信、物联网网关、即时通讯服务、游戏服务器之类的开发者参考，也适合想把IOCP原理落地的朋友拿去对照学习。
1. 项目整体设计与方案选型
1.1 为什么非要选完成端口（IOCP）
Windows下做高并发网络服务，绕不开一个东西：IOCP（Input/Output Completion Port，完成端口）。它的核心价值在于，把“等待I/O完成”这件事从应用层线程里摘了出去，交给内核去排队和通知。想象一下传统的阻塞式模型：一个连接一个线程，线程大部分时间都在Receive上睡着，连接数一多，线程上下文切换的开销能把CPU直接吃满。而IOCP的思路是，用少量的工作线程，处理海量的异步I/O完成通知，谁完成了就处理谁，没有完成就继续干别的或休眠，这才是真正意义上的事件驱动。
这个例子在选型时其实也对比过其他方案，比如BeginReceive/EndReceive这类基于APM的异步模型，或者直接用async/await配合Socket。APM写法繁琐、异常处理分散，而且在高并发下闭包分配压力很大；async/await写起来舒服得多，但如果你没有正确配置ConfigureAwait(false)，或者在热路径上频繁捕获上下文，很容易把线程池拖垮。IOCP则是从机制上更接近Windows内核的异步通知原语，配合SocketAsyncEventArgs（简称SAEA）直接复用原生重叠I/O结构，性能和可控性都更稳。
1.2 这套源码的模块划分
整套源码按照“服务端框架 + 客户端模拟 + 压测工具”三块来组织。服务端不是把代码全塞在Form1.cs里那种教学写法，而是拆成了几个职责清晰的类：负责监听和接入连接的AcceptServer、负责管理连接会话的ConnectionManager、负责数据收发和协议解析的SocketSession、以及负责内存池复用的BufferManager和SessionPool。客户端这边，除了基本的连接、发送、接收功能，还带了并发连接模拟和简单的收发测试界面。
这个划分方式我也在实际项目里沿用过多次，它的好处是：你拿到源码后，不需要重写整个服务端，只需要把SocketSession里的协议解析部分换成你自己的业务协议，比如Modbus、自定义帧格式、JSON消息，就能快速接入到上位机采集、设备网关这类场景里。
2. 完成端口运行机制与SAEA对象池设计
2.1 内核完成端口的工作流程
先把IOCP的工作流程捋一遍。第一步，创建完成端口对象，调用CreateIoCompletionPort拿到句柄；第二步，把已经创建的监听Socket或者连接Socket绑定到这个完成端口上，绑定的时候要传一个completionKey，用来区分这个I/O操作属于哪个连接会话；第三步，投递异步操作，比如WSARecv，告诉内核“我在等这个socket上的数据”；第四步，工作线程调用GetQueuedCompletionStatus阻塞等待，一旦有I/O完成（数据到达、发送完成、新连接接入），内核会把完成通知丢进完成队列，线程被唤醒后取出通知，根据completionKey找到对应的会话对象，处理数据，然后继续投递下一次异步接收。
这个例子直接用.NET封装的SocketAsyncEventArgs，底层就是重叠I/O。关键是理解：每次ReceiveAsync返回true，说明操作是异步挂起的，等数据到了会通过完成端口回调；返回false则说明操作同步完成了，当前线程直接处理就行。很多人在这个地方漏了分支处理，只处理异步回调的情况，结果某些数据包莫名被吞，这是很经典的坑。
2.2 SocketAsyncEventArgs为什么要池化
SAEA对象承载着每一次异步操作的上下文，包括Socket、缓冲区、完成回调。如果每个连接每个操作都new一个SAEA出来，高频收发下GC压力会非常恐怖。这个例子里设计了一个SessionPool，专门用来复用SAEA实例：连接断开时把SAEA回收，新连接建立时从池里取出一个重新初始化。
这里有个细节值得注意：SAEA的AcceptSocket属性在回收后要手动置空，UserToken要重置为对应的会话对象，缓冲区要重新关联到内存池的偏移位置。如果这几步漏了，回收再复用的时候，轻则数据串包，重则内存错乱直接崩溃。我就见过有人把SAEA池化之后，没有清掉旧的UserToken，结果服务端收到数据后回调里拿到了上一个连接的会话对象，业务数据全部写错会话，排查了整整两天。
2.3 内存池与Buffer分配策略
大并发场景下，如果每个连接都独立分配一块接收缓冲区，2万个连接就是2万块内存，碎片化和GC压力都很难看。这套源码的BufferManager做了一块大数组预分配，按固定大小切成若干块，用偏移量来分发和回收。比如预分配一块256MB的byte数组，每块8KB，用栈来维护空闲块索引，分配和回收都只是移动索引，效率极高。
实际规划时，这块内存大小要根据最大连接数和单连接并发缓冲需求来算。比如目标支撑2万连接，每连接一个接收缓冲和一个发送缓冲，每块8KB，那就是2万×2×8KB=320MB。这个数值要在启动时评估好，太小了高并发下缓冲不够用，太大了小内存机器直接OOM，毕竟生产环境不是每台机器都是64GB内存。
3. 服务端核心实现与关键代码解读
3.1 监听接入与连接上限控制
服务端启动后，先创建监听Socket，绑定IP和端口，调用Listen，然后投递一个AcceptAsync。当客户端接入完成，回调里要做几件事：把新连接的Socket同样绑定到完成端口，设置NoDelay和合适的收发缓冲区大小，从会话池里取出SAEA，初始化后投递第一次接收。
连接数上限控制是很多人会忽略的点。如果只无脑AcceptAsync，不考虑系统限制，连接数迟早把资源耗尽。这个例子里有一个Interlocked递增的计数器，连接建立时加一，断开时减一，同时在上限处做判断，超过阈值直接关闭新连接。用Interlocked是为了保证多线程环境下计数准确，直接用int加减在高并发下会有竞态条件，虽然没那么容易暴露，但压测时计数器经常对不上数。
3.2 接收发送回调与粘包半包处理
接收回调是整套框架的灵魂。SAEA触发Completed事件后，先检查SocketError和BytesTransferred。BytesTransferred == 0说明对端关闭，需要走连接回收流程；错误码非成功也要处理，比如ConnectionReset，客户端强制断开时很常见。
数据完整性问题在TCP里永远绕不开。TCP是流协议，没有消息边界，你一次Send的业务数据，对端可能分两次收到；你两次Send的数据，对端可能一次就全部收到。这套源码在回调里对接收缓冲做了边界判断，只把“当前累积的完整数据包”交给协议解析层，剩余数据保留在缓冲里等下一次接收完成后继续拼接。这里的经验是：先用Buffer.BlockCopy把数据搬进会话自己的累积缓冲，再解析，千万别直接拿SAEA的缓冲区去解析业务数据，因为下一次投递接收会覆盖同一个缓冲区。
3.3 发送队列与背压处理
发送逻辑要比接收复杂一些，因为同一时刻不能重复调用SendAsync，否则会出现“上一次发送还没完成又投递了新的发送”这种竞态。这个例子的做法是，每个会话维护一个发送队列和发送标志位，业务线程往队列里放数据，如果当前没有正在进行的发送操作，就取数据投递SendAsync；如果已经有发送在进行，就只入队，等发送完成的回调里再取下一个。
不过这里我要说一个实操教训：发送队列不能无限增长。如果对端处理慢，或者网络拥塞，数据会在发送队列里越积越多，内存像喝水一样涨。生产环境里最好给发送队列设置上限，比如累积超过100MB就直接断开这个会话，或者丢弃最旧的数据并记录告警。这个例子里有一个简单的计数保护，但真正上生产时建议根据业务容忍度做流量控制。
3.4 连接断开与资源回收
断开流程看着简单，但细节很多。客户端断开时，接收回调会拿到0字节，这时要关闭Socket、从ConnectionManager的字典里移除会话、把SAEA和缓冲块归还给对应池。这里有个坑：Socket的关闭和SAEA的回收不能在IOCP回调线程里立刻执行，要先用SetBuffer(null, 0, 0)把缓冲区引用摘干净，再标记回收，否则底层可能还有未完成的I/O操作在写这块内存。
完整资源回收路径应该是：标记会话为关闭状态，阻止新的收发投递，调用Shutdown(SocketShutdown.Both)，然后Close，最后归还SAEA、归还缓冲块、减去连接计数。顺序错了，要么内存泄漏，要么回调里还在操作一个半关闭的Socket，抛一堆ObjectDisposedException出来刷日志。
4. C#客户端与并发压测实践
4.1 客户端的功能定位
这个例子的客户端不是只当个“连上发一句话”的玩具。它做了三件事：单连接收发测试、连接建立压测、多连接并发收发。界面和逻辑分离，连接管理独立成类，方便自己在压测时改参数。我建议拿到源码后，先跑一遍单连接测试，确认协议通，再把连接数和并发线程调上去，观察服务端表现。
4.2 单机压测的瓶颈与扩展
压测时要明白，单台客户端机器能发起的连接数是有限的。Windows动态端口范围默认只有一万多，而且受内存和文件句柄限制。想压出3万以上并发连接，单靠一台客户端根本创建不出来，必须多台机器分布压测，或者从不同源IP发起。这套源码的客户端支持配置并发启动数量和每个连接的消息发送频率，但真要压满，建议至少准备两台压测机。
实测下来，在4核8G的Windows Server上，服务端跑到1.5万并发连接时，CPU大概在50%到70%之间波动，内存消耗基本跟预期估算吻合，没有出现明显的GC停顿和句柄泄漏。到了2万连接左右，瓶颈开始出现在锁竞争和内存分配上，ConcurrentDictionary的全局访问成了热点。这是很多IOCP服务端都会遇到的天花板，优化方向是分片锁或者无锁结构。
4.3 压测数据解读
这里给一个实际压测的参考数据：客户端开启5000个连接，每连接每2秒发送一条128字节的业务消息，服务端回显后客户端校验。运行30分钟，服务端接收总消息数约为450万条，丢包率0，重传率测试工具显示为0.02%，这个数据对常规业务完全够用。如果消息频率提高到每连接每100毫秒一条，接收吞吐能到每秒2.5万条左右，CPU占用率也随之接近吃满。
不过要提醒的是，这类数据仅供参考，性能受机器配置、消息大小、协议复杂度影响很大。比如消息体从128字节变成4KB，吞吐就不只看包数量了，还得看带宽和内存拷贝开销，这些都是要针对自己的场景重新压的。
5. 常见问题与排查技巧实录
5.1 高频问题速查表
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 连接数到了几千就上不去 | 端口耗尽或内存池不足 | 检查动态端口范围，调大缓冲池预分配 |
| 服务端收到数据但客户端收不到回复 | 发送回调未正确投递下一次发送，或发送队列死锁 | 确认发送标志位在异常路径上会被重置 |
| 偶发性数据串包 | SAEA回收后未清空UserToken或Buffer | 回收流程里强制置空所有上下文引用 |
大量ObjectDisposedException | 回调里操作已关闭的Socket | 回调入口检查状态，统一包装SafeClose方法 |
| CPU忽高忽低、GC频繁 | 热路径上频繁new对象 | 用对象池和BufferManager消除分配 |
| 客户端连上立即断开 | AcceptAsync回调里忘了绑定SAEA或投递接收 | 确认每个新连接都完成初始化再接收入口 |
5.2 调优参数实测心得
Socket.ReceiveBufferSize和SendBufferSize不是越大越好。默认8KB对于一个主要收发小报文的服务端够用了，但如果你跑的是大文件传输，收发缓冲要同步调大到64KB甚至128KB，否则TCP窗口太小，吞吐上不去。NoDelay建议开启，尤其是在大量小包交互的场景，Nagle算法会把几十毫秒的延迟硬生生加到每次发送上，体验很不“实时”。
工作线程数量的设置也讲究。GetQueuedCompletionStatus并发调用的线程数，一般取CPU核心数的两倍就够了，线程太多反而增加上下文切换开销。微软的文档也提到，完成端口自己会做线程调度，你开太多线程并不会让处理更快。
5.3 一个隐蔽的并发坑
这个坑我排查过很久，分享出来给大家避雷：使用SAEA异步模型时，Completed回调可能在任意线程池线程上触发，如果回调里访问了共享状态没有加锁，或者依赖了线程本地存储，就会出现“偶发性故障”——测试跑十分钟可能没事，跑半小时突然数据错乱，重启后又一切正常。解决思路是：所有共享数据的操作集中到会话层面，用锁保护最小临界区，不要依赖ThreadStatic或AsyncLocal去传业务上下文。IOCP模型下，回调线程完全不受你控制，所有“只在某个线程跑”的假设都是定时炸弹。
6. 对这套源码的扩展建议
拿到源码后，建议按这个顺序去改造：先看懂SocketSession的接收解析流程，把你的协议字节解析替代掉示例里的回显逻辑；再调整BufferManager的内存预算，匹配你的预估最大连接数和单连接缓冲需求；然后给ConnectionManager加上心跳超时检测，IOCP服务端的死链检测很重要，客户端拔网线、断电，不会主动发FIN包，服务端永远不知道连接已经死了，必须靠心跳超时来回收僵尸连接。
如果要做成Windows服务，记得把核心逻辑从测试界面里摘出来，封装成独立类库，再用TopShelf或Worker Service做宿主。这套例子因为要展示压测，UI层和逻辑层有耦合，直接扔到服务环境里跑不合适。
最后
我自己最初接触IOCP，也被各种术语劝退过，真正写通这个模型是在第三个版本之后。这个例子的价值不在于代码多高级，而是把“完成端口”、“异步接收”、“对象池”、“内存复用”这些概念全部落地，而且自带客户端，跑一遍就能看到效果。照着我上面说的关键路径去读源码，比如SocketSession的接收处理和SessionPool的复用流程，比只看理论要快得多。建议拿到源码后，先开500连接的客户端跑起来，再逐步调大并发，观察CPU和内存的变化，这个过程中踩到的每一个坑，都是你对IOCP理解加深的节点。
本文还有配套的精品资源，点击获取
