简介这份资源是面向C#初学者与网络编程入门者的UDP通信示例包围绕无连接、不可靠但高效的UDP协议展开帮助读者理解如何在.NET环境下借助System.Net.Sockets命名空间中的UdpClient类完成网口通讯。包内包含客户端与服务端两套工程覆盖UdpClient实例创建、Send发送数据包、Receive阻塞接收、IPEndPoint端点指定以及Close释放资源等核心环节并涉及端口占用、广播地址、数据丢失处理等注意事项可作为调试网口通讯测试的参考模板。资源共63个文件以cs源码、exe可执行程序、config配置、resx资源与csproj工程文件为主另有sln解决方案与pdb调试符号压缩包约117KB结构轻量便于快速运行验证。目前已有316人学习适合对照示例动手实践UDP收发流程与排错思路。1. 一个压缩包名背后C# UDP 网口通讯到底在做什么拿到“C#UDP.zip_UDP_UDP c#通讯_udp通信方式_网口通讯_网口通讯测”这个标题很多人第一反应是这不就是个 C# 写的 UDP 收发 Demo 吗但真正在工控现场待过的人会告诉你UDP 网口通讯这件事写通一个Send和Receive只要十分钟把它稳定跑在产线设备上、连续几天不掉线、丢包能定位、端口不冲突才是分水岭。它解决的核心问题是上位机与 PLC、扭矩枪、RFID 读写器、视觉控制器之间用无连接的 UDP 做高频、低延迟的数据交换典型场景就是网口通讯测试和 c#上位机 对接设备。适合谁看正在用 C# 做上位机、需要跟网口设备通讯、被 UDP 丢包和粘包折腾过的工程师。下面按“先跑通、再讲清、最后避坑”的顺序拆开讲。2. 先把 UDP 网口通讯的最小闭环跑通2.1 为什么工控上位机偏爱 UDP 而不是 TCP在产线数据采集里UDP 和 TCP 协议的区别不是理论题而是选型题。TCP 有连接、有重传、有拥塞控制听起来可靠但它的重传机制在实时场景里反而是负担一个包丢了后面所有包都得等它重传延迟抖动不可控。UDP 无连接、不重传、不保证顺序换来的是确定的发送节奏和极低的协议开销。典型场景是设备以固定周期比如 10ms往外广播状态帧上位机只关心“最新一帧”旧帧丢了无所谓这种语义下 UDP 是天然合适的。但要注意UDP 的“不可靠”是协议层不保证不代表你的程序不能做可靠性补偿。常见做法是在应用层加序号、加时间戳、加校验丢包了自己判断要不要补。我一般会先问清楚这个设备是周期广播还是请求应答周期广播用 UDP 收就行请求应答且要求不丢那要么在应用层做 ACK要么干脆换 TCP。选错了协议后面所有稳定性工作都是白费。另一个现实原因是设备固件。很多网口设备尤其是老一些的扭矩控制器、称重模块出厂只实现了 UDP 服务端你没法要求它改协议上位机只能迁就。这时候 UDP 不是选择是既定条件。2.2 用 C# 写一个能收能发的最小 UDP 程序先给一个能直接跑的最小闭环。下面这段代码同时做两件事绑定本地端口接收数据以及向目标设备发送一帧测试数据。用UdpClient是最省事的写法适合快速验证网口通讯是否通。using System; using System.Net; using System.Net.Sockets; using System.Text; using System.Threading; class UdpDemo { static void Main() { // 本地监听端口按设备实际约定改 int localPort 8000; // 目标设备 IP 和端口 string remoteIp 192.168.1.100; int remotePort 9000; UdpClient client new UdpClient(localPort); // 允许接收广播设备用广播发状态时需要 client.EnableBroadcast true; // 开一个接收线程避免阻塞主流程 Thread recvThread new Thread(() { IPEndPoint remote new IPEndPoint(IPAddress.Any, 0); while (true) { try { byte[] data client.Receive(ref remote); string msg Encoding.ASCII.GetString(data); Console.WriteLine($[RECV] {remote.Address}:{remote.Port} - {msg}); } catch (Exception ex) { Console.WriteLine($[RECV-ERR] {ex.Message}); } } }); recvThread.IsBackground true; recvThread.Start(); // 主线程定时发送测试帧 IPEndPoint target new IPEndPoint(IPAddress.Parse(remoteIp), remotePort); int seq 0; while (true) { string payload $TEST,{seq},{DateTime.Now:HH:mm:ss.fff}; byte[] buf Encoding.ASCII.GetBytes(payload); client.Send(buf, buf.Length, target); Console.WriteLine($[SEND] {payload}); Thread.Sleep(1000); } } }逻辑说明UdpClient构造时传入localPort就完成了本地绑定这一步决定了你的程序从哪个端口收数据。接收放在独立线程里因为Receive是阻塞的放主线程会把发送也卡死。发送用Send(byte[], length, IPEndPoint)目标地址每次都可以不同这是 UDP 无连接的特性。参数说明localPort必须和设备约定一致设备往哪个端口发你就绑哪个remoteIp和remotePort是设备监听的地址如果设备是广播发送你的接收端绑好端口即可不需要知道设备 IP。EnableBroadcast只在需要收广播或发广播时打开普通单播可以关掉。2.3 网口通讯测试时先确认的三件事在写业务逻辑之前先用工具确认链路是通的能省掉大量“到底是网络问题还是代码问题”的扯皮。我一般按这个顺序排查第一步确认 IP 和端口。用ipconfig看本机网卡地址确认和设备在同一网段。跨网段通讯比如 mcgs触摸屏跟西门子1500跨网段通讯 那种场景需要网关和路由支持UDP 单播跨网段通常没问题广播跨网段基本不通。第二步用系统自带工具或第三方 UDP 网络调试工具发一帧看设备有没有回应。这一步能把“设备没发”和“你没收到”区分开。第三步确认防火墙。Windows 防火墙默认会拦入站 UDP尤其是你绑的端口不在白名单里时现象就是发送正常、接收永远收不到。临时关掉防火墙测试确认后再加规则。提示测试阶段先把防火墙入站规则放行对应 UDP 端口别等到业务代码写完才发现收不到包。3. 把 UDP 通讯做稳缓冲区、粘包与线程模型3.1 接收缓冲区大小和丢包的真正关系UDP 丢包在现场太常见了很多人第一反应是“网络不好”但相当一部分丢包是接收缓冲区太小导致的。操作系统为每个 UDP socket 维护一个接收缓冲区数据到了先放缓冲区你的程序再Receive取走。如果设备发得快、你取得慢缓冲区满了后面到的包直接被内核丢掉你的代码根本感知不到。UdpClient默认缓冲区不大高频场景要手动调大。用Socket可以直接设Socket sock new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp); sock.Bind(new IPEndPoint(IPAddress.Any, 8000)); // 接收缓冲区调到 1MB按数据量调整 sock.ReceiveBufferSize 1024 * 1024; // 发送缓冲区同理 sock.SendBufferSize 1024 * 1024;参数说明ReceiveBufferSize单位是字节设多大取决于“峰值速率 × 你两次 Receive 之间的最大间隔”。比如设备 10ms 发一帧 1KB你每秒取一次那缓冲区至少要能装下 100 帧即 100KB留余量设 1MB 比较稳。设太大浪费内存设太小照样丢。判断是不是缓冲区丢包有个笨但有效的办法在接收循环里统计每秒收到的包数和设备标称的发送频率对比。差得多先怀疑缓冲区和你取包的及时性而不是网络。3.2 UDP 也会粘包一次 Receive 拿到多帧怎么办很多人以为粘包是 TCP 的专利其实 UDP 也会。UDP 保留消息边界理论上一次Receive对应一个数据报但如果设备把多帧数据拼在一个 UDP 包里发出来固件这么写的或者你的应用层协议本身是流式的就会出现一次收到多帧的情况。反过来一个逻辑帧被拆到多个 UDP 包里发也会出现半包。处理思路是定义帧格式常见做法是“帧头 长度 数据 校验”。接收端维护一个缓冲区把收到的字节追加进去然后循环找完整帧// 假设帧格式0xAA 0x55 2字节长度 数据 1字节校验 Listbyte buffer new Listbyte(); void OnDataReceived(byte[] data) { buffer.AddRange(data); while (true) { // 找帧头 int headIndex FindHeader(buffer); if (headIndex 0) { buffer.Clear(); break; } if (headIndex 0) buffer.RemoveRange(0, headIndex); if (buffer.Count 4) break; // 长度字段还没收全 int len buffer[2] | (buffer[3] 8); int total 4 len 1; if (buffer.Count total) break; // 整帧还没到齐 byte[] frame buffer.GetRange(0, total).ToArray(); buffer.RemoveRange(0, total); ParseFrame(frame); // 交给业务解析 } }逻辑说明buffer是跨多次Receive累积的每次收到数据先追加再循环尝试切出完整帧。切不出来就等下次数据。这样无论设备怎么分包只要字节流顺序对最终都能还原。参数说明帧头字节、长度字段的字节序大端还是小端、校验算法这三样必须和设备文档或实测对齐。长度字段是“数据长度”还是“整帧长度”差一个字节就会一直解析失败这是血泪经验里最常见的翻车点。3.3 线程模型别在接收线程里做耗时操作接收线程的唯一职责应该是“尽快把数据从内核缓冲区搬到应用缓冲区”。一旦你在接收线程里做解析、写数据库、更新 UI取包速度就下来了缓冲区很快满丢包随之而来。正确做法是接收线程只负责收和入队另开工作线程或线程池消费队列。using System.Collections.Concurrent; ConcurrentQueuebyte[] recvQueue new ConcurrentQueuebyte[](); // 接收线程 void RecvLoop(Socket sock) { byte[] buf new byte[65535]; EndPoint remote new IPEndPoint(IPAddress.Any, 0); while (true) { int n sock.ReceiveFrom(buf, ref remote); byte[] copy new byte[n]; Buffer.BlockCopy(buf, 0, copy, 0, n); recvQueue.Enqueue(copy); // 只入队不做别的 } } // 工作线程 void WorkLoop() { while (true) { if (recvQueue.TryDequeue(out byte[] data)) { OnDataReceived(data); // 解析、业务处理放这里 } else { Thread.Sleep(1); } } }参数说明buf用 65535 是 UDP 理论最大包长实际按设备最大帧设别每次 new。ConcurrentQueue是无锁队列适合这种单生产单消费场景。Thread.Sleep(1)是空转让步队列压力大时可以去掉或改成信号量通知。注意UI 更新一定要切回主线程WinForm 里跨线程直接改控件会抛异常用Invoke或BeginInvoke。4. 现场避坑UDP 网口通讯最常见的五类翻车4.1 现象发送正常接收一直接不到原因最常见是防火墙拦了入站 UDP其次是绑定的端口和设备发送的目标端口不一致还有一种是自己绑了IPAddress.Any但机器有多网卡数据从另一块网卡进来了。解决先关防火墙验证再核对端口多网卡场景显式绑定到设备所在网段的那个 IP而不是Any。4.2 现象偶尔丢一两包频率不高但一直有原因接收缓冲区偏小或者接收线程里做了耗时操作导致取包不及时。解决调大ReceiveBufferSize把解析和业务处理挪出接收线程用队列解耦。如果还丢用 Wireshark 抓包确认包到底有没有到网卡到了没到应用层就是程序问题没到就是网络或设备问题。4.3 现象解析出来的数据错位、乱码原因帧格式理解错了长度字段含义、字节序、校验范围三者之一对不上。解决拿一帧已知的正确数据逐字节对照文档先把长度字段和字节序确认死再调校验。别一上来就怀疑编码先怀疑帧结构。4.4 现象程序跑几小时后就收不到数据了原因接收线程里某个异常没捕获线程悄悄退出了主流程还在跑所以你没发现。解决接收循环里try-catch包住每次Receive异常记录日志但不要让线程退出或者加一个看门狗定期检查接收线程是否存活挂了就重启。4.5 现象换台电脑就通讯不上原因新电脑网卡网段不对、防火墙策略不同、或者绑定的端口被别的程序占用了。解决先netstat -ano | findstr 端口号看端口占用再核对网段和防火墙。端口被占用时Bind会抛异常别忽略这个异常。5. 进阶用序号和时间戳把 UDP 做成可观测的通讯UDP 本身不给你任何可靠性信息但你可以自己在应用层补。我的习惯是在每帧数据里带上发送序号和发送时间戳接收端据此算出丢包率和端到端延迟。这两个指标一出来通讯质量就从“感觉还行”变成“可量化”。具体做法发送端维护一个自增序号每帧写入帧头接收端记录上次收到的序号差值大于 1 就说明中间丢了包累加丢包计数。时间戳用发送端的本地时间接收端减去当前时间得到延迟前提是两台机器时钟大致同步工控现场一般够用。// 发送端 uint seq 0; byte[] BuildFrame(byte[] payload) { // 帧头2字节 序号4字节 时间戳8字节 数据 byte[] frame new byte[14 payload.Length]; frame[0] 0xAA; frame[1] 0x55; BitConverter.GetBytes(seq).CopyTo(frame, 2); BitConverter.GetBytes(DateTime.Now.Ticks).CopyTo(frame, 6); payload.CopyTo(frame, 14); return frame; } // 接收端统计 uint lastSeq 0; long lostCount 0; void OnFrame(uint seq, long sendTicks) { if (lastSeq ! 0 seq lastSeq 1) lostCount seq - lastSeq - 1; lastSeq seq; double delayMs (DateTime.Now.Ticks - sendTicks) / 10000.0; // 丢包率和延迟可以定时输出或上报 }参数说明序号用uint够用回绕时注意处理时间戳用Ticks精度是 100 纳秒除以 10000 得毫秒。丢包率 lostCount / (lastSeq)延迟做滑动平均更稳。这套东西不复杂但能让你在出问题时第一时间知道是网络抖动还是程序卡顿比盲目抓包高效得多。一个具体技巧把丢包率和延迟做成界面上两个数字现场调试时盯着看设备一发飙数字立刻变化定位方向马上就有了。我吃过亏早期不带序号丢包了只能靠猜后来加上这两个字段排查时间从半天缩到十分钟。希望帮到你。本文还有配套的精品资源点击获取