简介一份面向C#初学者与网络编程入门者的Socket通讯完整源码以WinForm为载体实现服务端与客户端双向消息收发直接打开工程即可运行代码精简清晰重点演示了Socket创建、绑定监听、连接建立及数据收发等关键流程。压缩包共61个文件以cs源代码和可执行程序为主含14个C#源文件、4个exe、4个pdb调试文件另有项目配置、窗体界面资源及解决方案文件整体仅1.17MB结构紧凑便于对照学习。资源将服务端与客户端分为两个独立项目界面与逻辑分层清晰适合快速理解网络通讯原理也能在现有框架上扩展多客户端管理、断线重连、消息分包等功能。已有2914人学习下载如果你需要一份看得懂、能跑通的Socket示例作为开发起点这份资源值得参考。1. C# Socket 网络通讯源码简单清楚往往比花哨封装更值钱做上位机或者嵌入式联调的工程师迟早会撞上一件事设备端已经把数据发到了 TCP 端口你这边要用 C# 把它接住。网上关于 C# Socket 的源码不少但能称得上简单、清楚的反而难找——要么是几百行的超类封装要么只贴一段监听代码客户端重连、粘包、关闭顺序这些真正卡人的细节全被省了。我自己的做法是用最少的类把 Socket 的监听、收发、会话管理跑通核心代码控制在一百行上下让新手能照着敲熟手能直接改。它覆盖设备 TCP/IP 上报、上位机与下位机通讯、局域网消息互通这几类最常见需求前提是你得先搞明白 TCP 的一次完整生命周期。这篇文章就把这套方案从头到尾拆开讲。2. 先选对模式再写代码TCP 与 UDP、同步与异步的取舍2.1 TCP 还是 UDP通讯选型不是玄学是需求表先说结论凡是要求每条消息都不能丢、顺序不能乱的场景选 TCP凡是丢了就丢了、要低延迟的场景选 UDP。设备状态上报、PLC 指令下发、文件传输、多机互联统统走 TCP。音视频流、实时位置、局域网广播发现UDP 更合适。两者的 C# API 差别非常大TCP 对应 TcpListener / TcpClientUDP 对应 UdpClient连接模型完全不同动手前必须先定下来否则写完一半再换协议等于重写。维度TCPUDP连接方式面向连接三次握手无连接可靠性可靠传输丢包重传不可靠丢包不补消息边界字节流无天然边界数据报有天然边界典型场景指令下发、文件、传感器数据音视频、广播、服务发现C# 核心类TcpListener、TcpClientUdpClient如果确定走 TCP还有一个隐藏选择直接用 Socket 还是 TcpClient我的习惯是用 TcpListener / TcpClient它们内部封装了 Socket对新手更友好和异步 API 配合也顺畅。需要精细控制比如设置 KeepAlive、做多路复用时再退回原生 Socket——TcpClient 的 Client 属性也能拿到底层 Socket两个方案不冲突。2.2 同步阻塞还是异步回调新手从同步跑通熟手再看回调这是简单清楚最关键的取舍。同步阻塞最好理解一个 Receive 方法调下去等不到数据就不返回代码执行顺序和人的思维一致。异步模型的性能上限高但回调里到处是线程切换调试时断点跳来跳去新人很容易在回调里直接操作 UI 控件然后报一线程错误。第一版我会坚持同步阻塞加后台线程代码读起来像写作文一行一行往下走。收发数据用 NetworkStream 还是直接用 Socket.Receive我推荐 NetworkStream它可以搭配 ReadAsync 做异步升级也方便接 StreamReader / StreamWriter 做字符串处理。真正要上高性能时换成 SocketAsyncEventArgs 或 ReadAsync并不会推翻现有结构只是把收发调用从线程里挪到回调里。先跑通、再优化这个顺序能让排错量减少一半这也是标题里简单二字的底气。2.3 一次完整的 TCP 生命周期从 Listen 到 Close 的四个阶段写代码之前必须把生命周期在脑子里过一遍否则换个场景就翻车。TCP 通讯在服务端和客户端视角不一样服务端创建监听套接字 → Bind 到 IP 和端口 → Listen 进入监听 → Accept 接受客户端连接 → 拿到连接套接字 → 循环收发 → Shutdown → Close。客户端创建连接套接字 → Connect 到服务端 IP 和端口 → 循环收发 → Shutdown → Close。两个细节最容易被忽略。第一服务端的 Accept 是阻塞的一次 Accept 只处理一个连接多个客户端必须把 Accept 放进 while(true) 循环里反复调用。第二关闭时不能直接 Close要先 Shutdown 表示我不再发送也不再接收了等对端 Read 返回 0 感知到结束再 Close 释放资源。顺序反了对端收不到正常的关闭信号只能靠超时判断整个逻辑就会变得含含糊糊。端口选择上我一般建议在 8000 到 20000 之间挑一个不常用的避开 8080、3306、6379 这些开发端口。监听 IP 用 IPAddress.Any 是全部网卡只想本机访问就换成 IPAddress.Loopback。还有一个环境问题Windows 防火墙首次运行会弹窗询问是否允许开发机上直接点允许部署到客户现场时记得在防火墙入站规则里把这个端口放行否则服务端起来了客户端永远连不上这类问题最浪费调试时间。3. 服务端源码拆解从监听线程到连接会话管理3.1 最小可跑的 TcpListener 服务端三十行建好骨架先来一个真正能跑起来的服务端没有花哨封装只有监听、接受连接、收消息三件事。我一般用控制台项目调服务端逻辑调通了再接上位机界面。using System; using System.Net; using System.Net.Sockets; using System.Text; using System.Threading; class TcpServer { static void Main() { int port 9000; // 监听本机所有网卡的 9000 端口 TcpListener listener new TcpListener(IPAddress.Any, port); listener.Start(); Console.WriteLine($服务端已启动监听端口 {port}); while (true) { // 阻塞等待新客户端接入每 accept 一次返回一个连接 TcpClient client listener.AcceptTcpClient(); // 每个连接开独立线程处理避免阻塞后续客户端接入 Thread t new Thread(() HandleClient(client)); t.Start(); } } static void HandleClient(TcpClient client) { NetworkStream stream client.GetStream(); byte[] buffer new byte[1024]; try { while (true) { // Read 阻塞收到数据才返回返回 0 表示对端已正常关闭 int len stream.Read(buffer, 0, buffer.Length); if (len 0) break; string msg Encoding.UTF8.GetString(buffer, 0, len); Console.WriteLine($收到: {msg}); } } catch (Exception ex) { Console.WriteLine($连接异常: {ex.Message}); } finally { client.Close(); } } }逻辑说明Main 里的 while(true) 承担 Accept 循环每来一个客户端就开一个线程单独收数据多个客户端互不阻塞。HandleClient 里的 while(true) 是收消息循环stream.Read 是阻塞调用有数据才返回返回值是本次读到的字节数为 0 说明对端执行了正常关闭流程。参数说明buffer 固定 1024 字节任何超过这个长度的消息都会被截断这是后面避坑章节要解决的头号问题。端口的选法就是上面说的 8000–20000 区间IPAddress.Any 适合服务器有多块网卡但不确定客户端走哪块的情况生产环境建议明确指定内网 IP减少无关网卡的暴露面。这段代码能做什么局域网内另一台机器上的客户端可以连上来发消息服务端控制台能看到文字。但它不具备主动回复消息和管理多连接的能力这两个能力才是完整源码的核心。3.2 连接会话管理一个客户端一个会话对象别让连接裸奔真实项目里你肯定不会只收消息还要给指定客户端推指令、统计在线数、把某个掉线的连接踢掉。要做到这些必须把 TcpClient 装进一个会话对象统一放到一个集合里管理。我一般这样设计class ClientSession { public string Id { get; set; } // 连接唯一标识一般用 GUID public TcpClient Client { get; set; } // 底层连接 public NetworkStream Stream { get; set; } // 网络流供收发使用 public DateTime LastActiveTime { get; set; } // 最近活跃时间心跳用 public ClientSession(TcpClient client) { Id Guid.NewGuid().ToString(N); Client client; Stream client.GetStream(); LastActiveTime DateTime.Now; } // 给这个客户端发送一条 UTF-8 文本消息 public void Send(string msg) { byte[] data Encoding.UTF8.GetBytes(msg); Stream.Write(data, 0, data.Length); } }逻辑说明会话对象把连接、流、标识、活跃时间绑在一起收到数据或主动发消息时更新 LastActiveTime后续做超时踢人就不用遍历裸连接了。Send 方法把字符串编码成字节再写流是服务端主动推送的基础。服务端要维护一个全局会话字典以 Id 为 keystatic Dictionarystring, ClientSession sessions new Dictionarystring, ClientSession(); static object lockObj new object(); static void AddSession(ClientSession session) { lock (lockObj) { sessions[session.Id] session; } } static void RemoveSession(string id) { lock (lockObj) { sessions.Remove(id); } }逻辑说明字典操作必须加锁因为多个连接线程同时接入、同时断开ConcurrentDictionary 也可以但 lock 写在明处更容易让新手理解线程安全是怎么回事。RemoveSession 在 finally 里调用保证无论正常断开还是异常断开这个连接的引用都会从字典里清掉否则内存泄漏和幽灵连接就来了。3.3 优雅关闭协议收尾比你想的更讲究服务端主动关闭一个连接常见做法是先调用 Shutdown 再 Close。TcpClient 没有直接的 Shutdown 方法需要通过 Client 属性拿到底层 Socket 来操作public void CloseSession() { try { // 通知对端我不再发送也不再接收让对端 Read 返回 0 Client.Client.Shutdown(SocketShutdown.Both); } catch (SocketException) { // 对端可能已断开忽略即可 } finally { Client.Close(); // 真正释放套接字资源 } }逻辑说明Shutdown(SocketShutdown.Both) 发出关闭信号后对端的 stream.Read 会立即返回 0这样客户端代码就知道这是一次正常结束而不是网络错误。直接 Close 会跳过通知阶段对端只能抛 SocketException然后靠异常处理来收拾残局这不太体面。参数说明SocketShutdown 枚举有三个值——Send 表示只关发送Receive 表示只关接收Both 两个都关。对于单连接双向通讯的应用Both 是最稳妥的。这里用 try-catch 包住 Shutdown 是因为对端可能已经强制断开此时再发关闭信号会抛异常属于正常现象。服务端的核心结构到这里就是完整的监听循环负责接客会话字典负责管理CloseSession 负责送客。接下来把客户端补齐顺便解决多客户端协作和粘包问题。4. 客户端源码与多客户端协作把完整两个字落到实处4.1 客户端连接与重连TCP 的假在线陷阱客户端的代码量比服务端少一半但有一个坑是服务端永远遇不到的重连。设备拔网线、服务端重启、笔记本休眠唤醒都会让客户端 Socket 对象看起来还活着实际上已经死了。TCP 的这个特性叫假在线客户端必须自己实现重连机制。class TcpClientHelper { private TcpClient client; private readonly string serverIp; private readonly int serverPort; public TcpClientHelper(string ip, int port) { serverIp ip; serverPort port; } // 尝试连接失败返回 false由调用方决定是否重试 public bool Connect() { try { client new TcpClient(); // 5 秒连接超时防止 Connect 无限阻塞 IAsyncResult result client.BeginConnect(serverIp, serverPort, null, null); bool success result.AsyncWaitHandle.WaitOne(TimeSpan.FromSeconds(5)); if (!success) { client.Close(); return false; } client.EndConnect(result); return true; } catch { client?.Close(); return false; } } }逻辑说明BeginConnect 返回的 AsyncWaitHandle 加 WaitOne 实现了带超时的 Connect这是防止 UI 卡死的常用技巧。原生 Connect 在目标 IP 不可达时可能阻塞几十秒生产环境等不起。连接失败返回 false调用方启动一个定时器重试间隔 3 秒还是 5 秒取决于业务容忍度。参数说明WaitOne 的时间单位是 TimeSpan5 秒适合局域网跨公网可以放宽到 8–10 秒。EndConnect 必须调用即使 result 处已经判断超时也要调用以清理异步资源不调用会有句柄泄漏这种泄漏是看不见的日积月累才出问题。重连的主循环一般是这样的每 5 秒检查一次连接状态如果断开就调用 Connect成功则退出重试循环进主收发流程。判断断开不能只看 TcpClient.Connected 属性——它只表示上次操作时的状态不能反映当下所以下面这句是很多旧代码翻车的根因// 错误示范Connected 是上一次操作的状态快照不是实时状态 if (client.Connected) { /* 不能依赖它判断是否在线 */ }正确做法是定期发送心跳包连续若干次没有收到响应就认定掉线。心跳的具体设计在第 6 章展开。4.2 多客户端如何被服务端区分会话标识与定向发消息客户端发来的消息里不带我是谁服务端怎么知道给谁回答案就是 3.2 里的会话字典。服务端在 ClientSession 里生成了 GUID客户端连上来之后服务端第一件事就是把 Id 发给它后续客户端上发的每条消息服务端在接收线程里通过当前线程对应的会话对象自然知道消息来自哪个连接。服务端收到的每个 TcpClient 在 HandleClient 里就是局部变量把它包成 ClientSession 存进字典后这个连接就和 Id 绑定了。需要给指定设备推送时只要查到会话对象再调 Send 就行static void SendToClient(string sessionId, string msg) { lock (lockObj) { if (sessions.TryGetValue(sessionId, out ClientSession session)) { session.Send(msg); } else { Console.WriteLine($会话 {sessionId} 不存在消息未发送); } } }逻辑说明TryGetValue 一次完成查找和取值比自己 ContainsKey 再取更高效也避免两次访问字典期间连接被移除导致的竞态。发送操作的锁不能省虽然 NetworkStream.Write 本身是线程安全的但多线程同时操作同一流时会互相穿插消息内容会被打乱。实际项目中我给会话起名不叫 ClientSession而是叫 DeviceSession——因为连上来的往往是一块单片机设备或一台工控屏而不是一个客户端。这个命名差别无关技术但能让代码语境更贴近业务建议你也这么做。4.3 数据分包与粘包第一次发送就会踩的坑TCP 是字节流协议它不管你的应用消息从哪里开始到哪里结束。你连续调用两次 Send对端可能一次 Read 就把两段数据全读走了这叫粘包你一次 Send 了 2000 字节对端 buffer 只有 1024分两次才读完这叫半包。两者本质是同一个问题没有消息边界。最简单可行的方案是长度头 消息体每个数据包固定前 4 个字节放消息体长度换算成字节长度不是字符串长度接收端先读 4 字节才知道读多少消息体。发送端这样写public static byte[] PackMessage(string msg) { byte[] body Encoding.UTF8.GetBytes(msg); // 用 BitConverter 将长度转成 4 字节存入头部 byte[] header BitConverter.GetBytes(body.Length); // 头部 消息体 拼成一个完整数据包 return header.Concat(body).ToArray(); }逻辑说明BitConverter.GetBytes(int) 在 .NET 里默认是小端序接收端用同样的 BitConverter.ToInt16 解析头部就能还原长度。两端都同框时没有问题但如果将来要和 C、Java 设备互通必须确认双方的字节序一致不一致就要手动反转。接收端要处理的就复杂一点因为 Read 不保证一次拿完整包static byte[] ReadPacket(NetworkStream stream) { // 第一步先读满 4 字节头 byte[] header new byte[4]; int read 0; while (read 4) { int n stream.Read(header, read, 4 - read); if (n 0) return null; // 对端关闭 read n; } int bodyLen BitConverter.ToInt32(header, 0); // 第二步再读满 bodyLen 字节的消息体 byte[] body new byte[bodyLen]; read 0; while (read bodyLen) { int n stream.Read(body, read, bodyLen - read); if (n 0) return null; read n; } return body; }逻辑说明这里用两层循环凑满数据第一层凑满头部 4 字节第二层凑满消息体。每层循环里都判断了返回 0 的情况——对端断开时不要再继续阻塞等待否则读不完整包就成了死循环。这个读满指定字节数的模式叫读精确长度是 Socket 编程的基本功也是半包问题的标准解法。注意 Read 的第二个参数是从缓冲区的第几个字节开始写第三个参数是最多读几个字节。拆开写是因为一次 Read 可能只读回了头部的一部分剩下的一部分要等下一次 Read。这个细节最容易写错写错了数据错位而且极难排查。5. 避坑手册C# Socket 高频翻车现场与排查5.1 异常目标计算机积极拒绝无法连接 (10061)现象客户端 Connect 时抛 SocketException错误码 10061提示目标计算机积极拒绝。原因服务端没有监听这个端口或者端口被别的进程占用或者客户端连的 IP 和端口拼错了。TCP 对端根本没有进程在 Listen内核会直接回 RST客户端立刻收到拒绝。解决先确认服务端进程还活着再用 netstat 查监听状态netstat -ano | findstr 9000输出里如果没有 LISTENING 行说明服务端没起来或端口不对。如果有 LISTENING 但客户端还是连不上检查防火墙入站规则是否放行了这个端口。还有一种情况是服务端监听了 127.0.0.1而客户端连的是局域网 IP这种连不上和防火墙无关纯粹是监听地址选错。5.2 服务端重启后报错地址已在使用现象服务端程序关闭后立刻重新启动listener.Start() 抛 SocketException提示通常每个套接字地址只允许使用一次。原因上一次进程关闭后TCP 连接进入 TIME_WAIT 状态内核要等一段时间才释放端口。端口在同一时刻被占着立刻重启当然失败。解决可以在创建监听套接字前设置地址重用但 TcpListener 直接 Start 没有这个参数要这么做TcpListener listener new TcpListener(IPAddress.Any, port); // 允许端口在 TIME_WAIT 状态下被重新绑定 listener.ExclusiveAddressUse false; listener.Start();参数说明ExclusiveAddressUse 默认是 true表示独占端口设成 false 后同一个端口能被快速重用。这只在开发阶段需要生产环境用脚本管理进程生命周期尽量做到旧进程彻底退出再启动新进程。依赖这个属性掩盖进程管理问题不是正路。5.3 接收到的中文乱码现象服务端用 Encoding.UTF8 收到客户端发来的消息中文显示乱码英文正常。原因客户端发送时用了 Encoding.Default 或 GB2312服务端用 UTF-8 解码两边编码不一致。Windows 下 Encoding.Default 在中文系统上等于 GBK和 UTF-8 完全不兼容。解决统一编码。所有端到端通讯都写死 UTF-8客户端和服务端同一处代码static readonly Encoding textEncoding Encoding.UTF8;注意这里要传 Encoding.UTF8 而不是 Encoding.Default后者在不同操作系统上行为不一致——Linux 上 Default 是 UTF-8Windows 上是 GBK同一套代码换个宿主系统就翻车。另外如果有第三方设备厂商协议约定用 GBK那就明确用 Encoding.GetEncoding(GBK)但这种情况必须写进协议文档里。5.4 UI 线程卡死上位机界面假死现象WinForm/WPF 上位机里调用了同步 Receive界面拖不动、按钮点了没反应只能结束进程。原因Receive 是阻塞调用放在 UI 线程上执行等不到数据界面就一直卡住。TCP 客户端连接一个不存在的 IPConnect 阻塞几十秒UI 同样卡死。解决收发逻辑全部丢到后台线程UI 只负责展示。收到消息后要更新控件必须用 Invoke 或 Control.BeginInvoke 切回 UI 线程// 在后台线程收到消息后安全更新 UI 控件 this.BeginInvoke(new Action(() { txtLog.AppendText(msg Environment.NewLine); }));逻辑说明BeginInvoke 是异步的不会阻塞当前后台线程Invoke 是同步的如果 UI 线程忙后台线程也会等。日志展示场景用 BeginInvoke 足够。如果后台线程收消息频率很高建议把消息先放入队列UI 定时器批量取否则高频 Invoke 也会拖垮界面性能。5.5 Send 提示远程主机强迫关闭了一个现有的连接现象服务端给某个客户端 Send 消息时抛 IOException内层 SocketException 提示远程主机强迫关闭。原因对端已经断开拔线、断电、崩溃但服务端还没感知到Socket 对象还在会话字典里发数据才发现连接早已失效。解决这是 TCP假在线的另一面也是必须做心跳的核心理由。没有心跳方案的话只能把 Send 包在 try-catch 里捕获异常后主动清理会话。更根本的做法就是给每个连接增加心跳超时检查超过比如 10 秒没有收到对端任何数据包就判定掉线主动 CloseSession 并从字典里移除。心跳的具体实现下一章展开。6. 把源码真正用起来心跳检测、压测验证与抓包定位6.1 心跳包设计让假在线现出原形心跳是 Socket 项目从能跑到可靠的分水岭。协议上我一般这样约定客户端每 3 秒发一个长度为 0 的包或者固定文本PING服务端收到后不回心跳或者回PONG只更新 LastActiveTime服务端每隔 5 秒遍历一次会话字典把超过 10 秒没活跃的连接关掉。// 服务端定期检查超过 10 秒无活跃则判定死链并清理 foreach (var item in sessions.ToList()) { if ((DateTime.Now - item.Value.LastActiveTime).TotalSeconds 10) { item.Value.CloseSession(); RemoveSession(item.Key); Console.WriteLine($连接 {item.Key} 心跳超时已清理); } }逻辑说明这里对 sessions 调用 ToList 是为了在遍历过程中安全地移除元素直接在 foreach 里 Remove 会抛 InvalidOperationException。心跳数据本身也要走 4.3 的打包协议不能单独写一套非标逻辑收发两端解析才有统一入口。心跳周期怎么定局域网设备 3 秒发一次10 秒判离线很合理。跨公网建议放宽到 10 秒心跳、30 秒判离线否则移动网络下频繁断线重连在线状态会一直抖动。6.2 用 Wireshark 抓包验证收发的每一个字节很多时候代码看着对但线上数据不对这就是黑匣子问题。别靠猜抓包看字节。Wireshark 抓 loopback 回环数据时需要先安装 Npcap 并勾选抓取回环流量过滤表达式用tcp.port 9000抓包看三个重点三次握手有没有完成、客户端发的第一个包是否带上了 4 字节长度头、粘包是否真的发生。抓包能直接看到 TCP 层把两个应用包合在一个报文段里发送这会让你对TCP 是字节流这句话有非常直观的认识。我之前调试一个第三方设备协议应用层代码死活不对抓包才发现设备发送方把长度字段算成了字符串长度而不是字节长度中文消息全部错位——这种问题不看原始报文看一年日志也看不出结果。6.3 压测验证别凭感觉说能用完整源码交付出去不能只说我测过能通要留一个可以重复执行的验证步骤。我一般会在服务端加一段压测代码模拟 50 个客户端同时连接每个连接循环发送 1000 条带编号的消息服务端每收到一条校验编号连续断号或乱序就打印出来。压测时关注三件事连接数能不能稳定在 50连续消息有没有丢失全部断开后进程内存是否回落。只要出现了断号或内存只涨不掉就说明会话清理有遗漏Return 到避坑 5.5 去查。一个经验压测出的连接数上不去时先看操作系统的限制。Windows 默认动态端口范围之外往往是端口耗尽用下面命令确认动态端口区间netsh int ipv4 show dynamicport tcp如果动态端口范围太小用 netsh int ipv4 set dynamicport tcp start49152 num16384 把它扩大但这属于系统级配置动之前要和现场网管确认。这套源码方案用到现在我最大的感受是Socket 算不上难难的是把边界条件都写对——长度头读不满怎么办、对端突然断开怎么办、会话清理遗漏怎么办。把这些边界条件一个个填上你手里的代码才是真正完整、清楚的也才敢放到工控现场去跑。希望帮到你。本文还有配套的精品资源点击获取