UDP发送端程序验证：sendto()返回正常但接收端无数据问题排查

我之前也碰到过一模一样的情况——sendto()返回成功但接收端啥都看不到，那种“明明代码没报错但就是没结果”的感觉真的挺闹心。咱们一步步拆解排查，总能找到问题：

1. 先把基础网络问题排除 #

• 先测连通性：在发送端和接收端之间跑个ping <接收端IP>，如果ping不通，先解决网络链路问题（比如不在同一网段、路由不通、跨设备的话要确认设备在同一个局域网）。
• 检查防火墙：不管是发送端还是接收端的防火墙（Windows Defender、Linux的ufw/iptables），必须确保目标UDP端口是开放的。比如Linux可以临时用ufw allow <端口号>/udp测试，Windows要在防火墙高级设置里添加入站/出站的UDP端口规则。

2. 死磕sendto()的参数细节 #

sendto()返回成功只说明内核收下了数据，不代表地址、端口这些参数是对的：

• 目标地址和端口绝对不能错：确认你传的目标IP是接收端的实际对外IP（别用127.0.0.1如果接收端在另一台机器），端口号和接收端监听的完全一致——UDP是无连接的，端口错了直接丢包，连个报错都没有。
• 地址结构体长度要准确：比如C语言里用sockaddr_in的话，最后一个参数必须是sizeof(struct sockaddr_in)，传错长度会导致内核解析地址失败，数据根本发不出去。
• 缓冲区要合法：别用野指针或者越界的内存当发送缓冲区，哪怕sendto()返回了长度，内核可能发送的是垃圾数据，接收端直接就丢了。

3. 检查数据包构造的坑 #

你提到载荷前32位是包序号，这里很容易踩字节序的坑：

• 字节序转换必须做：UDP传输用的是网络字节序（大端序），如果你的机器是小端序（绝大多数x86架构），直接把整数序号写到缓冲区，接收端解析出来的会是乱码，甚至被当成无效包丢弃。记得用htonl()把32位序号转成网络字节序再写入缓冲区。
• 可变长度计算要精准：确认发送的总长度是“32位序号 + 可变消息长度”，sendto()的长度参数必须和实际要发的字节数完全匹配，少传或多传都会导致接收端解析异常。

4. 用抓包工具实锤数据包状态 #

这是最直接的定位方法，能帮你分清是“没发出去”还是“发出去但丢了”：

• 在发送端用tcpdump（Linux）或Wireshark（全平台）抓包，过滤规则设为udp port <你的端口号>。如果抓不到包，说明sendto()的返回值是假成功，大概率是socket配置或参数问题；如果能抓到包，那问题就在接收端或传输链路（比如路由丢包、接收端防火墙拦截）。
• 抓到包后仔细看：目标IP、端口对不对？载荷里的序号是不是正确的网络字节序？消息内容和你预期的一致吗？

5. 确认接收端工具的配置 #

你用的SocketTest这类工具，别忽略这些细节：

• 监听的IP要对：如果接收端机器有多个网卡（有线、无线），要确保工具监听的是发送端能访问到的那个IP，别只监听127.0.0.1——不然跨机器的UDP包根本收不到。
• 切换到UDP模式：很多工具默认是TCP模式，一定要手动切到UDP监听。
• 记得点“开始监听”：别傻等，有些工具需要手动触发监听状态才会接收数据。

6. 检查发送端socket的配置 #

如果是自己写的socket初始化代码，确认：

• 创建socket时用的是SOCK_DGRAM：socket(AF_INET, SOCK_DGRAM, 0)，别手滑写成SOCK_STREAM（TCP）了。
• 别乱加奇怪的socket选项：比如有些选项会导致数据包静默丢弃，先试试用默认配置发送，排除自定义选项的影响。

7. 用最小化代码测试 #

把你的程序砍到最简化：发送一个固定长度的UDP包（比如前32位写0，后面跟"test"），目标地址直接写死成接收端的IP和端口，再测试能不能收到。如果简化版能收到，再逐步加回可变长度、序号等逻辑，快速定位哪段代码出了问题。

内容的提问来源于stack exchange，提问作者N.Las