简介这份C#高并发SOCKET服务器与客户端完整工程实例源码面向希望深入理解网络通信底层机制的.NET开发者尤其适合需要掌握多线程与异步编程模型的进阶学习者。资源包共431个文件约4.1MB以cs源代码、csproj项目文件、sln解决方案、resx资源文件及dll动态库为主同时包含pas、dfm等Delphi相关文件便于跨语言对照参考。工程涵盖服务器端Socket监听、连接处理、数据收发与异常捕获以及客户端连接管理、同步异步发送接收和界面集成等关键模块并可能同时提供多线程与async/await两种并发策略实现。已有987人学习下载读者可通过阅读源码、运行调试直观理解TCP/IP通信流程与高并发场景下的性能优化思路是学习C#网络编程与并发处理的实用参考范例。1. 从一份 C# 高并发 SOCKET 源码说起它到底解决了什么问题很多人第一次拿到「C#高并发SOCKET服务器和客户端完整工程实例源码」这类工程时第一反应是打开 sln 直接 F5然后发现服务端一跑起来 CPU 就飙到 100%客户端连上几十个就开始丢包。这不是代码写得烂而是 Socket 编程里最典型的认知断层把「能连上」当成了「能扛住」。这份工程真正要解决的核心问题是在 .NET 平台上用异步 Socket 模型撑起成千上万条长连接同时保证消息不粘包、不乱序、不把线程池打爆。它适合两类人一类是正在做 C# 上位机、工控采集、IM 长连接网关的开发者另一类是写过同步 Socket 但一上量就翻车的工程师。热搜里「C# socket bigging receive 回调」「高并发 IM」「windows socket error 通常每个套接字地址只允许使用一次」这些词恰好对应了这份工程里最值得拆的三块异步接收模型、连接管理、端口复用。下面我按「先立住模型再动手复现最后讲坑」的顺序把这份工程里真正值钱的部分讲透。2. 高并发 SOCKET 的模型选型为什么不用同步阻塞和 BeginReceive2.1 同步阻塞、BeginReceive、SocketAsyncEventArgs 三代模型的真实差距C# 的 Socket 编程大致经历了三代写法。第一代是Socket.Accept()NetworkStream.Read()的同步阻塞每个连接占一个线程1000 个连接就是 1000 个线程线程上下文切换的开销直接把 CPU 吃光这也是很多人写「高并发」却只能跑几十个连接的根本原因。第二代是BeginReceive/EndReceive的 APM 异步模型热搜里那个「C# socket bigging receive 回调」说的就是它。它确实不占线程了但每次收发都要分配IAsyncResult高频小包场景下 GC 压力巨大而且回调嵌套深了以后代码几乎没法维护。第三代是SocketAsyncEventArgs简称 SAEA它把异步操作对象做成可复用的池一次分配反复使用配合MemoryPool或ArrayPool管理缓冲区才是真正意义上的高并发模型。这份工程如果要在生产环境扛量主线必须是 SAEABeginReceive 只能作为理解异步思想的过渡。选型上我一般会这样判断连接数在 200 以内、消息频率低同步阻塞完全够用别过度设计连接数上千、消息频繁直接上 SAEA不要用 BeginReceive 硬撑因为它的 GC 抖动在压测时非常明显。SAEA 的核心优势在于「一个事件对象可以复用」服务端只需要维护一个SocketAsyncEventArgsPool每个连接从池里借一个用于接收用完归还避免了每次 IO 都 new 对象。2.2 用 SocketAsyncEventArgs 搭一个可复用的接收循环下面这段是服务端接收循环的最小骨架也是这份工程里最该先跑通的部分。它演示了如何用 SAEA 完成一次异步接收并在回调里重新投递下一次接收形成持续循环。// 服务端基于 SocketAsyncEventArgs 的接收循环骨架 private void StartAccept(Socket listenSocket) { var acceptArgs new SocketAsyncEventArgs(); acceptArgs.Completed OnAcceptCompleted; // 投递异步 Accept返回 false 表示同步完成需手动触发回调 if (!listenSocket.AcceptAsync(acceptArgs)) OnAcceptCompleted(null, acceptArgs); } private void OnAcceptCompleted(object sender, SocketAsyncEventArgs e) { if (e.SocketError SocketError.Success) { var client e.AcceptSocket; client.NoDelay true; // 关闭 Nagle 算法降低小包延迟 var token new ClientToken(client); BeginReceive(token); // 为新连接启动接收循环 } // 关键重新投递 Accept否则只能接受一个连接 e.AcceptSocket null; ((Socket)sender).AcceptAsync(e); } private void BeginReceive(ClientToken token) { var args token.RecvArgs; args.SetBuffer(token.Buffer, 0, token.Buffer.Length); if (!token.Socket.ReceiveAsync(args)) ProcessReceive(token, args); // 同步完成时手动处理 }逻辑说明AcceptAsync返回false表示操作同步完成此时不会触发Completed事件必须手动调用回调这是 SAEA 最容易翻车的地方漏了这一步就会出现「只能连一个客户端」的玄学现象。NoDelay true关闭 Nagle 算法对 IM、工控这类小包高频场景很关键否则消息会被攒着一起发延迟肉眼可见。参数上token.Buffer建议用ArrayPoolbyte.Shared.Rent(4096)获取不要每个连接 new 一个 byte 数组连接上万时内存会成倍膨胀。ReceiveAsync同样要判断返回值同步完成时直接进处理逻辑不能干等回调。2.3 连接对象池与缓冲区管理别让 GC 成为瓶颈高并发场景下真正拖垮服务的往往不是网络 IO而是 GC。每来一个连接就 new 一个SocketAsyncEventArgs、new 一个 byte 缓冲区连接数一上来Gen0 回收频率飙升表现为周期性卡顿。常见做法是维护一个ConcurrentBagSocketAsyncEventArgs作为对象池连接建立时借出断开时归还并重置状态。缓冲区用ArrayPoolbyte租借归还时记得ArrayPool.Return否则池子形同虚设。这份工程里如果看到new byte[1024]出现在接收路径上基本可以判定它没做池化压测到几千连接就会露馅。参数上单个接收缓冲区 4KB 是通用值如果业务消息普遍大于 4KB要么调大缓冲区要么在应用层做分片重组不要指望一次ReceiveAsync就能收完一条完整消息。3. 粘包拆包与消息协议高并发下最容易翻车的一环3.1 为什么 TCP 一定会粘包以及三种主流拆包方案TCP 是字节流协议它只保证字节顺序不保证消息边界。发送方连续Send两次接收方可能一次Receive就全收到了也可能一条消息被拆成两次收到这就是粘包和拆包。热搜里「C# socket bigging receive 回调」的很多困惑其实都源于此回调触发一次不代表收到一条完整消息。主流拆包方案有三种固定长度、分隔符、长度前缀。固定长度简单但浪费带宽适合定长指令分隔符如\r\n适合文本协议但消息体内不能出现分隔符长度前缀最通用消息头固定 4 字节存消息体长度工业级协议基本都用它。这份工程如果要做通用长连接长度前缀是首选。3.2 长度前缀协议的服务端解析实现下面这段演示如何在接收回调里做粘包处理把收到的字节先追加到连接自己的缓冲区然后循环判断是否凑够一条完整消息。// 长度前缀协议解析4 字节大端长度 消息体 private void ProcessReceive(ClientToken token, SocketAsyncEventArgs e) { if (e.BytesTransferred 0 e.SocketError SocketError.Success) { // 1. 把本次收到的数据追加到连接缓冲区 token.Stream.Write(token.Buffer, 0, e.BytesTransferred); // 2. 循环解析直到凑不齐一条完整消息 while (true) { var data token.Stream.GetBuffer(); var len token.Stream.Length; if (len 4) break; // 连长度头都不够等下次数据 int bodyLen (data[0] 24) | (data[1] 16) | (data[2] 8) | data[3]; if (len 4 bodyLen) break; // 消息体没收全继续等 var body new byte[bodyLen]; Array.Copy(data, 4, body, 0, bodyLen); Dispatch(token, body); // 交给业务层处理 // 3. 移除已消费的字节保留剩余半包 token.Stream.Position 0; token.Stream.Write(data, 4 bodyLen, (int)(len - 4 - bodyLen)); token.Stream.SetLength(len - 4 - bodyLen); } BeginReceive(token); // 继续投递下一次接收 } else { CloseClient(token); // 连接断开或出错清理资源 } }逻辑说明token.Stream是每个连接私有的内存流用来暂存半包数据不能用全局共享的缓冲区否则多连接会互相污染。长度头用大端解析是为了跨平台一致C# 默认小端网络传输统一用大端是行业惯例。while(true)循环保证一次收到多条消息时能全部解析出来这是很多人漏掉的一步导致消息积压。参数上bodyLen必须做上限校验比如超过 1MB 直接断开连接否则恶意客户端发一个超大长度头就能把服务端内存撑爆这是血泪经验。Dispatch里如果业务处理耗时不要直接在 IO 回调线程里做丢到业务线程池否则会阻塞接收循环。3.3 客户端发送端如何配合协议客户端发送时同样要按长度前缀封装不能直接Send原始字节。常见做法是提供一个SendMessage(byte[] body)方法内部先写 4 字节长度头再写消息体并且用发送队列串行化避免多线程同时Send导致字节交错。如果客户端也要高并发发送建议用独立的发送 SAEA 对象和接收对象分开不要共用一个否则收发状态会互相干扰。参数上发送队列建议设一个上限超过就丢弃或阻塞防止客户端疯狂发消息把服务端打挂。4. 避坑与排查高并发 SOCKET 工程里最常见的 5 个翻车现场4.1 端口被占用windows socket error 通常每个套接字地址只允许使用一次现象服务端重启时报「通常每个套接字地址(协议/网络地址/端口)只允许使用一次」。原因上一次进程的监听 Socket 处于 TIME_WAIT 状态端口还没释放。解决在Bind之前设置listenSocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true)让新 Socket 可以复用处于 TIME_WAIT 的端口。注意这个选项要在Bind之前调用之后设置无效。4.2 只能连一个客户端AcceptAsync 返回 false 没处理现象服务端启动后只能接受一个连接第二个连接一直挂起。原因AcceptAsync返回false时表示同步完成不会触发Completed回调代码里只依赖回调就会漏掉后续 Accept。解决每次调用AcceptAsync后判断返回值为false时手动调用一次完成处理逻辑并在处理完后重新投递AcceptAsync。4.3 消息乱序或丢失多线程同时操作同一个 Socket现象压测时偶发消息内容错乱或者部分消息丢失。原因多个线程同时对同一个 Socket 调用Send字节流交错或者接收缓冲区和业务处理共享了可变状态。解决每个连接的发送操作串行化用发送队列加锁或专用发送线程接收缓冲区每个连接独立业务处理不要直接引用 IO 缓冲区先拷贝出来。4.4 CPU 飙满回调里做了耗时业务现象连接数一上来 CPU 直接 100%但网络吞吐并不高。原因在Completed回调里直接做数据库查询、文件读写等耗时操作阻塞了 IO 线程。解决回调里只做协议解析把业务消息丢进Channel或线程池异步处理IO 线程尽快返回继续投递下一次接收。4.5 内存持续增长SAEA 和缓冲区没归还池现象服务运行几小时后内存占用持续上涨GC 回收后也降不下来。原因连接断开时没有把SocketAsyncEventArgs归还对象池或者ArrayPool租借的缓冲区没有Return。解决在连接关闭的统一入口里做资源归还用try/finally保证异常路径也能归还并且归还前重置SAEA的Completed委托和缓冲区引用避免池里对象持有已关闭连接的引用。5. 压测验证与进阶怎么确认你的 SOCKET 服务真的扛得住写完代码只是开始能不能扛住必须靠压测说话。我一般会分三步验证第一步用telnet或简单脚本连 100 个连接确认连接建立和断开没有泄漏第二步用压测工具模拟 1000 个长连接每个连接每秒发 10 条小消息观察 CPU、内存、GC 次数和消息延迟第三步做异常测试包括客户端强制断线、发送超大消息、半包后停止发送确认服务端不会崩、不会内存泄漏。压测时重点看三个指标GC Gen0回收频率高并发下应保持平稳频繁回收说明有临时对象、线程池队列长度持续增长说明业务处理阻塞了 IO、连接断开后内存是否回落不回落就是资源没释放。进阶技巧上有两个方向值得投入。一是把接收和发送彻底分离接收 SAEA 和发送 SAEA 各自独立池化避免收发互相影响二是引入System.IO.Pipelines它内部已经处理了缓冲区的租借和归还配合PipeReader做协议解析比手写内存流更省心代码也更清晰。下面是一个用 Pipelines 做长度前缀解析的片段可以作为从手写缓冲区迁移的参考。// 基于 System.IO.Pipelines 的长度前缀解析 async Task ReadLoop(PipeReader reader) { while (true) { ReadResult result await reader.ReadAsync(); ReadOnlySequencebyte buffer result.Buffer; while (TryReadMessage(ref buffer, out ReadOnlySequencebyte body)) { Dispatch(body.ToArray()); // 解析出一条完整消息 } // 告诉 Pipeline 已消费的位置未消费的会被保留 reader.AdvanceTo(buffer.Start, buffer.End); if (result.IsCompleted) break; } } bool TryReadMessage(ref ReadOnlySequencebyte buffer, out ReadOnlySequencebyte body) { body default; if (buffer.Length 4) return false; // 长度头都不够 Spanbyte lenBytes stackalloc byte[4]; buffer.Slice(0, 4).CopyTo(lenBytes); int len (lenBytes[0] 24) | (lenBytes[1] 16) | (lenBytes[2] 8) | lenBytes[3]; if (buffer.Length 4 len) return false; // 消息体没收全 body buffer.Slice(4, len); buffer buffer.Slice(4 len); // 移动游标准备解析下一条 return true; }逻辑说明ReadAsync返回的buffer可能包含多条消息或半条消息TryReadMessage负责判断并切出完整消息AdvanceTo告诉 Pipeline 哪些字节已经消费、哪些还要保留。参数上stackalloc byte[4]在栈上分配长度头避免堆分配适合高频调用。buffer.Slice是零拷贝操作不会复制数据这是 Pipelines 相比手写内存流最大的优势。迁移时注意Dispatch里如果要用body必须先ToArray或拷贝因为AdvanceTo之后底层缓冲区可能被复用。最后说个我自己的习惯每次改完接收逻辑我都会先跑一个「半包测试」——客户端发一条消息只发一半停 5 秒再发另一半看服务端能不能正确拼出完整消息。这个测试帮我抓出过好几次边界 bug比压测更能暴露协议解析的问题。高并发 SOCKET 没有银弹把模型选对、把资源管好、把边界测到剩下的就是耐心调参。希望帮到你。本文还有配套的精品资源点击获取