简介一份面向网络编程初学者的UDP通信示例工程基于VC环境开发完整演示了在Windows平台下如何使用Winsock库实现用户数据报协议UDP的客户端与服务器收发数据。代码包含客户端和服务器两个独立模块覆盖套接字创建、绑定、发送与接收、错误处理等关键流程是理解无连接传输协议及套接字编程基础知识的实用素材。压缩包内共15个文件以6个cpp源文件为核心配合3个h头文件、3个dsp工程文件和2个dsw工作区文件另有1个positions辅助文件整体体积仅11KB结构精简便于逐文件阅读和学习。目前已有131人浏览学习。通过这份Demo读者可以直观看到如何初始化Winsock库、构造sockaddr_in地址结构、绑定本地端口、调用sendto发送数据以及recvfrom接收数据并掌握常见错误码的处理方式。示例中的Client与Server代码相互呼应可直接编译运行适合作为课程实验或项目开发的参考模板也可帮助初学者快速建立网络编程的实操能力。1. UDP 与 VC 网络调试一份老 demo 为什么现在还值得跑手头这份 UDP.rar是 VC 6.0 时代的一套 UDP 通信 demo。Example.dsw 工作区里挂着两个工程Client.cpp 负责发送Server.cpp 负责接收代码量不大却没有框架包装适合直接抄来改。UDP 不建立连接、不保证有序、不保证送达但正因为它轻局域网里的状态上报、日志推送、音视频流至今还在用。当年我用它入门 Winsock现在做 UDP 网络调试还是拿它当骨架。这套 demo 适合两类人第一次接触 Winsock 的 VC 新手以及需要快速验证 UDP 端口测试、协议栈行为的维护工程师。它把 UDP 在 Windows 下的完整链路——初始化、建套接字、bind、sendto、recvfrom、收尾——全部摊在几百行代码里读一遍比翻十篇教程都管用。2. Winsock 初始化与建套接字让一个 UDP 端口活起来的三步拿到这份 demo别急着按 F5。我把 Server.cpp 从头读一遍你会发现它其实只做了三件事初始化 Winsock、创建 SOCK_DGRAM 套接字、把地址结构填对。这三件事任何一件出了问题后面全是白费。这一章就按这三步拆开讲。2.1 为什么是 SOCK_DGRAMUDP 与 TCP 的选型差异先回答一个我经常被问到的问题为什么 socket 的第二个参数填的是 SOCK_DGRAM而不是 SOCK_STREAM。这两个常量对应传输层两种完全不同的服务模型。TCP 是面向连接的数据像水管里的水流有序、可靠有确认、有重传UDP 是面向报文的数据像寄信封装成独立数据报投出去不管对方是否收到也不保证到达顺序。对比项TCPSOCK_STREAMUDPSOCK_DGRAM是否需要连接需要 connect 建立连接无连接直接发数据边界字节流应用层自己切包一次 sendto 对应一次 recvfrom可靠性确认、重传、保证有序不保证可能丢包、乱序典型场景文件传输、远程桌面设备状态上报、日志推送、流媒体对这份 demo 来说选 UDP 最重要的理由是调试门槛低。TCP 要处理三次握手、粘包拆包、连接断开重连一套流程跑下来真正想验证的网络链路反而被绕晕了。UDP 不一样一次 sendto、一次 recvfrom边界清清楚楚非常适合做 UDP 网络调试和端口测试。你在终端里用 iperf3 打 UDP 流也好写一个最小探测程序也好本质都是在验证数据报能不能顺利完成从 A 到 B 的链路——这正是 SOCK_DGRAM 存在的意义。2.2 WSAStartup 与 socket 创建初始化代码为什么不能省打开 Server.cpp头部的代码几乎都是同一个套路先 WSAStartup再 socket。这两步在教科书里常被一笔带过但实际开发里相当一部分「套接字创建失败」的报错都出在这几行。#include winsock2.h // 必须放在 windows.h 之前 #include ws2tcpip.h // inet_pton 需要的头文件 #pragma comment(lib, ws2_32.lib) // 链接 Winsock 库 WSADATA wsaData; int ret WSAStartup(MAKEWORD(2, 2), wsaData); if (ret ! 0) { printf(WSAStartup failed: %d\n, ret); return 1; } SOCKET udpSocket socket(AF_INET, SOCK_DGRAM, 0); if (udpSocket INVALID_SOCKET) { printf(socket failed: %d\n, WSAGetLastError()); WSACleanup(); return 1; }WSAStartup 的第一个参数 MAKEWORD(2, 2) 表示请求 2.2 版的 Winsock 规范第二个参数返回系统实际支持的版本。关键点是WSAStartup 必须在任何套接字调用之前执行一个进程只需要一次程序退出前要 WSACleanup 配对。很多新手把代码复制走忘了#pragma comment(lib, ws2_32.lib)这一行编译链接时直接报 unresolved external symbol。socket 的三个参数分别是地址族、套接字类型、协议。AF_INET 是 IPv4 地址族SOCK_DGRAM 是数据报套接字第三个参数 0 表示让系统根据前两个参数自动选择协议。返回值是 SOCKET 类型不是普通的 int判断失败要用 INVALID_SOCKET 而不是 -1。我实际排查中发现有人把 SOCKET 打印成 int 后高位丢失调试信息完全没法看算是一个隐蔽的小坑。注意WSAStartup 若返回 WSAVERNOTSUPPORTED说明请求的版本不被当前系统支持返回 WSASYSNOTREADY说明底层网络子系统未就绪。这类环境问题优先检查系统网络状态而不是代码。2.3 sockaddr_in 地址与端口字节序与初始化细节地址结构是下一个高频出错点。sockaddr_in 是 Windows 上最常用的 IPv4 地址结构bind、sendto、recvfrom 全都要和它打交道。sockaddr_in server_addr; ZeroMemory(server_addr, sizeof(server_addr)); // 先清零避免残留数据 server_addr.sin_family AF_INET; server_addr.sin_port htons(12345); // 端口转网络字节序 server_addr.sin_addr.S_un.S_addr inet_addr(192.168.1.100);三个字段分工明确sin_family 固定 AF_INETsin_port 存端口号必须经 htons 转换sin_addr 存 IP 地址。为什么必须转换x86 是小端序网络字节序是大端序htons 把主机序整数转成网络序否则端口会错乱。这个细节在局域网内未必立刻暴露但换到跨平台环境或做协议解析时一定翻车。如果 IP 来自配置或用户输入inet_addr 能直接把字符串转成 4 字节二进制失败返回 INADDR_NONE0xFFFFFFFF所以要单独判断。更现代一点的做法是用 inet_pton它同时支持 IPv4 和 IPv6返回值语义也更清晰#include ws2tcpip.h sockaddr_in server_addr; ZeroMemory(server_addr, sizeof(server_addr)); server_addr.sin_family AF_INET; server_addr.sin_port htons(12345); int rc inet_pton(AF_INET, 192.168.1.100, server_addr.sin_addr); if (rc ! 1) { // rc 0 表示字符串格式非法rc -1 表示地址族不支持 printf(inet_pton failed, rc%d\n, rc); return 1; }还有一个老手之间常提的细节sockaddr_in 一定要先清零再赋值。结构体里没被显式设置的字段如果残留垃圾数据bind 可能返回 WSAEADDRINUSEsendto 可能返回 WSAEFAULT而且 Release 版和 Debug 版表现还不一样典型的玄学问题。我一般拿到 demo 第一件事就是把每个地址结构都加上 ZeroMemory一行代码省掉大量莫名的定位时间。提示服务端要监听本机所有网卡时sin_addr 写 htonl(INADDR_ANY)不要写具体 IP。写具体 IP 的话只有发往该 IP 的数据报能被收到跨网段调试时非常容易踩中。2.4 常见错误码速查UDP 调试离不开 WSAGetLastError。下面这几个错误码出现频率最高值得先记在脑子里。错误码数值含义常见诱因WSAEADDRINUSE10048端口被占用上一个进程没退出或误绑了已占用的端口WSAEACCES10013权限不足端口小于 1024或被防火墙策略拦截WSAEFAULT10014缓冲区非法sockaddr 结构体未清零或长度参数错误WSAEMSGSIZE10040报文长度超限接收缓冲区小于到达报文报文被截断WSAEHOSTUNREACH10065主机不可达目标地址错误或跨网段路由不通我排查 UDP 问题时习惯把错误码表和 netstat 输出放在一起看。错误码只能告诉你系统层发生了什么真正的原因往往要回到端口状态和防火墙规则上去找。3. Client 与 Server 实现用 sendto/recvfrom 把链路拉通初始化做完套接字已经存在接下来就是把两端拼起来。Server 端的核心是 bind 加 recvfrom客户端核心是 sendto。这一章按工程文件的实际结构走一遍代码顺序也尽量贴近你打开 Server.cpp 和 Client.cpp 时看到的顺序。3.1 Server 必须先 bind不占住端口就没有收包资格在 UDP 通信里Server 的定义不是「接受连接」而是「监听某个端口」。bind 的作用是把套接字和本地地址、端口绑定之后系统才会把发往这个端口的数据报投给这个套接字。不 bind 的话套接字没有固定端口recvfrom 就不知道该从哪里收数据。sockaddr_in local_addr; ZeroMemory(local_addr, sizeof(local_addr)); local_addr.sin_family AF_INET; local_addr.sin_port htons(12345); local_addr.sin_addr.S_un.S_addr htonl(INADDR_ANY); int ret bind(udpSocket, (struct sockaddr*)local_addr, sizeof(local_addr)); if (ret SOCKET_ERROR) { printf(bind failed: %d\n, WSAGetLastError()); closesocket(udpSocket); WSACleanup(); return 1; }bind 三个参数的顺序是套接字、通用地址指针、地址长度。Winsock 接口历史地选用了通用 sockaddr 指针所以 sockaddr_in 要强转过去长度要靠第三个参数告诉内核。bind 成功后不用 listen、不用 acceptUDP 的套接字立刻就能收发——这是和 TCP 服务端最大的区别第一次看的人总觉得「少了一步」。bind 失败时先看错误码再动手。WSAEADDRINUSE 意味着端口已被占用多半是上一个进程还在运行或者调试时开了两个服务端窗口。WSAEACCES 常见于端口小于 1024 或防火墙策略拦截。排查顺序我一般固定为netstat 查端口占用任务管理器清残留进程然后再重启 demo。顺序反了会在同一个坑上反复跳。3.2 Server 的接收循环recvfrom 的阻塞与来源地bind 之后进入接收循环。阻塞模式下recvfrom 会一直停在原地直到有数据报到达才返回。从旁观者角度看程序像卡死了其实它在等包。这一个特性让很多新手误以为 demo 写错了。char recvBuf[1024]; // 接收缓冲区 sockaddr_in client_addr; // 用于获取发送端地址 int addrLen sizeof(client_addr); while (true) { ZeroMemory(client_addr, sizeof(client_addr)); addrLen sizeof(client_addr); // 每次循环都要重新赋值 int bytesRecv recvfrom(udpSocket, recvBuf, sizeof(recvBuf) - 1, 0, (struct sockaddr*)client_addr, addrLen); if (bytesRecv SOCKET_ERROR) { printf(recvfrom failed: %d\n, WSAGetLastError()); break; } recvBuf[bytesRecv] \0; // 手动补字符串结束符 printf(recv %d bytes from %s:%d\n, bytesRecv, inet_ntoa(client_addr.sin_addr), ntohs(client_addr.sin_port)); }recvfrom 的参数密度很高逐个说第一个是套接字第二个是接收缓冲区第三个是缓冲区大小我习惯减一留一个字节给结束符第四个 flags 填 0第五个是输出型参数函数返回后里面保存发送方的地址和端口第六个是地址长度的指针调用前必须初始化成 sizeof(client_addr)。第六个参数最容易写错它要的是指针不是值。填错之后要么返回 WSAEFAULT要么地址信息被截断调试信息里看到的 IP 永远是 0.0.0.0。缓冲区大小直接决定单次能收的最大报文。UDP 单报文理论上限是 65507 字节但实际网络中路径 MTU 会更早卡住。局域网内的调试1024 字节足够如果要做超过 MTU 的数据报传输就要考虑调整缓冲区并处理 WSAEMSGSIZE。另外注意recvBuf 读到的字节数和实际收到的报文长度相等结束符要自己补系统不会帮你加。3.3 客户端的 sendto目标地址、长度与返回值客户端的重点在 Client.cpp 的 sendto。它不需要 bind系统会在第一次调用时自动分配临时端口这也是 UDP 客户端可以「即发即走」的原因。// 用一个简单的循环演示连续发送 const char* sendBuf Hello, UDP!; sockaddr_in server_addr; ZeroMemory(server_addr, sizeof(server_addr)); server_addr.sin_family AF_INET; server_addr.sin_port htons(12345); server_addr.sin_addr.S_un.S_addr inet_addr(192.168.1.100); for (int i 0; i 10; i) { int bytesSent sendto(udpSocket, sendBuf, (int)strlen(sendBuf) 1, 0, (struct sockaddr*)server_addr, sizeof(server_addr)); if (bytesSent SOCKET_ERROR) { printf(sendto failed: %d\n, WSAGetLastError()); break; } Sleep(1000); // 每秒发一包方便配合抓包观察 }sendto 的参数和 recvfrom 高度对称唯一差别是第五、第六个参数是输入型给的是目标地址和长度。数据长度这里写的是strlen(sendBuf) 1把 \0 一起发出去接收端可以直接按字符串处理。如果你的协议是二进制长度就应该是结构体大小或实际数据字节数这一点非常容易踩。sendto 的返回值要冷静地看。它返回成功只代表数据交给了协议栈不代表对端收到了。UDP 没有连接数据发出后是路由、防火墙、对端协议栈的事。目标端口没进程监听时路由器或主机可能回一个 ICMP 端口不可达但这个反馈通常不会同步出现在 sendto 的返回值里。真要判断链路质量靠的是对端回显或者用 iperf3 这类工具做 UDP 打流统计。3.4 收尾顺序closesocket 与 WSACleanupdemo 的退出流程容易被当成「最后随便写写」其实顺序有讲究先 closesocket 关闭套接字再 WSACleanup 释放 Winsock。反过来先 WSACleanup再 closesocket 会得到 WSAENOTSOCK多数情况下不会崩溃但属于未定义行为。closesocket(udpSocket); // 先关套接字 udpSocket INVALID_SOCKET; WSACleanup(); // 再释放 Winsock在老版本代码里偶尔能看到用 CloseHandle 去关 SOCKET 的写法那是错的套接字是 Winsock 句柄不是内核 HANDLE必须用 closesocket。长期运行的程序还要注意 WSAStartup 和 WSACleanup 配对次数调用几次就清理几次不配对的话多次初始化后 socket 创建可能报错而且报错位置离根因很远排查成本很高。3.5 什么时候才需要多线程或异步 I/Odemo 是单线程的单线程意味着同一时间只能做一件事要么阻塞在 recvfrom 收包要么去干别的。如果你的程序除了收 UDP 还要处理界面消息、执行定时任务、保存日志就必须考虑把网络接收拆到独立线程或者用事件驱动模型。最简单的拆分是开一个线程专门跑 recvfrom 循环主线程做业务。DWORD WINAPI RecvThread(LPVOID param) { SOCKET sock (SOCKET)param; char buf[2048]; while (running) { // running 是全局退出标志 int n recvfrom(sock, buf, sizeof(buf), 0, NULL, NULL); if (n 0) { // 把数据交给处理队列主线程从队列取 } } return 0; }多线程接收要把握一个原则recvfrom 本身只在接收线程里调用不要在多个线程同时对同一个套接字调用 recvfrom否则 Winsock 会随机派发报文逻辑乱序且很难定位。异步 I/O 是之后的进阶选择比如 WSAAsyncSelect 或完成端口在报文量大、连接数多时才体现出优势demo 这个阶段用线程就够。4. UDP demo 避坑指南五个高频问题与排查思路4.1 现象sendto 返回成功对方就是收不到排查第一步是认清一个事实sendto 返回成功只说明数据交给了协议栈之后的路径不在你控制范围。这种情况优先怀疑三处目标 IP 和端口写错、防火墙拦截 UDP 入站、对端 recvfrom 根本没在收。常见做法是先在本机开一个 UDP 端口测试工具例如用 iperf3 带-u参数对目标机器打流确认 UDP 通路本身是好的。再用 Wireshark 在目标机器抓包如果数据出现在抓包里而应用收不到基本可以判定是防火墙或 bind 的问题如果抓包都看不到问题出在路由或发送端。Windows 防火墙对入站 UDP 的提示很少包被静默丢弃很多 UDP 调试的深夜都耗在这上面。如果以上都查过还是不通最后一步是把服务端程序换成最小 echo 版本收包后原样回发给客户端。客户端收到回包说明链路双向都通收不到就把关注点放回防火墙和路由。这个办法能有效地把「网络问题」和「程序问题」切开。4.2 现象recvfrom 一直阻塞程序像死掉了如果服务端是单线程recvfrom 阻塞期间程序无法响应界面消息窗口显示「未响应」但这不是死锁是 recvfrom 没返回。解决思路有两条把 recvfrom 放进独立线程或者用 select 加超时。// 用 select 实现带超时的接收避免永久阻塞 struct timeval timeout; timeout.tv_sec 3; // 3 秒超时 timeout.tv_usec 0; fd_set readSet; FD_ZERO(readSet); FD_SET(udpSocket, readSet); int ret select(0, readSet, NULL, NULL, timeout); if (ret 0 FD_ISSET(udpSocket, readSet)) { // 有数据可读此时 recvfrom 不会阻塞 int bytesRecv recvfrom(udpSocket, recvBuf, sizeof(recvBuf) - 1, 0, NULL, NULL); } else if (ret 0) { printf(recv timeout\n); // 超时按需处理 }select 的返回值语义要记牢大于 0 表示有套接字可读0 表示超时SOCKET_ERROR 说明参数有问题。Windows 上 select 的第一个参数可以填 0虽然书籍里写的是「最大文件描述符加一」但那是 Linux 的习惯移植代码时不用照搬。4.3 现象本机环回通过跨机器就失败本机 127.0.0.1 能收发换成局域网 IP 就不通这是 UDP 调试里最高频的场景。原因通常是服务端 bind 到了 127.0.0.1只监听环回口或者客户端目标 IP 写成了本机 IP 之外的其他地址还有一种常见情况是多网卡机器上bind 的 IP 不是数据实际进入的网卡。处理办法服务端 bind 用 INADDR_ANY或者先用 ipconfig 确认实际网卡 IP别猜。这里可以配合 UDP 探测脚本从 A 机器向目标机器的多个端口发探测数据逐个端口确认哪些有响应很快就能把问题范围缩小到端口或防火墙。多网卡环境下抓包时也要选对网卡不然怎么抓都是空的。4.4 现象缓冲区太小收包被截断发送端一次发出 3000 字节接收端缓冲区只有 1024recvfrom 会返回失败错误码 WSAEMSGSIZE数据被截断。这个现象在局域网调试里容易忽视因为小报文怎么测都正常一旦报文变大就出问题。解决方式是先确认你的报文大小上界再设缓冲区。UDP 理论单报文上限是 65507 字节但实际也会受 MTU 影响超过 1472默认 MTU 1500 减去 IP 头和 UDP 头就可能触发分片或丢弃。如果你发的报文接近 MTU我建议要么缩小单包设计要么在接收端用足够大的缓冲区并显式处理 WSAEMSGSIZE。缓冲区大不等于无脑大但要先解决截断问题再考虑内存这是顺序问题。4.5 现象VC 工程编译不过报一堆链接错误VC 6.0 写出来的 .dsp 工程拿到新版 Visual Studio 里最常见的坑有两个winsock2.h 和 windows.h 的包含顺序冲突以及 ws2_32.lib 没链接。包含顺序上winsock2.h 要在 windows.h 之前或者定义 WIN32_LEAN_AND_MEAN 后再引 windows.h否则会出现大量的重定义错误。链接错误 unresolved external symbol 的成因很单一——缺库。工程属性里找到链接器、输入、附加依赖项加上 ws2_32.lib或者在代码顶部#pragma comment(lib, ws2_32.lib)。另外.dsp 转换到新版工程后字符集、目标平台版本这些默认值会变转换完建议逐项检查一遍。新版 VS 默认创建的是 .vcxproj 工程老 .dsp 的转换向导一般能处理但处理完的工程属性不能完全信任要重新过一遍。5. 验证一条 UDP 链路端口观察、多线程接收与丢包统计5.1 用 netstat 确认端口真的在收demo 跑起来后第一件事不是看 printf而是先看端口状态。netstat -an | findstr 12345输出里出现UDP 0.0.0.0:12345 *:*说明 bind 成功端口开放。如果找不到这一行说明程序根本没活到 bind。加一个netstat -s -p udp可以看 UDP 统计信息包括接收错误、丢包计数这是 UDP 端口测试里最直接的验证手段。等 demo 正常收发后再用同样的命令对比前后统计值就能判断链路是否真的在走数据。5.2 扩展多线程接收与丢包统计单线程 demo 只能验证最基本链路实际产品里我会在 Server 里开独立接收线程主线程负责协议解析或界面刷新。注意 recvfrom 的套接字不要被多个线程同时读Winsock 会在多个线程之间随机分配报文造成数据乱序这不是网络问题是并发设计问题。丢包统计是 UDP 调试的核心指标。发送端每发一包带上递增序号接收端记录已收序号中间缺失的就是丢包。跑一轮就能判断链路质量也能顺带验证缓冲区设置是否合理。我通常在 demo 基础上加一个 60 秒的连续发送模式每秒 100 包跑完看丢包率比抓包直观得多。5.3 我的一个实测习惯最后说个习惯。我每次拿到这类 demo都会先改两处再跑一是把 sendBuf 和 recvBuf 都放大到 1024 以上并清零二是强制给每个地址结构做 ZeroMemory。这两个改动看起来不起眼但都来自我踩过的坑——一次是结构体没清零导致 bind 随机失败一次是小缓冲区让大报文静默截断定位花了整个下午。从那以后凡是经我手的 UDP 代码初始化清零、长度显式传递、返回值逐条判断这三件事强制走一遍成了固定动作。如果你也要在这个 demo 基础上扩展成自己的工具建议从这三个动作开始它们不影响功能但能省掉大量定位时间。希望帮到你。本文还有配套的精品资源点击获取