C#高并发Socket框架：基于SAEA与IOCP实现TCP/UDP长连接

搞高并发网络服务的人应该都有过这种体验用TcpListener写个Demo倒是顺手但一旦把连接数往上顶内存、线程、延迟各种问题全冒出来了。这套自研的C#socket源代码最初就是因为业务上要支撑数万台设备的长连接接入、频繁的小报文收发才被逼着在TCP/UDP两个方向上都做了完整的服务端和客户端实现。核心思路很直接在Windows上走SocketAsyncEventArgs底层对应IOCP完成端口坚决不用一个连接占一个线程的老路子在Linux上也能跑同一套逻辑底层映射为epoll。文中涉及的关键技术包括完成端口模型、SAEA对象池、BufferManager缓冲区切片、TCP粘包半包处理、心跳超时扫描、UDP并发会话管理以及一套能直接抄走的断线重连策略。适合正在搞物联网网关、网络游戏长连接、上位机通信或者只是想把C#网络编程水平往上提一截的开发者。1. 项目整体设计与思路拆解1.1 为什么不用TcpListener和NetworkStream非要自己写Socket很多新手写C#网络程序第一个接触的就是TcpListener加NetworkStream阻塞式一收一发配合async/await用起来也像模像样。这套写法在连接数几十个、消息频率不高的时候确实没问题。可一旦连接数上了几千上万问题就暴露了。根本原因在于同步阻塞模型的线程模型每个连接要么分配一个独立线程要么在ReadAsync上挂起。前者最直接一万个连接就是一万个线程单线程栈默认1MB光栈空间就要吃掉10GB虚拟内存线程上下文切换更是能把CPU打满后者虽然用了异步但NetworkStream的ReadAsync在底层依然要经过一层层状态机封装在高频小包场景下对象分配和状态机开销非常可观。所以这套代码直接放弃TcpListener回到Socket类本身用SocketAsyncEventArgs做底层异步收发。原因很简单SAEA是.NET里对Windows完成端口IOCP和Linux epoll封装最薄的一层几乎每次异步操作都直接由内核完成端口通知线程池执行回调中间没有多余的托管层开销。还有一个在设计期就确定的决策服务器端采用长连接模式。虽然有消息确认、有业务握手机制但连接一旦建立就不轻易关闭。短连接每次都要三次握手在高并发下会制造大量TIME_WAIT状态的连接而这种状态的连接在Windows上默认要等240秒才能释放端口资源这是高并发服务端最需要避开的坑。关于端口占用的问题在后面的问题排查部分会专门展开。1.2 选型SAEA异步模型与完成端口IOCP的底层逻辑SocketAsyncEventArgs这套API很多人用了但没真正理解它为什么快。我用一个餐厅的类比来解释传统的同步Socket服务端像一对一服务员一个服务员从头到尾只服务一桌客人客人不结账服务员就一直被占着。这在餐厅人少的时候没问题人一多就只能不断加人加线程。而SAEA加IOCP的模式变成了叫号系统服务员只在有具体事情要做的时候才出现——客人菜到了去传菜客人要结账去算钱。没有事情的时候服务员不去守着任何一桌而是在待命区等待叫号。落实到代码层面SAEA的高性能来源于三点第一SocketAsyncEventArgs对象可以反复使用。完成一次ReceiveAsync之后把Buffer位置和UserToken重新设置就可以再次发起接收操作不需要重新分配任何对象。第二完成通知走的是Completed事件回调由线程池的IOCP线程直接触发不像老的Begin/End异步模式APM要额外创建IAsyncResult对象。第三SAEA在Windows上直接映射到内核的完成端口。数据到达网卡后由内核驱动直接投递到完成端口队列托管线程在端口上等待并取出完成包。整个过程中没有用户态到内核态的反复切换。所有SAEA实例通过一个自定义对象池来管理接收用的SAEA和发送用的SAEA分开各自有独立的池。每个SAEA在被创建时绑定一块独立的缓冲区。缓冲区的分配不是每次new byte[8192]而是通过一个BufferManager从一整块大型数组上切出连续切片这个设计直接影响GC压力后面会有详细说明。1.3 设计目标连接数、吞吐量、延迟三个维度的取舍高并发网络框架不可能在连接数、吞吐量、延迟三个维度同时做到极致必须根据业务场景明确优先级。这套代码的设计定位是连接数优先单机目标10万级长连接吞吐量其次每秒稳定处理5万到10万条小报文取决于报文大小和硬件延迟放在最后不追求微秒级极值但保证绝大多数请求在毫秒级内响应这个定位直接影响了一些关键决策连接管理必须轻量化。每建立一条连接除了Socket句柄和两个SAEA一个接收用、一个发送用之外尽量不额外分配大对象。消息格式必须紧凑。用二进制协议包头定长按需携带负载避免XML/JSON这类文本协议带来的序列化开销。日志必须异步。不能在接收回调里同步写文件日志否则一条慢日志就能阻塞住一个IO线程。有了明确的取舍后面的实现才不会跑偏。这也是我建议每一个要自己做网络框架的人第一步先做的事情把目标写下来。2. 核心细节解析与实操要点2.1 让SocketAsyncEventArgs跑起来的关键配置SAEA的操作类型有三种Accept、Receive、Send。同一个SAEA实例可以切换操作类型但在同一时间只能挂起一种操作。实际代码里接收用的SAEA只做ReceiveAsync发送用的SAEA只做SendAsync监听用的SAEA只做AcceptAsync各司其职。初始化一个接收SAEA有几个关键点var receiveSaea new SocketAsyncEventArgs(); receiveSaea.SetBuffer(bufferManager.RentBuffer(8192)); // 从缓冲池租一块而非new byte[] receiveSaea.UserToken socketState; // 挂上连接状态上下文 receiveSaea.Completed OnIOCompleted; // 统一完成回调UserToken是个object类型用来挂业务上下文。这里特别提醒不要在一个接收SAEA上把UserToken设为null然后在外部用DictionarySocket, State来反查状态。高并发下这种字典查询本身就是锁竞争的热点直接在UserToken上携带状态是最快的方式。真正的坑在于回调逻辑。ReceiveAsync的返回值有两种情况返回true表示操作异步挂起等Completed事件回调返回false表示操作同步完成不需要走事件回调。代码里必须对两种情况都做处理我第一次写时就漏了false分支导致某些小包数据到达时处理逻辑被跳过直接丢了数据。回调里拿到BytesTransferred以后第一件事是判断如果等于0说明对端关闭了连接需要走清理流程。这一步不能偷懒0字节接收在TCP里就是FIN包的信号。2.2 缓冲池到底该不该自己做ArrayPool够用吗处理高并发socket收发时缓冲区是最容易忽视的性能杀手。如果每次ReceiveAsync都new byte[8192]每秒5万条消息就意味着50万次小数组分配GC不炸才怪。.NET标准库提供了ArrayPoolT.Shared很多人直接用这个做缓冲区租借。ArrayPool在简单场景下确实能工作但有一个隐蔽的问题它租出来的数组通常比请求的尺寸大如果每次都要把整个数组交给SetBufferSAEA会从数组头部开始用实际可用空间是不可控的。而且ArrayPool的数组归还时机完全靠自觉一旦某个异步回调没有及时归还池子里的缓冲区就会被慢慢耗尽甚至因为反复借用同一数组导致数据错乱。这套代码里的BufferManager采用的是“大数组切片”方案。初始化时一次分配一大块连续内存比如64MB然后按固定大小默认8192字节切成均匀的切片每条连接从里面取一个切片作为收发缓冲区断开时归还。用int类型的offset记录切片下标配合count告诉SAEA这个缓冲区的有效范围。public sealed class BufferManager { private readonly byte[] _buffer; private readonly int _chunkSize; private readonly Stackint _freeOffsetPool; // 空闲偏移量栈 private readonly int _totalChunks; public BufferManager(int totalBytes, int chunkSize) { _chunkSize chunkSize; _totalChunks totalBytes / chunkSize; _buffer new byte[totalBytes]; _freeOffsetPool new Stackint(_totalChunks); for (int i 0; i _totalChunks; i) { _freeOffsetPool.Push(i * _chunkSize); } } }这里有一个很多人会忽略的点缓冲区的SetBuffer不是每次调用都重新分配内存而是复用了大数组里的某一段。所以SAEA.Buffer始终是指向同一个大数组的某个偏移量GC根本感知不到这些小缓冲区的申请和释放。这才是零GC压力的正确做法。2.3 处理TCP粘包半包一行代码不写全不对的字节流切割TCP是流协议发送方调用两次Send接收方可能一次回调就收齐了反过来说发送方一次Send一个大包接收方可能分三次回调才收完。这就是粘包和半包任何基于TCP的自定义协议都必须处理这个问题。常用的方案有三种固定长度、长度前缀、分隔符。固定长度最简单每个消息都占同样字节数不够就补0缺点是浪费带宽分隔符方案适合文本协议比如HTTP头但消息正文里如果出现同样的分隔符就需要转义处理起来烦长度前缀是最标准的做法在每条消息前加4字节的头部记录后续负载长度。这套代码的帧格式定义为4字节消息头包含负载长度 N字节消息体。接收端处理逻辑遵循以下步骤检查接收缓冲区中可读字节数是否大于等于4读出长度字段判断长度是否合法小于最大帧长如果缓冲区中已有数据不足一个完整帧等待更多数据到达够了一帧后按长度截取消息体交给业务逻辑然后把已消费的字节从缓冲区移除private byte[] TryDecodeFrame(SocketBufferState state) { if (state.ReceivedCount 4) return null; // 连头部都不够 int header BitConverter.ToInt32(state.Buffer, state.Offset); int bodyLength header 0x7FFFFFFF; if (state.ReceivedCount 4 bodyLength) return null; // 头部够了但消息体还没到 byte[] frame new byte[bodyLength]; Buffer.BlockCopy(state.Buffer, state.Offset 4, frame, 0, bodyLength); int consumed 4 bodyLength; state.Consume(consumed); // 把已消费的字节移除未消费的部分向前移动 return frame; }Consume这一步最容易出问题。很多人直接用Array.Copy把剩余数据往前搬频繁搬移本身就有CPU开销但如果不去搬缓冲区会被没处理完的半包数据占满而新数据又不断追加。实测下来把未消费数据移到缓冲区头部的方案虽然简单在消息长度比较均匀的场景下性能完全够用。如果消息长度差异极大可以考虑环形缓冲区但复杂度会上升不是所有项目都值得用。2.4 UDP和TCP的并发处理差异为什么不能照搬UDP和TCP在并发处理上完全是两套逻辑。最大的差别在于TCP是有连接的一个Socket对应一条固定的连接有Accept、有连接建立的过程、有断开通知UDP是无连接的一个Socket面对的是所有远端地址每个数据报都必须附上来源/目标EndPoint。所以不能把TCP那套“预分配SAEA、连接级状态管理”直接套到UDP上。UDP的接收SAEA在每次ReceiveFromAsync之前都要设置一个EndPoint接收来源地址。这个EndPoint必须是一个可复用的实例每次调用前重置。如果每个数据报都new IPEndPoint(IPAddress.Any, 0)同样会造成严重的GC压力。UDP场景下每条“逻辑连接”以远端IP端口为标识需要单独管理状态的话建议用一个ConcurrentDictionaryEndPoint, SessionState来维护。收到数据报时按EndPoint查会话状态存在就处理不存在就新建并加入字典。注意EndPoint作为字典键时会调用Equals做比较IPEndPoint默认实现了值比较可以直接用但不建议频繁创建新的EndPoint实例来查字典。还有一个和TCP完全不同的点UDP数据报有长度上限。IPv4下建议每个数据报不要超过1472字节这是以太网MTU1500减去IP头20和UDP头8的余量。超过这个值IP层会做分片而分片数据报一旦有一片丢失整个数据报就丢了。所以UDP的应用层协议在设计时就要考虑分片与重组或者更稳妥的做法是直接限制单报文的长度。3. 实操过程与核心环节实现3.1 服务端骨架监听、接受连接、收发、断开的完整闭环服务端的主流程我用下面的方式组织。首先创建监听Socket设置NoDelay、绑定地址、开始监听然后用一个专用的acceptSaea循环调用AcceptAsync。_socket new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); _socket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true); _socket.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.NoDelay, true); _socket.Bind(new IPEndPoint(IPAddress.Any, _port)); _socket.Listen(1024); _acceptSaea new SocketAsyncEventArgs(); _acceptSaea.Completed OnAcceptCompleted; StartAccept();StartAccept的核心是用一个循环维持接受操作持续进行。注意AcceptAsync同样有空返回和同步完成两种情况private void StartAccept() { _acceptSaea.AcceptSocket null; bool pending _socket.AcceptAsync(_acceptSaea); if (!pending) { OnAcceptCompleted(this, _acceptSaea); } }OnAcceptCompleted里第一件事不是立即开始收发而是创建连接状态对象、分配接收SAEA和发送SAEA、把UserToken关联好然后再发起第一次ReceiveAsync。每次acceptSaea处理完一个连接后要立刻重新调用StartAccept准备接受下一个连接。这里有一个经验AcceptAsync完成后SAEA的AcceptSocket属性会持有新连接的Socket取出后必须把AcceptSocket设为null否则下次AcceptAsync会直接报错。连接的清理逻辑也很关键。当接收回调收到BytesTransferred 0或者捕获到SocketError时需要依次做以下事情从在线连接字典中移除该连接、把两个SAEA归还到对象池、把缓冲区切片归还到BufferManager、关闭Socket。顺序不能乱特别是缓冲区切片的归还要在SAEA归还之前因为BufferManager要和SAEA解绑。3.2 客户端连接池与断线重连设计客户端的实现容易被人忽略但真正上线后才知道客户端比服务端更容易在各种奇怪的网络环境下暴露出问题。这套代码的TCP客户端没有直接用一个连接实例搞定一切而是实现了一个简单的连接池。连接池的意义在于避免在高频请求场景下反复经历三次握手和四次挥手把已建立的连接循环复用。连接池的容量上限可配置空闲连接超过上限时直接关闭。池的维护用ConcurrentQueueClientConnection来管理空闲连接借出和归还都通过队列操作。断线重连的逻辑单独封装成了一个类核心是一个带退避策略的重试循环private async Task ReconnectLoop(CancellationToken token) { int retryCount 0; while (!token.IsCancellationRequested) { try { var connection new ClientConnection(_host, _port); await connection.ConnectAsync(token); retryCount 0; await connection.WaitForCloseAsync(token); } catch (SocketException ex) { retryCount; int delayMs Math.Min(1000 * (1 retryCount), 30000); _logger.Warn(连接失败延迟重试, ex); await Task.Delay(delayMs, token); } } }这里面最容易被忽视的问题是重试过程中的资源释放。每一次ConnectAsync失败底层Socket都会占用一个端口Windows下大量TIME_WAIT状态的连接会迅速耗尽可用端口范围反过来导致后面的重试全部失败。所以每次连接失败后必须显式调用Dispose并且重试延迟不能太短。3.3 心跳保活与超时扫描避免僵尸连接拖垮服务TCP本身有KeepAlive机制但默认2小时才探活一次对高并发服务来说太迟钝了。服务端想主动发现断开的连接必须自己做应用层心跳。心跳机制的设计分两块客户端需要定期发送心跳包服务端需要记录每条连接的最后活跃时间并定时扫描。实现上我用一个后台Task循环做超时扫描每10秒扫一次把所有最后活跃时间超过60秒的连接标记为超时并断开。这里有个工程上的考量如果扫描逻辑是遍历所有连接然后逐个检查时间10万连接每10秒全扫一次效率其实不高。更优雅的方案是时间轮TimingWheel把连接按时间片分组每次只扫描即将超时的那一组。但时间轮的复杂度不低如果你的连接数在1万以内直接全量扫描完全够用不要为了炫技让代码变得难维护。客户端的心跳包不能占太重的带宽。心跳消息体可以是一个0字节负载的业务帧只需要占用包头长度几十个字节就搞定。心跳间隔可以跟服务端的超时阈值关联一般心跳间隔设为服务端超时阈值的三分之一左右比如服务端60秒超时客户端就每20秒心跳一次这样即使丢两三个心跳包都不会误杀连接。3.4 性能压测与调优数据参考代码写完后必须压测不压测调优都是耍流氓。我拿到的数据是基于一台4核8G的Windows Server.NET 6环境下模拟了5万条TCP长连接每秒钟服务端吞吐在7万条左右的小报文。内存稳定在300MB上下GC频率没有出现明显异常。压测过程有几个关键调优点第一线程池的最小线程数。默认的线程池在工作线程不足时是慢慢注入的高并发突发流量下会出现“线程饥饿”导致的延迟尖刺。所以服务启动时要显式调大最小线程数ThreadPool.SetMinThreads(200, 200);第二禁用Nagle算法。Nagle算法会把小包攒在一起发送减少网络上的小报文数量但对实时性要求高的应用来说延迟会被撑大。在Socket上直接设置NoDelaysocket.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.NoDelay, true);第三内核接收和发送缓冲区的设置。接收缓冲区太小会频繁触发背压太大则占内存。我的经验值接收缓冲区16KB、发送缓冲区8KB。这两个值如果直接用Socket的ReceiveBufferSize和SendBufferSize设置也可以但要记得在绑定之前设置。4. 常见问题与排查技巧实录4.1 连接数上不去的几个隐形瓶颈压测连接数时到了2万左右就上不去了排查了半天代码没毛病最后发现是操作系统的限制在作怪。第一个是ulimit级别的文件句柄限制Linux上默认单进程可打开的文件描述符数量是1024把一个TCP连接对应一个句柄连接数上限根本活不过1024。用ulimit -n 65535提高限制值之后又发现系统级限制还挡了一道。这正是高并发线上环境必须提前检查和调优的问题。第二个是线程池线程数不足。IOCP完成端口处理时线程池里的IO线程数量默认是CPU核数的若干倍在高连接数下不够用。直接通过ThreadPool.SetMinThreads调大是有效手段。第三个是内存估算。一个连接大概消耗2到5KB左右的内存包括Socket缓冲区、SAEA、状态对象10万连接就是200到500MB加上系统本身的占用一定要在部署前估算好内存余量别让连接数被物理内存卡死。4.2 收到数据就崩缓冲区生命周期管理错误最容易踩的坑是缓冲区使用超界。在Completed回调里SAEA.Buffer指向的是BufferManager大数组中的一段这段内存的有效期到“归还”为止。如果回调里把SAEA.Buffer的引用存到某个字段里等回调执行完、SAEA被归还缓冲区之后再去读取读取到的内容可能是其他连接的数据甚至直接抛IndexOutOfRangeException。正确做法有两个其一在回调里把需要的数据拷贝到业务对象或ArrayPool租借的临时数组里再交给业务层处理其二保证业务逻辑的异步处理不会引用SAEA.Buffer。第一条更容易实现实测性能损失也不大因为现代CPU上大块Buffer.BlockCopy的效率极高。另一个崩溃场景是发送操作没有检查SendAsync的返回值。SendAsync返回false表示同步完成此时Completed事件不会触发很多人的发送逻辑写在事件回调里同步完成的时候就被跳过去了。发送侧必须和接收侧一样判断返回值来决定是否走回调。4.3 远程主机强迫关闭连接的处理策略“远程主机强迫关闭了一个现有的连接”这个错误几乎是所有做C#网络开发都遇到过的。它对应SocketError.ConnectionReset本质上是收到对端发来的RST包。触发情况通常是对端进程崩溃、对端发送缓冲区未发送的数据被丢弃、或者中间网络设备主动重置了连接。服务端的正确处理是在接收回调里捕获到ConnectionReset后按正常断开的流程走不要抛异常导致整个线程池出问题。日志里记录一下对端地址和断开时间然后清理资源。客户端的正确处理是触发断线重连。顺带说一个很多人在排查时会忽视的点对端进程崩溃后TCP连接并不会立刻断开如果应用层没有心跳服务端可能要等很久才能发现连接已死。这就回到3.3节说的心跳扫描的必要性。4.4 端口被占用与需要禁用的黏性问题服务端启动时Bind失败抛出“通常每个套接字地址只允许使用一次”的错误Windows错误码10048Linux上对应“Address already in use”原因通常是上一次程序退出时端口还没释放。Windows上的解决方法是绑定前设置ReuseAddresssocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);Linux上SO_REUSEADDR的行为和Windows略有差别它主要解决的是TIME_WAIT状态下端口无法复用的问题。需要注意的是这两个平台的行为不完全等价跨平台代码要分平台判断。客户端这边也有类似的端口问题。大量短连接断开后客户端机器的端口会进入TIME_WAIT状态默认60秒Linux或240秒Windows内不能复用。如果你的客户端经常需要快速建立大量短连接要么走连接池要么把超时时间调短。4.5 客户端连接服务端时常见的“Connection Refused”说到“socket is not connected”和“Connection Refused”也算一对经典错误。前者多是因为客户端Socket还没有成功连接到服务端就调用了Send方法。后者错误码10061则是服务端根本没在监听目标端口。排查顺序很固定先确认服务端进程活着、端口有绑定再确认防火墙没有拦截目标端口最后确认客户端连的IP和端口没写错。实际项目里我遇到过好几次服务端监听了127.0.0.1客户端却连了机器的内网IP结果就是连不上。绑定地址时必须明确监听IPAddress.Any还是具体IP如果要对外提供服务直接监听Any否则调试时会把大量时间浪费在地址不匹配上。这次开发的完整代码里TCP/UDP客户端、服务端四个模块都包含在内。我实际用下来最满意的部分不是某一个具体功能而是整个项目从开始的缓冲区设计、并发控制、心跳扫描、重连机制到最后的压测调优能形成一个完整闭环。任何需要高并发长连接的场景这套骨架都能直接复用改改协议层和业务层的代码就能落地。最后再分享一个小技巧写Socket网络代码时最好从第一行开始就把日志分级埋好。连接建立打Info、连接断开打Info、异常打Warn、业务数据打Debug。高并发问题绝大多数都是“看起来很正常但数据就是不对”这时候只有完整链路日志能帮你快速定位是在哪个环节出了问题。等踩了坑再回头补日志排查代价会高得多。