Python UDP 通信的适用场景与限制

udp适合实时音视频、dns查询、iot心跳、游戏同步等“丢包可容忍”或“上层自兜底”场景；其无连接特性要求手动处理地址绑定、编码、缓冲区及错误排查。

UDP 适合哪些场景？

UDP 不保证送达、不排序、不重传，所以它只适合「丢了也不关键」或「自己能兜底」的通信。典型用法是：实时音视频流、DNS 查询、IoT 设备心跳上报、游戏状态同步（部分）、局域网内快速广播发现服务。

常见错误现象：[errno 111] Connection refused 或 [Errno 101] Network is unreachable 经常被误认为是 UDP 本身出错，其实 UDP 的 sendto() 在目标不可达时通常**不报错**——它直接发出去就完了，错误往往在接收端或中间网络设备上才暴露。

• 如果你需要确认对方收到了，得自己加序列号 + ACK 机制，不是靠 UDP
• DNS 用 UDP 是因为查询短、快、容忍重试；一旦响应超 512 字节，会退到 TCP，这不是 UDP 的错，是协议设计选择
• 跨公网用 UDP 要小心 NAT 类型，对称型 NAT 会让 p2p 直连失败，得靠 STUN/TURN

python 中 socket.SOCK_DGRAM 怎么用才不出错？

Python 的 UDP socket 构建和 TCP 完全不同：不能 connect() 后直接 send()（除非你明确想限制目标地址），绝大多数情况必须用 sendto() 并显式传入地址元组。

容易踩的坑：

立即学习“Python免费学习笔记（深入）”；

• 绑定本地端口时没设 SO_REUSEADDR，重启程序报 [Errno 48] Address already in use —— 加 sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
• 发送中文或非 ASCII 数据忘了 encode，直接传字符串会抛 TypeError: a bytes-like Object is required —— 必须 data.encode('utf-8')
• 接收缓冲区太小，recvfrom(1024) 截断了大数据包，UDP 不像 TCP 会自动分片重组 —— 根据业务预估最大包长，比如 DNS 响应一般 ≤ 4096，可设 recvfrom(65535)

为什么 UDP 收不到包？排查顺序是什么？

UDP 没连接状态，收不到包时没法靠“连接是否建立”来判断，得一层层排除。优先级从近到远：

• 检查本地 socket 是否绑定了正确地址：bind(('0.0.0.0', 8080)) 才能收所有网卡进来的包；用 bind(('127.0.0.1', 8080)) 就只能收本地回环
• 确认防火墙放行了 UDP 端口（macos 的 `pf`、linux 的 `iptables/nftables`、windows 防火墙都可能拦截）
• 用 tcpdump -i any udp port 8080 或 wireshark 看包到底到没到网卡 —— 如果抓不到，问题在发送端或网络路径；如果抓到了但 Python 没收到，大概率是 bind 地址/端口不对，或 socket 被意外 close
• 注意：同一台机器上两个 UDP socket 不能 bind 同一端口，除非用了 SO_REUSEPORT（Linux 3.9+ / macOS 10.11+），否则后启动的会失败

UDP 和 TCP 混用时要注意什么？

一个常见需求是：用 UDP 发控制指令（快），用 TCP 传大文件（稳）。这时最容易忽略的是端口复用和 socket 生命周期管理。

• 不要让 UDP socket 和 TCP socket 绑定同一端口（比如都 bind ('0.0.0.0', 8000)），即使加了 SO_REUSEADDR，行为也因系统而异；最好分开端口，比如 UDP 8000、TCP 8001
• UDP socket 不会因对端宕机而触发异常，所以不能靠 recvfrom() 抛异常来判断对方下线；得配合心跳包 + 超时计数
• 如果用 asyncio 写混合协议，别混用 loop.create_datagram_endpoint() 和 loop.create_server() 的 transport 接口——前者是无连接的，后者是面向连接的，状态管理逻辑完全不同

UDP 的边界感很强：它只负责把包扔进网络层，剩下的全是你的事。写得越简单，越容易漏掉超时、重试、分片、乱序这些本该由上层补足的环节。