简介这份资源面向具备一定C#基础、希望掌握网络编程的开发者聚焦WinForm环境下Socket通信的完整实现重点解决服务端如何同时接纳并管理多个客户端连接的问题。压缩包共59个文件、约113KB以14个cs源码文件为核心配合csproj项目文件、sln解决方案、config配置、resx与resources界面资源以及exe、pdb等编译产物服务端与客户端两个工程结构清晰可直接用Visual Studio打开运行调试。已有112人学习下载。内容覆盖Socket的Bind、Listen、Accept、Connect、Send与Receive等关键方法调用并演示以多线程或异步方式为每个客户端分配独立处理逻辑同时涉及共享资源加锁同步、异常与连接超时处理以及WinForm界面事件绑定等实践要点便于读者对照源码理解多客户端通信的线程模型与排错思路。1. 从一次产线调试说起为什么我还在用 WinForm 写 Socket 服务端去年帮一个做设备集成的朋友排查问题现场六台工控机同时往一台管理机上发心跳管理机上的 WinForm 程序界面直接卡死日志里全是连接超时。翻代码发现服务端用的是同步Accept加单线程处理第一个客户端连上后不撒手后面五个全在排队。这类场景其实特别常见车间里几台扫码枪、几台称重仪、几台 PLC 网关都要把数据汇总到一台 Windows 机器上界面还得实时刷新。这时候 C# WinForm 配 Socket 反而是最省事的选择——不用装运行时环境之外的依赖部署就是拷个 exe现场运维人员双击就能跑。这个项目要解决的就是这件事一个 WinForm 服务端能同时接多个客户端一个 WinForm 客户端能连上去收发消息代码结构清晰到能直接拿去改。适合谁适合需要快速搭一个局域网内多设备数据汇聚界面的开发者也适合刚学完 Socket 基础想看看完整工程怎么组织的人。2. 项目结构拆解服务端与客户端各自管什么2.1 解决方案的目录组织拿到这类项目我第一件事是看解决方案怎么分。典型的组织方式是一个.sln下挂两个 WinForm 项目外加一个可选的公共类库。服务端项目负责监听、管理连接、广播消息客户端项目负责连接、发送、接收显示。公共类库放消息协议定义比如消息类型枚举、序列化辅助方法避免两边各写一份导致协议对不上。SocketDemo/ ├── SocketDemo.sln ├── SocketDemo.Server/ │ ├── Program.cs │ ├── MainForm.cs │ ├── MainForm.Designer.cs │ └── ClientSession.cs ├── SocketDemo.Client/ │ ├── Program.cs │ ├── MainForm.cs │ └── MainForm.Designer.cs └── SocketDemo.Common/ └── MessageProtocol.cs这个结构的好处是职责边界清楚。ClientSession.cs是服务端里最关键的类它封装了单个客户端连接的接收循环和发送方法。很多人写多客户端服务端时把所有逻辑塞进MainForm.cs结果界面代码和网络代码搅在一起加个心跳检测都要改半天。拆出ClientSession之后每个连接是一个独立对象服务端只维护一个ConcurrentDictionarystring, ClientSession增删连接都是字典操作线程安全且好排查。2.2 服务端核心监听与连接管理服务端的启动流程分三步创建监听 Socket、绑定端口、开始异步接受连接。这里用异步AcceptAsync而不是同步Accept是为了不阻塞 UI 线程。每接受一个连接就 new 一个ClientSession丢进字典然后立刻回到接受下一个连接的状态。// MainForm.cs 片段启动监听 private Socket _listener; private readonly ConcurrentDictionarystring, ClientSession _sessions new(); private async void btnStart_Click(object sender, EventArgs e) { int port int.Parse(txtPort.Text); _listener new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); _listener.Bind(new IPEndPoint(IPAddress.Any, port)); _listener.Listen(100); // backlog 设大一点防止瞬时连接被拒 AppendLog($服务端已启动监听端口 {port}); while (true) { Socket clientSocket await _listener.AcceptAsync(); string key clientSocket.RemoteEndPoint.ToString(); var session new ClientSession(clientSocket, key); session.OnMessageReceived Session_OnMessageReceived; session.OnDisconnected Session_OnDisconnected; _sessions[key] session; session.StartReceive(); // 启动该连接的接收循环 AppendLog($客户端接入{key}当前连接数 {_sessions.Count}); } }Listen(100)里的 100 是 backlog 参数表示等待接受的连接队列长度。现场设备集中上电时可能瞬间发起十几个连接backlog 太小会导致部分连接被系统拒绝表现就是客户端报“目标机器积极拒绝”。AcceptAsync返回后拿到的RemoteEndPoint作为字典键格式是IP:端口同一台机器多个客户端时端口不同键不会冲突。session.StartReceive()内部起一个独立任务跑接收循环这样主循环只负责接受不会被某个客户端的数据处理拖慢。2.3 单个连接的接收循环与粘包处理TCP 是字节流没有消息边界。客户端发两条消息服务端可能一次收到一条半也可能两条粘在一起。这个项目里我一般会在ClientSession里维护一个Listbyte缓冲区每次收到数据追加进去然后按协议头里的长度字段切分完整消息。// ClientSession.cs 片段带长度前缀的接收循环 private readonly Listbyte _buffer new(); private const int HeaderSize 4; // 前4字节存消息体长度 private async void ReceiveLoop() { var temp new byte[4096]; try { while (true) { int received await _socket.ReceiveAsync(temp, SocketFlags.None); if (received 0) break; // 对端正常关闭 _buffer.AddRange(temp.Take(received)); ParseBuffer(); } } catch (SocketException ex) { AppendLog($连接异常断开{ex.SocketErrorCode}); } finally { OnDisconnected?.Invoke(_key); } } private void ParseBuffer() { while (_buffer.Count HeaderSize) { int bodyLen BitConverter.ToInt32(_buffer.Take(HeaderSize).ToArray(), 0); if (_buffer.Count HeaderSize bodyLen) return; // 半包等下次 byte[] body _buffer.Skip(HeaderSize).Take(bodyLen).ToArray(); _buffer.RemoveRange(0, HeaderSize bodyLen); string text Encoding.UTF8.GetString(body); OnMessageReceived?.Invoke(_key, text); } }HeaderSize固定 4 字节对应int类型。发送端在消息体前面先写BitConverter.GetBytes(body.Length)再写消息体。ParseBuffer用while而不是if是因为一次接收可能包含多条完整消息必须循环切到不够一条为止。_buffer.Count HeaderSize bodyLen这个判断就是半包处理的关键不够就return等下一次ReceiveAsync。这里有个细节_buffer是Listbyte频繁RemoveRange(0, n)在消息量大时有性能开销常见做法是换成环形缓冲区或者用MemoryStream配合偏移量但演示项目用List足够直观现场每秒几十条消息完全扛得住。2.4 客户端连接与收发客户端这边简单得多一个Socket对象连接成功后起接收循环发送时直接Send。界面上一个文本框显示收到的消息一个输入框加发送按钮。// Client MainForm.cs 片段连接与发送 private Socket _socket; private async void btnConnect_Click(object sender, EventArgs e) { _socket new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); await _socket.ConnectAsync(txtServerIp.Text, int.Parse(txtServerPort.Text)); AppendLog(已连接到服务端); _ Task.Run(ReceiveLoop); } private void btnSend_Click(object sender, EventArgs e) { string msg txtMessage.Text; byte[] body Encoding.UTF8.GetBytes(msg); byte[] packet BitConverter.GetBytes(body.Length).Concat(body).ToArray(); _socket.Send(packet); AppendLog($我{msg}); }ConnectAsync用await是为了连接失败时不卡界面异常会抛到try/catch里提示用户。发送时先拼长度头再拼消息体和服务端ParseBuffer的解析规则严格对应。注意_socket.Send在数据量大时不保证一次发完严格做法是循环发送直到sent累计等于packet.Length演示项目消息短一次Send基本能发完但二次开发如果要传文件这里必须改成循环。3. 跑起来环境、编译与联调步骤3.1 环境准备与项目打开需要 Visual Studio 2019 或 2022装“.NET 桌面开发”工作负载。项目目标框架一般是 .NET Framework 4.7.2 或 .NET 6/8 的 Windows 目标打开.sln后确认两个 WinForm 项目都能还原依赖。如果提示缺少System.Net.Sockets检查目标框架是否选对——.NET Framework 下这个命名空间在System.dll里.NET Core 以上是内置的一般不用额外装包。编译顺序上先编译SocketDemo.Common再编译服务端和客户端。VS 默认会处理项目依赖但如果你手动改过引用右键解决方案选“生成解决方案”最稳妥。生成成功后服务端和客户端的输出目录分别在各自bin/Debug/下。3.2 启动服务端并验证监听先跑服务端。界面上填端口比如8888点“启动”。日志区出现“服务端已启动”后用命令行验证端口确实在监听netstat -ano | findstr :8888能看到LISTENING状态就说明绑定成功。如果报“通常每个套接字地址只允许使用一次”说明端口被占用了换个端口或者用netstat找到占用进程结束掉。防火墙弹窗要允许专用网络访问否则同一局域网的其他机器连不上本机测试不受影响。3.3 多客户端同时连接验证服务端跑着不动开第一个客户端填服务端 IP本机就填127.0.0.1和端口点连接服务端日志应出现“客户端接入”。再开第二个客户端实例——注意不是点两次连接而是把客户端 exe 再启动一份或者 VS 里右键客户端项目选“调试 启动新实例”。两个客户端分别发消息服务端日志能看到两个不同IP:端口键的消息且互不干扰。这一步验证的就是多客户端并发也是这个项目最核心的能力。提示本机测试时两个客户端连同一个服务端RemoteEndPoint的端口不同字典键不会冲突。如果发现第二个客户端连上后第一个掉线检查是不是把_sessions写成了普通Dictionary并在某处误清空或者接收循环里异常处理把整个服务端循环带崩了。3.4 消息收发与日志观察客户端发一条“hello”服务端日志显示来源键和内容服务端如果有广播按钮可以把消息转发给所有客户端。观察日志时重点看三件事连接数是否正确增减、消息内容是否完整没有截断或乱码、断开一个客户端后其他客户端是否正常。乱码通常是两端编码不一致统一用Encoding.UTF8即可。消息截断则回到ParseBuffer检查长度头解析最常见的原因是发送端忘了写长度头或者长度算错。4. 避坑与排查多客户端场景下最容易翻车的几处4.1 界面卡死网络操作跑在 UI 线程上现象点“启动”后窗口无响应或者客户端连接时界面冻结几秒。原因同步Accept、同步Receive或者Connect直接写在按钮事件里阻塞了 UI 线程。解决所有网络等待操作改用async/await版本AcceptAsync、ReceiveAsync、ConnectAsync接收循环用Task.Run起独立任务。跨线程更新界面时用Invoke或BeginInvokeWinForm 控件不是线程安全的直接在接收线程里改TextBox.Text会抛跨线程异常。4.2 连接数上不去backlog 与端口耗尽现象设备集中上电时部分客户端连接被拒报“由于目标计算机积极拒绝无法连接”。原因Listen的 backlog 参数太小或者服务端接受循环里有耗时操作导致来不及Accept。解决Listen(100)起步接受循环里只做new ClientSession和字典写入任何耗时逻辑比如写数据库、弹窗都丢到消息回调里异步处理。另外本机反复测试大量短连接时可能遇到端口耗尽等一会儿或者重启客户端即可生产环境用长连接不会有这个问题。4.3 粘包半包导致消息错乱现象客户端连续快速发几条消息服务端显示的内容串在一起或者解析出乱码。原因接收端假设“一次Receive就是一条完整消息”没有按长度头切分。解决严格按 2.3 节的缓冲区方案处理每次收到数据先追加再循环切分不够一条就等。发送端必须保证长度头和消息体在同一个Send调用里发出或者至少保证顺序不能先发头再隔很久发体否则中间可能被其他线程的发送插队。4.4 断开检测不及时半开连接现象客户端网线拔了或者进程被杀服务端日志迟迟不显示断开连接数一直挂着。原因TCP 对端异常消失时不会立刻发 FIN服务端ReceiveAsync会一直等。解决加心跳机制客户端定时发心跳包服务端记录每个连接最后活跃时间后台定时任务扫描超过阈值比如 30 秒没消息的连接主动Close并移出字典。另一个办法是设置Socket的ReceiveTimeout但异步模式下这个属性不生效心跳是更可靠的做法。4.5 关闭服务端时资源没释放现象点“停止”后端口仍被占用再次启动报地址已在使用。原因只关了监听 Socket没关已建立的客户端连接或者Close之后没等系统释放。解决停止时遍历_sessions逐个Close并清空字典再_listener.Close()最后把引用置null。如果还占用检查是否有接收循环还在跑用CancellationToken通知所有循环退出等任务结束后再关 Socket。5. 二次开发从演示到能用的改造清单这个项目的骨架已经够跑通多客户端收发但真要放到现场用有几处我每次都会改。第一处是消息协议从纯文本升级成带类型的结构比如在长度头后面加一个字节的消息类型0 表示文本、1 表示心跳、2 表示文件块这样服务端可以按类型分流处理不用靠字符串前缀猜。第二处是连接管理加心跳和自动重连客户端断线后定时重试服务端定时清理僵尸连接这两件事不做现场跑一天就会积累一堆死连接。第三处是界面和网络彻底解耦。现在消息回调直接更新界面消息量大时Invoke会成为瓶颈。我的习惯是接收线程只把消息塞进ConcurrentQueue界面用Timer每 100 毫秒批量取出刷新这样 UI 刷新频率可控不会因为消息洪峰卡死。第四处是日志落盘现场出问题不可能一直盯着界面看用StreamWriter按天写文件关键操作连接、断开、异常都记进去排查时直接翻日志比问现场人员靠谱得多。验证改造是否成功我一般跑三个场景一是十个客户端同时连接并每秒各发一条消息持续十分钟看服务端内存是否稳定、界面是否可操作二是随机杀掉几个客户端进程看服务端连接数是否在心跳超时后正确下降三是服务端主动停止再启动看端口能否立即复用、旧连接是否全部释放。这三个场景过了基本就能拿去现场试了。有个血泪教训早期我图省事把ClientSession的Close写在finally里但没加锁结果心跳清理线程和接收循环同时调Close偶发ObjectDisposedException把整个服务端带崩。从那以后我每次写连接关闭逻辑都强制走一遍“先置状态标志、再Interlocked保证只关一次、最后触发断开事件”的流程再也没翻过车。希望帮到你。本文还有配套的精品资源点击获取