简介：这套C# Socket网络通讯源码面向初步接触网络编程的开发者，以服务端与客户端两个完整项目演示Socket通信基本原理，代码结构简单、逻辑清晰，打开即用，适合用于课程设计或通讯功能扩展。压缩包共61个文件，以C#源文件（cs）为主，并包含可执行程序（exe）、调试符号（pdb）、界面资源（resx）及解决方案文件（sln）等，整体仅1.17MB，便于快速下载与本地运行。已有2915人学习使用，口碑较为可靠。通过服务端与客户端的分项目组织，读者可直观理解连接建立、消息收发等关键环节，并在此基础上自定义协议或增加多客户端管理等扩展功能。全部源码均为原创，风格直白，便于二次改造。
1. C#Socket网络通讯是什么：上位机场景里绕不开的最后一条路
如果你做过C#上位机，大概率有过这样的经历：设备方只甩给你一个IP和端口，说“连上去收数据就行”。所谓C#Socket网络通讯，就是这时候用来把两个进程之间的字节流打通的那套基础能力——TCP也好、UDP也好，绕不开监听、连接、收发和断开。完整源码听起来唬人，拆开看核心不过三个点：你等谁、你发什么、你怎么知道一条消息从哪儿断到哪儿。这篇文章按“先立模型、再给源码、后讲避坑”的顺序把这条路走通，适合刚接触socket网络编程的C#上位机开发者，也适合协议对接做到一半发现粘包问题的人。
2. 动手前先把模型立住：同步阻塞、异步回调与粘包拆包
很多人拿不到能跑的源码，不是因为不会写收发，而是没想清楚自己要的是哪种通信模型，写出来的代码跟场景是拧着的。这一章先把模型掰开，后面再看源码就不会一头雾水。
2.1 先分清服务端和客户端：TcpListener、TcpClient、Socket怎么选
Socket是最底层的抽象，TcpClient和TcpListener是对它的一层包装。TcpListener管“监听”，TcpClient管“连接后的通信”，它们内部都持有Socket对象。在C#上位机开发里，选择逻辑很简单：你需要等待别人来连你，就用TcpListener；你需要主动去连别人，就用TcpClient。两个都不满足才考虑直接操作Socket，比如要设置很细的IO选项或者同时挂多个连接时自己控缓冲区。绝大多数项目用前两者就够了。
一个容易搞反的点是：很多设备（扫码器、称重仪表、读卡器）本身是服务端，开机后监听一个固定端口，上位机反而要作为客户端去连接它。工控现场常见的Modbus TCP就是上位机做客户端连PLC的502端口。反过来，如果设备会把数据主动推给上位机，比如RFID读写器把标签数据上报过来，那上位机就是服务端，设备掉线重连也不影响接收。设计代码前先把角色定死，不然写到一半发现角色反了，整个收发流程都要返工。
2.2 同步阻塞与BeginReceive回调：为什么设备主动上报必须用异步
同步模式下，程序调用Receive就一直停在那里等数据，直到有数据或者对端关闭才返回。对于“发一条指令—等一条应答”的请求应答型交互，比如上位机给PLC下发一条复位命令，同步模式最简单也最直白，不容易出错。但上位机往往同时要和十几台设备通信，每台设备都开一个专职线程阻塞等待，线程数量一多，调度开销和资源占用就成了问题，UI线程更不能这么干。
老项目里最常见的异步写法是BeginReceive回调。调用的套路是：先准备一个byte[]缓冲区和SocketAsync对象，调用socket.BeginReceive(buffer, 0, buffer.Length, SocketFlags.None, 回调方法, state)，然后立即返回。数据到达时框架在线程池线程上调用你传进去的回调方法，回调里调EndReceive拿到实际收到的字节数。这里的坑在于，同一时刻只允许一个未完成的BeginReceive，如果回调还没处理完又发了第二次BeginReceive，会抛异常，所以一般用异步状态对象把缓冲区、Socket、消息累积器打包传进去，err个跌跌撞撞。
.NET后来提供的async/await模式本质上也是异步回调，只不过编译器帮你生成了状态机，代码写起来像同步，可读性好很多。下一篇源码就基于async/await，新项目建议直接用这套，老代码实在不能动再补BeginReceive封装。
2.3 粘包、半包、断包：TCP是字节流，不是消息流
TCP不保消息边界，它只保证字节顺序。你一次Send了100字节，对端可能一次收到100字节，也可能先收到40字节再收到60字节，极端情况下还可能一次收到200字节——里面有两条消息粘在一起。这就是工控里天天说的粘包和半包问题。很多socket网络编程出问题的项目，根源都是直接把收到的字节流当完整消息解析，收到半个包就解码，解码失败就当成设备乱发数据，整个上位机界面直接崩掉。
治这个问题的标准做法是给每条消息加边界。常见三种：固定长度、特殊结束符、包头带长度。二进制数据里固定长度最简单但不灵活；特殊结束符（比如\r\n）需要处理数据里出现同样字符的情况，要转义，麻烦；我在C#上位机里最常用的是“4字节长度前缀+消息体”：发送端先把消息体长度写成4字节int，拼在消息体前面一起发，接收端先读4字节拿到长度，再按这个长度去读消息体。这样无论网络怎么拆包，都能从字节流里把整条消息重新抠出来。
3. 完整源码落地：TCP服务端+客户端的最小可运行方案
这套源码的设计就一句话：发的时候先发4字节长度，再发内容；收的时候先收满4字节，再按长度收内容。剩下的全是循环和异常处理。这一章给的是能直接运行的完整Program.cs，新建一个.NET 6以上的控制台项目就能跑。
3.1 服务端源码：监听、Accept、读满与拆包
服务端先启动监听，每来一个客户端就用一个独立Task处理，不阻塞主循环。拆包逻辑集中在ReadExactlyAsync里——必须把指定字节数读满才算一次完整读取，少了就继续读，这就是处理半包的唯一办法。看完整代码。
using System.Net; using System.Net.Sockets; using System.Text; TcpListener listener = new TcpListener(IPAddress.Any, 9000); listener.Start(); Console.WriteLine($"服务端已启动，监听端口 {9000}"); while (true) { TcpClient client = await listener.AcceptTcpClientAsync(); _ = HandleClientAsync(client); // 每个客户端一个独立任务，不阻塞Accept } static async Task HandleClientAsync(TcpClient client) { Console.WriteLine($"客户端接入: {client.Client.RemoteEndPoint}"); NetworkStream stream = client.GetStream(); byte[] header = new byte[4]; // 长度头 byte[] buffer = new byte[64 * 1024]; // 消息体缓冲，按业务调整 try { while (true) { // 先读满4字节长度头 if (!await ReadExactlyAsync(stream, header, header.Length)) break; // 客户端正常关闭 int bodyLen = BitConverter.ToInt32(header, 0); if (bodyLen <= 0 || bodyLen > buffer.Length) { Console.WriteLine($"非法消息长度: {bodyLen}，主动断开"); break; } // 再按长度读消息体 if (!await ReadExactlyAsync(stream, buffer, bodyLen)) break; string text = Encoding.UTF8.GetString(buffer, 0, bodyLen); Console.WriteLine($"[{DateTime.Now:HH:mm:ss}] 收到: {text}"); byte[] echo = Encoding.UTF8.GetBytes($"echo: {text}"); await WriteFrameAsync(stream, echo); } } catch (Exception ex) { Console.WriteLine($"连接异常: {ex.Message}"); } finally { client.Close(); Console.WriteLine($"客户端断开: {client.Client.RemoteEndPoint}"); } } // 把buffer读满count字节才算成功，解决半包 static async Task<bool> ReadExactlyAsync(NetworkStream stream, byte[] buffer, int count) { int offset = 0; while (offset < count) { int read = await stream.ReadAsync(buffer, offset, count - offset); if (read == 0) return false; // 连接关闭 offset += read; } return true; } static async Task WriteFrameAsync(NetworkStream stream, byte[] body) { byte[] header = BitConverter.GetBytes(body.Length); await stream.WriteAsync(header, 0, header.Length); await stream.WriteAsync(body, 0, body.Length); }这段代码里有两个参数值得重点说明。第一个是IPAddress.Any，它表示监听本机所有网卡地址，工控机上设备可能从有线网卡、无线网卡任何一个网卡进来，绑定Any才不会漏接；如果你只回环测试，可以改成IPAddress.Loopback。第二个是buffer的64KB上限，这是给消息体设的保险丝，防止对端发一个超大的长度值（比如几十GB）让你的程序直接OutOfMemory崩溃，实际项目里按最大协议帧来定就行，比如Modbus TCP一般给4096都够。
_ = HandleClientAsync(client)这行是丢任务模式，主循环不await它，客户端连接后立刻能继续Accept下一个。代价是异常没有被观察者捕获，不过HandleClientAsync内部已经把异常全拦住了，外面没有抛出来的机会。如果业务里还有未捕获异常，建议在Task外层再加一个日志兜底，记录是哪台设备的IP断开或者异常。
3.2 客户端源码：连接、发帧、收帧的对称写法
客户端的收发逻辑必须跟服务端完全对称：先发4字节长度，再发消息体；接收时先读4字节，再读对应长度的消息体。双方只要有一边把长度算错或者没用相同的大小端，就会出现消息解析错位。
using System.Net.Sockets; using System.Text; using TcpClient client = new TcpClient(); await client.ConnectAsync("127.0.0.1", 9000); Console.WriteLine("已连接服务端"); NetworkStream stream = client.GetStream(); byte[] header = new byte[4]; byte[] buffer = new byte[64 * 1024]; for (int i = 0; i < 100; i++) { string msg = $"hello from client {i}"; byte[] body = Encoding.UTF8.GetBytes(msg); await WriteFrameAsync(stream, body); if (!await ReadExactlyAsync(stream, header, header.Length)) break; int bodyLen = BitConverter.ToInt32(header, 0); if (bodyLen <= 0 || bodyLen > buffer.Length) break; if (!await ReadExactlyAsync(stream, buffer, bodyLen)) break; string reply = Encoding.UTF8.GetString(buffer, 0, bodyLen); Console.WriteLine($"服务端回复: {reply}"); } client.Close(); Console.WriteLine("客户端退出"); static async Task<bool> ReadExactlyAsync(NetworkStream stream, byte[] buffer, int count) { int offset = 0; while (offset < count) { int read = await stream.ReadAsync(buffer, offset, count - offset); if (read == 0) return false; offset += read; } return true; } static async Task WriteFrameAsync(NetworkStream stream, byte[] body) { byte[] header = BitConverter.GetBytes(body.Length); await stream.WriteAsync(header, 0, header.Length); await stream.WriteAsync(body, 0, body.Length); }这里的ConnectAsync第二个参数是端口号，要和服务端监听的一致，否则会抛SocketException连接失败。客户端把缓冲区和服务端一样设成64KB，这里有个隐患我在第4章会细说：如果服务端发来的消息体大于这个缓冲区，读半截就会出错。设置好后，发送和接收都通过同一个帧结构走，代码结构和服务端几乎镜像，这也是刻意保持的，逻辑越对称越不容易出幺蛾子。
3.3 跑通链路：两个控制台实例先把回环测通
把服务端代码存成Server项目的Program.cs，客户端代码存成一个Client项目。两个项目分别启动，或者打开两个终端窗口同时dotnet run。先启动服务端，再启动客户端，正确的结果是：客户端每发一条，服务端打印一条收到消息，客户端收到一条echo回复，循环100次后两边都正常退出。这个测试通过，就说明链路通、帧对齐。
如果出问题，先按这个顺序排查：第一步ping 127.0.0.1确认网络栈正常；第二步看服务端控制台有没有打印“服务端已启动”，没有就说明端口被占用，参见第4章；第三步看客户端有没有“已连接服务端”，连不上先查防火墙和端口；最后再看消息收发。本机回环是最干净的测试环境，没有防火墙干扰，也没有丢包，能把代码逻辑和网络环境问题有效隔离。
4. Socket通讯排查与避坑：端口冲突、UI卡死、断开检测的血泪记录
源码能跑通只是第一步，落地到产线上才是真正的考验。这些坑都是我在C#上位机项目里踩过的，每一条都按现象、原因、解决的顺序写清楚，照着排查能少走很多弯路。
4.1 端口被占用：绑定报错“每个套接字地址只允许使用一次”
现象：启动服务端时抛出SocketException，错误信息是“通常每个套接字地址(协议/网络地址/端口)只允许使用一次。”如果用了Java或者Python技术栈的设备端，还会看到类似的“failed to create server shutdown socket on address [localhost] and port [802...”字样，本质都是端口冲突。
原因：要么是别的进程已经占用了这个端口，要么是你自己上一个程序没有完全退出，Socket还处在TIME_WAIT状态没释放。调试时按了停止按钮但进程没真正结束，是C#控制台程序里最常见的翻车场景。
解决：先用下面命令查端口被谁占用，然后杀掉对应进程，或者干脆换一个端口。
netstat -ano | findstr :9000 taskkill /PID 12345 /F第一行会列出监听9000端口的进程PID，第二行强制结束它。如果是程序自己残留，去任务管理器确认没有同名进程再启动。工控现场还有种情况是设备厂商给的固定端口不能改，解决不了占用就只能改监听IP或者协议层加转发，别硬顶。
4.2 回调线程里更新UI：跨线程控件访问会把上位机搞崩
现象：在Receive回调里写textBox1.AppendText(msg)，运行时抛出InvalidOperationException，提示“线程间操作无效，从不是创建控件的线程访问它”。或者不报错但界面卡死，过一会儿无响应。
原因：异步回调在线程池线程上执行，不是UI线程，WinForms和WPF都不允许直接跨线程更新控件。卡死的情况多半是回调里弹了MessageBox，把线程阻塞后又占用了UI资源。这也是C#上位机面试里经常追问的地方，问的就是明白不明白线程模型。
解决：用Control.BeginInvoke把UI更新操作调度回UI线程，回调在哪个线程跑都不受影响。
this.BeginInvoke(new Action(() => { textBox1.AppendText(msg + Environment.NewLine); }));注意要优先用BeginInvoke而不是Invoke，BeginInvoke不等待UI线程执行完就返回，Invoke会同步等待，万一UI线程正在处理别的耗时操作，接收线程就被拖住了。更规范的做法是给UI更新建一个队列，接收线程只往队列里塞数据，UI线程用Timer去取，这样就算一秒来几千条消息也不会卡界面。
4.3 断网后代码不报错：TCP不会主动告诉你对端走了
现象：网线被拔了或者设备断电，上位机界面还显示“已连接”，发指令也“成功”了，没有任何异常。过几分钟再操作，才突然收到一个异常断开。
原因：TCP没有在应用层探活。只要对端没有发RST包，操作系统就认为连接还在，你往缓冲区里写数据也只进入系统内存，不会立刻报错。很多新手同学在这个阶段会怀疑是不是自己代码写错了，其实是TCP本身的机制。
解决：两条腿走路。一是应用层心跳，每3到5秒发一帧心跳指令，超过N秒没收到对端响应就判定断开走重连逻辑；二是设置Socket的KeepAlive和超时参数，但操作系统的KeepAlive默认要两个小时才探测一次，不调整的话远水救不了近火。还有个有用的信号：ReadAsync返回0表示对端正常关闭了连接，这是TCP协议里最明确的优雅关闭信号，收到就立刻清理连接。
代码层面可以这样设置底层超时：
client.Client.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.KeepAlive, true); client.Client.ReceiveTimeout = 10000; // 10秒没数据就超时4.4 粘包半包导致的乱码：拆包逻辑必须和发送端严格对齐
现象：客户端发送的消息偶尔能正常解析，偶尔两条内容拼在一起，偶尔一条消息被截成两半，解析出来是乱码或者直接抛异常。
原因：这就是2.3里说的TCP字节流特性。只要收发双方有一方没按长度前缀拆包，或者把编码搞错了（UTF-8和GB2312混用），就会出现这种间歇性故障。最气人的是这种问题在回环测试里可能跑一百次都遇不到，一到现场网络稍微卡一下就开始时不时冒出来。
解决：坚持用第3章的帧结构，发送端写长度头时用BitConverter.GetBytes，接收端也用BitConverter.ToInt32，两边必须一致。还要注意大小端，如果设备端是Python或者Java，默认用大端，C#的BitConverter是小端，不一致的话收到的长度值可能是16777216这种天文数字，直接触发我们设的长度校验。遇到这种情况，要么在网络层反转，要么自定义一个大小端转换函数统一处理。
5. 验证与进阶：压测通过才算这套C#Socket通讯真正能用
代码写完先别急着上产线，用一轮简单的验证把拆包和断线逻辑的真实状态暴露出来。
5.1 用回环压测验证拆包正确性
把第3章客户端的循环次数从100改成10000，服务端每收到一条就计数。跑完看两边计数是否一致，一致说明拆包逻辑基本可靠。第二步做乱序测试：客户端开多个并发任务同时发，每个任务连续发1000条，这能暴露缓冲区重用和共用变量的问题。第三步拔网线测试，在客户端发送循环中间人为断开网络，观察服务端是否在预期时间内判定断开，程序有没有崩溃或者内存上涨。
我在做这类压测时会顺手把服务端收到的毫秒时间戳也打印出来，看相邻两条消息的间隔。如果出现突然200毫秒以上的断档，多半是网络抖动，不是代码问题，别改成重连逻辑太激进。真正的生产环境建议配合网络模拟工具模拟丢包和延迟，比回环测试更能暴露问题。
5.2 再往前一步：帧格式、心跳与资源回收的进阶做法
当前这套长度前缀方案只适合内部协议，如果要对接真正的设备，帧格式设计得更完善一些：头部可以扩展成“消息序号+协议ID+长度+CRC16校验”，消息序号用来检测丢帧和重复帧，CRC用来校验内容是否被篡改，这在弱网环境里几乎是必须的。资源回收方面，用using包裹TcpClient和NetworkStream，连接断开时调用Dispose，避免句柄泄漏。高并发场景可以把byte[]换成MemoryPool循环租借，或者改用SocketAsyncEventArgs走IOCP，压测时吞吐量能提升不少。
我现在的习惯是：每台设备接入先记一条日志，每次异常断开把堆栈和收发的最后一段数据一起存下来，这样设备厂扯皮的时候手里有证据，自己排查也能少花半天时间。网络通讯这行没有多少玄学，绝大多数问题都是帧格式不对称、缓冲区不够、断线没检测这三类，框架搭对了，后面就是正常维护的事。希望帮到你。
本文还有配套的精品资源，点击获取
