尧图网页设计 
简介这是一份面向 VB.NET 网络编程初学者与一卡通系统开发者的 UDP 通信服务端示例源码聚焦实时在线云消费机场景解决如何用 Socket 监听 UDP 端口、收发报文并搭建消费终端与服务器之间实时通信链路的问题。压缩包共 105 个文件约 2.91MB包含 8 个 vb 源码文件、26 个 dll 依赖库、7 个可执行程序、若干 config 配置、xml 与 resources 资源文件以及用于注册 ocx 控件的 bat 脚本覆盖从源码到运行环境的完整结构。已有 199 人学习下载。读者可据此理解 UDP 端口监听、消息发送与接收的完整流程并在此基础上接入数据库增删查改快速扩展为实时一卡通消费系统适合作为课程设计、毕业设计或小型商用项目的起步框架。1. 从一台 VB.NET 云消费机服务器说起UDP 长连接到底扛不扛得住做过食堂刷卡机、自助售货机或者共享设备的人大概率都碰过这样一个场景几十上百台终端分布在不同的网络环境里每隔几秒就要把一笔消费流水上报到中心服务器服务器还得把余额变动、黑名单、费率调整这些指令实时推回去。用 TCP 吧连接数一多心跳、断线重连、半包粘包全得自己处理用 HTTP 轮询吧实时性差终端还费流量。这时候很多人会把目光投向 UDP——无连接、开销小、延迟低听起来特别适合这种「小包高频」的在线消费机场景。但 UDP 的坑也是出了名的丢包、乱序、没有连接状态服务器端到底该怎么设计才能既扛住并发又保证流水不丢这份 VB.NET Socket Udp 实时在线云消费机服务器端源码核心要解决的就是这个问题。它面向的是用 VB.NET 做上位机或服务端的开发者尤其是那些设备数量在几十到几百台、对实时性有要求、又不想把架构搞得太重的项目。接下来我会把 UDP 服务器端的选型逻辑、Socket 编程的关键参数、以及实际落地时最容易翻车的地方一条条拆开讲清楚。2. UDP 服务器端选型为什么消费机场景偏爱无连接2.1 TCP 和 UDP 在消费机场景下的真实差别先别急着写代码选型错了后面全是白干。消费机终端和服务器之间的通信本质上是一种「状态同步 流水上报」的混合模式。终端需要知道自己的余额对不对、能不能交易服务器需要知道每一笔消费是谁花的、花了多少。用 TCP 的话好处是可靠、有序坏处是每台设备都要维持一个连接服务器端要管理连接生命周期终端断网后重连逻辑也得写扎实。设备数量一上来连接管理本身就成了负担。UDP 的优势在于无连接服务器不需要为每台设备维护会话状态收到包就处理处理完就回。对于消费机这种「请求-响应」模式明确、单包数据量小通常几十到几百字节的场景UDP 的额外开销比 TCP 小得多。但代价是你要自己在应用层做可靠性保障流水号去重、超时重传、确认应答这些都得自己实现。常见做法是给每个包加一个自增的序列号服务器收到后记录最新序列号重复的丢弃缺失的通过终端重传补上。还有一个现实因素很多消费机终端跑在嵌入式环境或者老旧 Windows 系统上TCP 协议栈的实现质量参差不齐反而 UDP 更稳定。这也是为什么不少存量项目最终选了 UDP 方案。2.2 VB.NET 做 UDP 服务器的技术栈选择VB.NET 里做 UDP 通信核心就是System.Net.Sockets命名空间下的UdpClient和Socket两个类。UdpClient封装得比较友好适合快速上手Socket类更底层能精细控制缓冲区、超时、绑定行为适合对性能有要求的服务器端。我一般会这样选如果只是做一个小规模的测试服务UdpClient足够了但如果是正式上线的消费机服务器建议直接用Socket类因为你需要控制ReceiveBufferSize、SendTimeout、ReceiveTimeout这些参数还要处理SocketException里的各种错误码。下面是一个最小可运行的 UDP 服务器端骨架用Socket类实现Imports System.Net Imports System.Net.Sockets Imports System.Text Module UdpServer Private serverSocket As Socket Private listenPort As Integer 9000 Sub Main() 创建 UDP Socket绑定到所有网卡的指定端口 Dim localEndPoint As New IPEndPoint(IPAddress.Any, listenPort) serverSocket New Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp) serverSocket.Bind(localEndPoint) 设置接收缓冲区消费机小包多缓冲区别太小 serverSocket.ReceiveBufferSize 1024 * 1024 serverSocket.ReceiveTimeout 0 0 表示无限等待靠异步或循环控制 Console.WriteLine(UDP 消费机服务器已启动监听端口 listenPort) Dim buffer(4096) As Byte Dim remoteEndPoint As New IPEndPoint(IPAddress.Any, 0) Dim remoteEP As EndPoint CType(remoteEndPoint, EndPoint) While True Try 阻塞接收数据报 Dim received As Integer serverSocket.ReceiveFrom(buffer, 0, buffer.Length, SocketFlags.None, remoteEP) Dim clientMsg As String Encoding.UTF8.GetString(buffer, 0, received) Console.WriteLine(收到来自 remoteEP.ToString() 的数据 clientMsg) 这里调用业务处理函数解析消费流水、更新余额等 Dim response As String ProcessConsumeData(clientMsg, remoteEP) 回送应答包 Dim respBytes As Byte() Encoding.UTF8.GetBytes(response) serverSocket.SendTo(respBytes, remoteEP) Catch ex As SocketException 记录错误码常见的有 10054连接被重置、10040消息过长 Console.WriteLine(Socket 异常错误码 ex.ErrorCode 消息 ex.Message) End Try End While End Sub Private Function ProcessConsumeData(msg As String, ep As EndPoint) As String 实际业务里这里要解析协议格式比如流水号|卡号|金额|时间戳 然后写数据库、校验余额、返回结果 Return ACK| msg.GetHashCode().ToString() End Function End Module这段代码的逻辑很直白绑定端口、循环收包、处理、回包。关键参数有三个ReceiveBufferSize设成 1MB 是为了应对突发流量消费机在高峰期可能几十台同时上报ReceiveTimeout设为 0 表示阻塞等待实际生产环境建议配合异步回调或者独立线程池buffer大小 4096 字节足够覆盖绝大多数消费机协议包但如果你的协议里有图片或大块数据得相应调大。2.3 单线程阻塞收包的性能边界在哪上面那个While True循环是单线程阻塞模型写起来简单但性能边界很明显同一时刻只能处理一个包如果业务处理逻辑里有数据库操作或者文件写入后面的包就得排队。设备数量少比如 20 台以内、上报频率低10 秒一次的时候这个模型完全够用。但一旦设备上百、上报间隔缩短到 1-2 秒队列就会堆积表现为终端侧「发了没反应」或者「响应超时」。要突破这个边界常见做法有两种一是用BeginReceiveFrom/EndReceiveFrom做异步接收收到包后丢到线程池处理二是用多个Socket绑定同一端口需要设置ReuseAddress每个 Socket 一个接收线程。VB.NET 里异步模型写起来比 C# 啰嗦一些但逻辑是一样的。我一般会先跑单线程版本用压力测试工具打流看丢包率和处理延迟再决定要不要上异步。3. 消费机协议设计流水号、校验和重传怎么定3.1 自定义二进制协议还是文本协议消费机服务器和终端之间的协议格式直接决定了后面维护的痛苦程度。文本协议比如流水号|卡号|金额|时间戳可读性好调试方便用串口助手或者 UDP 调试工具就能看明白。二进制协议紧凑、解析快但调试时得对着十六进制看容易出错。我的经验是如果终端是 PC 或者性能还不错的嵌入式设备优先用文本协议开发效率高出问题好排查。如果终端资源紧张比如 8 位单片机或者单包大小直接影响流量成本再考虑二进制。这份源码标题里没提协议格式但消费机场景下文本协议加一个简单的校验字段是性价比最高的选择。3.2 流水号去重和 CRC16 校验的 VB.NET 实现UDP 不保证不重复终端重传或者网络抖动都可能导致服务器收到重复包。流水号是去重的关键终端每发一笔流水流水号自增服务器维护一个「已处理流水号」的滑动窗口收到重复的直接丢弃但依然要回 ACK否则终端会一直重传。校验方面热搜词里出现了「vb.net crc16编程」说明不少人在这个环节踩过坑。CRC16 用来检测数据在传输过程中是否被篡改或损坏比简单的累加和可靠。下面是一个 VB.NET 的 CRC16 实现用的是常见的 Modbus 多项式Module Crc16Helper CRC16-Modbus 查表法速度快适合高频调用的服务器端 Private ReadOnly CrcTable As UShort() { H0, HC0C1, HC181, H140, HC301, H3C0, H280, HC241, HC601, H6C0, H580, HC741, H500, HC941, HC981, H440 完整表有 256 项这里省略实际使用需补全 } Public Function ComputeCrc16(data As Byte(), offset As Integer, length As Integer) As UShort Dim crc As UShort HFFFF For i As Integer offset To offset length - 1 crc (crc 8) Xor CrcTable((crc Xor data(i)) And HFF) Next Return crc End Function 文本协议里把 CRC 拼在末尾用十六进制字符串表示 Public Function AppendCrc(payload As String) As String Dim bytes As Byte() Encoding.UTF8.GetBytes(payload) Dim crc As UShort ComputeCrc16(bytes, 0, bytes.Length) Return payload | crc.ToString(X4) End Function Public Function VerifyCrc(fullMsg As String) As Boolean Dim parts As String() fullMsg.Split(|c) If parts.Length 2 Then Return False Dim payload As String String.Join(|, parts, 0, parts.Length - 1) Dim expected As UShort Convert.ToUInt16(parts(parts.Length - 1), 16) Dim bytes As Byte() Encoding.UTF8.GetBytes(payload) Return ComputeCrc16(bytes, 0, bytes.Length) expected End Function End Module查表法的核心是把每个字节的 CRC 计算结果预先存好运行时只做移位和异或比逐位计算快很多。参数上注意两点初始值用HFFFF这是 Modbus 的标准多项式表必须完整上面只列了前 16 项实际项目里要补全 256 项否则校验结果对不上。校验失败时服务器应该直接丢弃该包不回 ACK让终端超时重传。3.3 超时重传和 ACK 机制的最小实现UDP 没有内置重传终端发完包后如果没收到 ACK得自己重发。服务器端的责任是收到合法包就回 ACKACK 里带上流水号终端收到后把该流水号标记为已完成。如果终端在 500ms 内没收到 ACK就重传重传 3 次还没成功就报警或者缓存到本地。服务器端实现 ACK 很简单就是在ProcessConsumeData返回的时候把流水号原样带回去。但要注意ACK 包本身也可能丢所以终端侧的重传逻辑必须独立于服务器。服务器不要主动重传 ACK否则在高并发下会放大流量。我一般会在服务器端加一个「最近处理流水号」的字典容量限制在 10000 条超出的按时间淘汰防止内存无限增长。4. 避坑与排查UDP 服务器端最容易翻车的五个点4.1 端口被占用通常每个套接字地址只允许使用一次现象服务器启动时报SocketException错误信息是「通常每个套接字地址(协议/网络地址/端口)只允许使用一次」。原因很明确上一次的服务进程还没完全退出端口处于TIME_WAIT或者被其他程序占用了。UDP 虽然没有 TCP 的TIME_WAIT但如果之前绑定了ExclusiveAddressUse或者有多个进程抢同一个端口就会报这个错。解决办法在Bind之前设置serverSocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, True)允许多个 Socket 绑定同一端口。另外排查时用netstat -ano | findstr :9000看端口被哪个 PID 占了任务管理器里结束掉。开发阶段建议把端口做成配置项别硬编码。4.2 收包缓冲区溢出导致丢包现象压力测试时终端侧显示发送成功但服务器日志里少了很多流水。原因通常是ReceiveBufferSize太小或者业务处理太慢导致内核缓冲区满了之后新来的包直接被丢弃。UDP 没有流控丢了就是丢了服务器根本不知道。解决办法把ReceiveBufferSize调到 1MB 以上同时把业务处理逻辑从接收循环里剥离出去用队列解耦。接收线程只负责收包和入队处理线程从队列里取数据慢慢处理。队列可以用ConcurrentQueue(Of Byte())VB.NET 里通过System.Collections.Concurrent引用。如果丢包依然严重就得考虑多线程接收或者异步模型了。4.3 中文乱码编码不一致的隐蔽坑现象终端发来的卡号或者备注信息里带中文服务器解析出来是乱码。原因是终端和服务器用的编码不一致终端可能用了 GBK服务器默认用 UTF-8 解码。解决办法协议里明确约定编码格式统一用 UTF-8。如果终端改不了服务器端就得按终端实际编码来解码。VB.NET 里用Encoding.GetEncoding(GBK)可以指定编码但要注意这个编码在 .NET Core 里需要额外注册。最稳妥的做法是在协议头里加一个编码标识字段服务器根据标识动态选择解码器。4.4 防火墙拦截 UDP 包现象本机测试一切正常部署到服务器后终端死活连不上。原因多半是 Windows 防火墙或者云服务商的安全组没放行 UDP 端口。UDP 是无连接的防火墙不会像 TCP 那样有明确的连接建立过程所以排查起来更隐蔽。解决办法在服务器上添加入站规则允许指定 UDP 端口的流量。云服务器还要检查安全组配置。测试时可以用udp端口测试工具或者iperf3的 UDP 模式打流确认端口是否真的通了。如果服务器有多张网卡绑定的时候用IPAddress.Any还是指定 IP也要根据实际网络拓扑来定。4.5 异步回调里的异常吞没现象服务器运行一段时间后某些终端的请求不再被处理但进程没崩溃日志里也没有明显错误。原因可能是用了BeginReceiveFrom异步模型回调函数里抛了异常但没捕获导致异步接收链断了后续的包再也收不到。解决办法在异步回调的最外层包一层Try...Catch任何异常都要记录日志并且重新调用BeginReceiveFrom把接收链续上。VB.NET 里异步回调的异常不会自动冒泡到主线程必须手动处理。我一般会在回调入口和出口都打日志方便确认接收链是否还活着。5. 进阶技巧用抓包和日志把 UDP 问题钉死UDP 服务器端最让人头疼的地方在于「没有连接状态」出了问题不好定位。终端说发了服务器说没收到到底是谁的问题这时候光看应用日志是不够的得把网络层的数据也抓下来。我常用的组合是 Wireshark 加自定义日志。Wireshark 过滤规则写udp.port 9000能看到每一个数据报的源 IP、目的 IP、长度和原始内容。如果 Wireshark 里能看到包但服务器日志里没有那问题就在服务器端的接收逻辑如果 Wireshark 里都没有那就是终端没发出来或者中间网络丢了。这一步能省掉大量扯皮时间。日志方面建议在服务器端记录四个关键字段收到时间、源终端标识、流水号、处理结果。格式用管道符分隔方便后续用脚本分析。下面是一个简单的日志写入函数Private Sub WriteUdpLog(remoteEP As EndPoint, seqNo As String, result As String) 日志按天分文件避免单个文件过大 Dim logDir As String C:\ConsumeServerLogs\ If Not IO.Directory.Exists(logDir) Then IO.Directory.CreateDirectory(logDir) Dim logFile As String logDir udp_ DateTime.Now.ToString(yyyyMMdd) .log Dim line As String DateTime.Now.ToString(HH:mm:ss.fff) | remoteEP.ToString() | seqNo | result Environment.NewLine 用 AppendAllText 简单追加高并发场景建议换成带锁的 StreamWriter IO.File.AppendAllText(logFile, line, Encoding.UTF8) End Sub这个函数每次调用都会打开和关闭文件在每秒几百包的场景下会成为瓶颈。正式环境里我会用一个独立的日志线程配合BlockingCollection做生产者消费者批量写入。参数上注意日志目录要有写权限否则会静默失败——这也是个血泪教训曾经因为权限问题排查了半天最后发现日志根本没写进去。还有一个验证手段是回环测试在一台机器上同时跑服务器和模拟终端用127.0.0.1通信排除网络因素。如果回环正常但跨机不正常基本就是防火墙或者路由问题。模拟终端可以用 VB.NET 写个小工具也可以直接用python socket脚本发 UDP 包灵活度高。最后说个习惯每次改完服务器端的接收逻辑我都会先用iperf3的 UDP 模式打一轮流看丢包率和吞吐量再上真实终端。这个步骤花不了几分钟但能提前暴露缓冲区、线程模型的问题。UDP 这东西玄学的地方不少但大部分「玄学」最后都能用抓包和日志解释清楚。希望帮到你。本文还有配套的精品资源点击获取 VB.NET UDP云消费机服务器端源码实战：高并发实时通信与避坑指南
简介这是一份面向 VB.NET 网络编程初学者与一卡通系统开发者的 UDP 通信服务端示例源码聚焦实时在线云消费机场景解决如何用 Socket 监听 UDP 端口、收发报文并搭建消费终端与服务器之间实时通信链路的问题。压缩包共 105 个文件约 2.91MB包含 8 个 vb 源码文件、26 个 dll 依赖库、7 个可执行程序、若干 config 配置、xml 与 resources 资源文件以及用于注册 ocx 控件的 bat 脚本覆盖从源码到运行环境的完整结构。已有 199 人学习下载。读者可据此理解 UDP 端口监听、消息发送与接收的完整流程并在此基础上接入数据库增删查改快速扩展为实时一卡通消费系统适合作为课程设计、毕业设计或小型商用项目的起步框架。1. 从一台 VB.NET 云消费机服务器说起UDP 长连接到底扛不扛得住做过食堂刷卡机、自助售货机或者共享设备的人大概率都碰过这样一个场景几十上百台终端分布在不同的网络环境里每隔几秒就要把一笔消费流水上报到中心服务器服务器还得把余额变动、黑名单、费率调整这些指令实时推回去。用 TCP 吧连接数一多心跳、断线重连、半包粘包全得自己处理用 HTTP 轮询吧实时性差终端还费流量。这时候很多人会把目光投向 UDP——无连接、开销小、延迟低听起来特别适合这种「小包高频」的在线消费机场景。但 UDP 的坑也是出了名的丢包、乱序、没有连接状态服务器端到底该怎么设计才能既扛住并发又保证流水不丢这份 VB.NET Socket Udp 实时在线云消费机服务器端源码核心要解决的就是这个问题。它面向的是用 VB.NET 做上位机或服务端的开发者尤其是那些设备数量在几十到几百台、对实时性有要求、又不想把架构搞得太重的项目。接下来我会把 UDP 服务器端的选型逻辑、Socket 编程的关键参数、以及实际落地时最容易翻车的地方一条条拆开讲清楚。2. UDP 服务器端选型为什么消费机场景偏爱无连接2.1 TCP 和 UDP 在消费机场景下的真实差别先别急着写代码选型错了后面全是白干。消费机终端和服务器之间的通信本质上是一种「状态同步 流水上报」的混合模式。终端需要知道自己的余额对不对、能不能交易服务器需要知道每一笔消费是谁花的、花了多少。用 TCP 的话好处是可靠、有序坏处是每台设备都要维持一个连接服务器端要管理连接生命周期终端断网后重连逻辑也得写扎实。设备数量一上来连接管理本身就成了负担。UDP 的优势在于无连接服务器不需要为每台设备维护会话状态收到包就处理处理完就回。对于消费机这种「请求-响应」模式明确、单包数据量小通常几十到几百字节的场景UDP 的额外开销比 TCP 小得多。但代价是你要自己在应用层做可靠性保障流水号去重、超时重传、确认应答这些都得自己实现。常见做法是给每个包加一个自增的序列号服务器收到后记录最新序列号重复的丢弃缺失的通过终端重传补上。还有一个现实因素很多消费机终端跑在嵌入式环境或者老旧 Windows 系统上TCP 协议栈的实现质量参差不齐反而 UDP 更稳定。这也是为什么不少存量项目最终选了 UDP 方案。2.2 VB.NET 做 UDP 服务器的技术栈选择VB.NET 里做 UDP 通信核心就是System.Net.Sockets命名空间下的UdpClient和Socket两个类。UdpClient封装得比较友好适合快速上手Socket类更底层能精细控制缓冲区、超时、绑定行为适合对性能有要求的服务器端。我一般会这样选如果只是做一个小规模的测试服务UdpClient足够了但如果是正式上线的消费机服务器建议直接用Socket类因为你需要控制ReceiveBufferSize、SendTimeout、ReceiveTimeout这些参数还要处理SocketException里的各种错误码。下面是一个最小可运行的 UDP 服务器端骨架用Socket类实现Imports System.Net Imports System.Net.Sockets Imports System.Text Module UdpServer Private serverSocket As Socket Private listenPort As Integer 9000 Sub Main() 创建 UDP Socket绑定到所有网卡的指定端口 Dim localEndPoint As New IPEndPoint(IPAddress.Any, listenPort) serverSocket New Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp) serverSocket.Bind(localEndPoint) 设置接收缓冲区消费机小包多缓冲区别太小 serverSocket.ReceiveBufferSize 1024 * 1024 serverSocket.ReceiveTimeout 0 0 表示无限等待靠异步或循环控制 Console.WriteLine(UDP 消费机服务器已启动监听端口 listenPort) Dim buffer(4096) As Byte Dim remoteEndPoint As New IPEndPoint(IPAddress.Any, 0) Dim remoteEP As EndPoint CType(remoteEndPoint, EndPoint) While True Try 阻塞接收数据报 Dim received As Integer serverSocket.ReceiveFrom(buffer, 0, buffer.Length, SocketFlags.None, remoteEP) Dim clientMsg As String Encoding.UTF8.GetString(buffer, 0, received) Console.WriteLine(收到来自 remoteEP.ToString() 的数据 clientMsg) 这里调用业务处理函数解析消费流水、更新余额等 Dim response As String ProcessConsumeData(clientMsg, remoteEP) 回送应答包 Dim respBytes As Byte() Encoding.UTF8.GetBytes(response) serverSocket.SendTo(respBytes, remoteEP) Catch ex As SocketException 记录错误码常见的有 10054连接被重置、10040消息过长 Console.WriteLine(Socket 异常错误码 ex.ErrorCode 消息 ex.Message) End Try End While End Sub Private Function ProcessConsumeData(msg As String, ep As EndPoint) As String 实际业务里这里要解析协议格式比如流水号|卡号|金额|时间戳 然后写数据库、校验余额、返回结果 Return ACK| msg.GetHashCode().ToString() End Function End Module这段代码的逻辑很直白绑定端口、循环收包、处理、回包。关键参数有三个ReceiveBufferSize设成 1MB 是为了应对突发流量消费机在高峰期可能几十台同时上报ReceiveTimeout设为 0 表示阻塞等待实际生产环境建议配合异步回调或者独立线程池buffer大小 4096 字节足够覆盖绝大多数消费机协议包但如果你的协议里有图片或大块数据得相应调大。2.3 单线程阻塞收包的性能边界在哪上面那个While True循环是单线程阻塞模型写起来简单但性能边界很明显同一时刻只能处理一个包如果业务处理逻辑里有数据库操作或者文件写入后面的包就得排队。设备数量少比如 20 台以内、上报频率低10 秒一次的时候这个模型完全够用。但一旦设备上百、上报间隔缩短到 1-2 秒队列就会堆积表现为终端侧「发了没反应」或者「响应超时」。要突破这个边界常见做法有两种一是用BeginReceiveFrom/EndReceiveFrom做异步接收收到包后丢到线程池处理二是用多个Socket绑定同一端口需要设置ReuseAddress每个 Socket 一个接收线程。VB.NET 里异步模型写起来比 C# 啰嗦一些但逻辑是一样的。我一般会先跑单线程版本用压力测试工具打流看丢包率和处理延迟再决定要不要上异步。3. 消费机协议设计流水号、校验和重传怎么定3.1 自定义二进制协议还是文本协议消费机服务器和终端之间的协议格式直接决定了后面维护的痛苦程度。文本协议比如流水号|卡号|金额|时间戳可读性好调试方便用串口助手或者 UDP 调试工具就能看明白。二进制协议紧凑、解析快但调试时得对着十六进制看容易出错。我的经验是如果终端是 PC 或者性能还不错的嵌入式设备优先用文本协议开发效率高出问题好排查。如果终端资源紧张比如 8 位单片机或者单包大小直接影响流量成本再考虑二进制。这份源码标题里没提协议格式但消费机场景下文本协议加一个简单的校验字段是性价比最高的选择。3.2 流水号去重和 CRC16 校验的 VB.NET 实现UDP 不保证不重复终端重传或者网络抖动都可能导致服务器收到重复包。流水号是去重的关键终端每发一笔流水流水号自增服务器维护一个「已处理流水号」的滑动窗口收到重复的直接丢弃但依然要回 ACK否则终端会一直重传。校验方面热搜词里出现了「vb.net crc16编程」说明不少人在这个环节踩过坑。CRC16 用来检测数据在传输过程中是否被篡改或损坏比简单的累加和可靠。下面是一个 VB.NET 的 CRC16 实现用的是常见的 Modbus 多项式Module Crc16Helper CRC16-Modbus 查表法速度快适合高频调用的服务器端 Private ReadOnly CrcTable As UShort() { H0, HC0C1, HC181, H140, HC301, H3C0, H280, HC241, HC601, H6C0, H580, HC741, H500, HC941, HC981, H440 完整表有 256 项这里省略实际使用需补全 } Public Function ComputeCrc16(data As Byte(), offset As Integer, length As Integer) As UShort Dim crc As UShort HFFFF For i As Integer offset To offset length - 1 crc (crc 8) Xor CrcTable((crc Xor data(i)) And HFF) Next Return crc End Function 文本协议里把 CRC 拼在末尾用十六进制字符串表示 Public Function AppendCrc(payload As String) As String Dim bytes As Byte() Encoding.UTF8.GetBytes(payload) Dim crc As UShort ComputeCrc16(bytes, 0, bytes.Length) Return payload | crc.ToString(X4) End Function Public Function VerifyCrc(fullMsg As String) As Boolean Dim parts As String() fullMsg.Split(|c) If parts.Length 2 Then Return False Dim payload As String String.Join(|, parts, 0, parts.Length - 1) Dim expected As UShort Convert.ToUInt16(parts(parts.Length - 1), 16) Dim bytes As Byte() Encoding.UTF8.GetBytes(payload) Return ComputeCrc16(bytes, 0, bytes.Length) expected End Function End Module查表法的核心是把每个字节的 CRC 计算结果预先存好运行时只做移位和异或比逐位计算快很多。参数上注意两点初始值用HFFFF这是 Modbus 的标准多项式表必须完整上面只列了前 16 项实际项目里要补全 256 项否则校验结果对不上。校验失败时服务器应该直接丢弃该包不回 ACK让终端超时重传。3.3 超时重传和 ACK 机制的最小实现UDP 没有内置重传终端发完包后如果没收到 ACK得自己重发。服务器端的责任是收到合法包就回 ACKACK 里带上流水号终端收到后把该流水号标记为已完成。如果终端在 500ms 内没收到 ACK就重传重传 3 次还没成功就报警或者缓存到本地。服务器端实现 ACK 很简单就是在ProcessConsumeData返回的时候把流水号原样带回去。但要注意ACK 包本身也可能丢所以终端侧的重传逻辑必须独立于服务器。服务器不要主动重传 ACK否则在高并发下会放大流量。我一般会在服务器端加一个「最近处理流水号」的字典容量限制在 10000 条超出的按时间淘汰防止内存无限增长。4. 避坑与排查UDP 服务器端最容易翻车的五个点4.1 端口被占用通常每个套接字地址只允许使用一次现象服务器启动时报SocketException错误信息是「通常每个套接字地址(协议/网络地址/端口)只允许使用一次」。原因很明确上一次的服务进程还没完全退出端口处于TIME_WAIT或者被其他程序占用了。UDP 虽然没有 TCP 的TIME_WAIT但如果之前绑定了ExclusiveAddressUse或者有多个进程抢同一个端口就会报这个错。解决办法在Bind之前设置serverSocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, True)允许多个 Socket 绑定同一端口。另外排查时用netstat -ano | findstr :9000看端口被哪个 PID 占了任务管理器里结束掉。开发阶段建议把端口做成配置项别硬编码。4.2 收包缓冲区溢出导致丢包现象压力测试时终端侧显示发送成功但服务器日志里少了很多流水。原因通常是ReceiveBufferSize太小或者业务处理太慢导致内核缓冲区满了之后新来的包直接被丢弃。UDP 没有流控丢了就是丢了服务器根本不知道。解决办法把ReceiveBufferSize调到 1MB 以上同时把业务处理逻辑从接收循环里剥离出去用队列解耦。接收线程只负责收包和入队处理线程从队列里取数据慢慢处理。队列可以用ConcurrentQueue(Of Byte())VB.NET 里通过System.Collections.Concurrent引用。如果丢包依然严重就得考虑多线程接收或者异步模型了。4.3 中文乱码编码不一致的隐蔽坑现象终端发来的卡号或者备注信息里带中文服务器解析出来是乱码。原因是终端和服务器用的编码不一致终端可能用了 GBK服务器默认用 UTF-8 解码。解决办法协议里明确约定编码格式统一用 UTF-8。如果终端改不了服务器端就得按终端实际编码来解码。VB.NET 里用Encoding.GetEncoding(GBK)可以指定编码但要注意这个编码在 .NET Core 里需要额外注册。最稳妥的做法是在协议头里加一个编码标识字段服务器根据标识动态选择解码器。4.4 防火墙拦截 UDP 包现象本机测试一切正常部署到服务器后终端死活连不上。原因多半是 Windows 防火墙或者云服务商的安全组没放行 UDP 端口。UDP 是无连接的防火墙不会像 TCP 那样有明确的连接建立过程所以排查起来更隐蔽。解决办法在服务器上添加入站规则允许指定 UDP 端口的流量。云服务器还要检查安全组配置。测试时可以用udp端口测试工具或者iperf3的 UDP 模式打流确认端口是否真的通了。如果服务器有多张网卡绑定的时候用IPAddress.Any还是指定 IP也要根据实际网络拓扑来定。4.5 异步回调里的异常吞没现象服务器运行一段时间后某些终端的请求不再被处理但进程没崩溃日志里也没有明显错误。原因可能是用了BeginReceiveFrom异步模型回调函数里抛了异常但没捕获导致异步接收链断了后续的包再也收不到。解决办法在异步回调的最外层包一层Try...Catch任何异常都要记录日志并且重新调用BeginReceiveFrom把接收链续上。VB.NET 里异步回调的异常不会自动冒泡到主线程必须手动处理。我一般会在回调入口和出口都打日志方便确认接收链是否还活着。5. 进阶技巧用抓包和日志把 UDP 问题钉死UDP 服务器端最让人头疼的地方在于「没有连接状态」出了问题不好定位。终端说发了服务器说没收到到底是谁的问题这时候光看应用日志是不够的得把网络层的数据也抓下来。我常用的组合是 Wireshark 加自定义日志。Wireshark 过滤规则写udp.port 9000能看到每一个数据报的源 IP、目的 IP、长度和原始内容。如果 Wireshark 里能看到包但服务器日志里没有那问题就在服务器端的接收逻辑如果 Wireshark 里都没有那就是终端没发出来或者中间网络丢了。这一步能省掉大量扯皮时间。日志方面建议在服务器端记录四个关键字段收到时间、源终端标识、流水号、处理结果。格式用管道符分隔方便后续用脚本分析。下面是一个简单的日志写入函数Private Sub WriteUdpLog(remoteEP As EndPoint, seqNo As String, result As String) 日志按天分文件避免单个文件过大 Dim logDir As String C:\ConsumeServerLogs\ If Not IO.Directory.Exists(logDir) Then IO.Directory.CreateDirectory(logDir) Dim logFile As String logDir udp_ DateTime.Now.ToString(yyyyMMdd) .log Dim line As String DateTime.Now.ToString(HH:mm:ss.fff) | remoteEP.ToString() | seqNo | result Environment.NewLine 用 AppendAllText 简单追加高并发场景建议换成带锁的 StreamWriter IO.File.AppendAllText(logFile, line, Encoding.UTF8) End Sub这个函数每次调用都会打开和关闭文件在每秒几百包的场景下会成为瓶颈。正式环境里我会用一个独立的日志线程配合BlockingCollection做生产者消费者批量写入。参数上注意日志目录要有写权限否则会静默失败——这也是个血泪教训曾经因为权限问题排查了半天最后发现日志根本没写进去。还有一个验证手段是回环测试在一台机器上同时跑服务器和模拟终端用127.0.0.1通信排除网络因素。如果回环正常但跨机不正常基本就是防火墙或者路由问题。模拟终端可以用 VB.NET 写个小工具也可以直接用python socket脚本发 UDP 包灵活度高。最后说个习惯每次改完服务器端的接收逻辑我都会先用iperf3的 UDP 模式打一轮流看丢包率和吞吐量再上真实终端。这个步骤花不了几分钟但能提前暴露缓冲区、线程模型的问题。UDP 这东西玄学的地方不少但大部分「玄学」最后都能用抓包和日志解释清楚。希望帮到你。本文还有配套的精品资源点击获取