UDP适合实时性高、容忍丢包的场景，如设备发现、心跳上报、音视频信令、DNS查询、游戏状态同步；不适用于文件上传等需可靠传输的业务。
UDP 适合哪些 Python 网络场景
UDP 在 Python 中适用于对实时性要求高、能容忍少量丢包的场景，比如局域网内设备发现、心跳上报、音视频流前导信令、DNS 查询封装、游戏状态同步（非关键帧）。它不适用于需要可靠传输的业务逻辑，例如文件上传、API 响应、数据库同步。
典型做法是用 socket.socket(socket.AF_INET, socket.SOCK_DGRAM) 创建套接字，配合 sendto() 和 recvfrom() 进行无连接通信。注意：bind() 仅接收端必须调用，发送端可省略；但若发送端也 bind()，就能复用同一端口收发（比如实现简单回显服务）。
为什么 recvfrom() 常阻塞，又怎么避免
recvfrom() 默认是阻塞调用，没有数据时线程会挂起——这在单线程脚本里容易卡死，尤其做客户端轮询时。解决方式有三：
- 设超时：
sock.settimeout(1.0)，超时抛出socket.timeout异常，需捕获处理 - 用非阻塞模式：
sock.setblocking(False)，无数据时直接抛BlockingIOError - 结合
select.select()或selectors模块做多路复用，适合单线程管理多个 UDP 端口
别用 settimeout(0) 模拟非阻塞——它等价于 setblocking(False)，但语义不清，容易误读。
立即学习“Python免费学习笔记（深入）”；
UDP 数据报大小限制与截断风险
IPv4 下理论最大 UDP 报文是 65535 字节（含 IP+UDP 头），但实际受 MTU 限制。以太网默认 MTU 是 1500，减去 IP（20）和 UDP（8）头，应用层最多写 1472 字节。超过就会被 IP 层分片，一旦某一片丢失，整个 UDP 包就被内核丢弃——表现为“收不到”，而非“收到一半”。
本文档主要讲述的是android rtsp流媒体播放介绍；实时流协议（RTSP）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频，的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
Python 中若 sendto() 发送超过路径 MTU 的数据，系统通常不报错，但接收端 recvfrom() 可能只拿到截断后的前 1472 字节（取决于 socket 接收缓冲区和底层行为），且无任何警告。因此：
- 主动控制发送长度，建议 ≤1400 字节留足余量
- 接收端用足够大的 buffer（如
recvfrom(65535)），但要检查返回的实际长度 - 不要依赖
recvfrom()返回长度等于发送长度——丢包或截断都可能导致不一致
UDP 没有连接状态，所以没有“断开”概念
很多人误以为调用 close() 会通知对方“我下线了”，其实不会。UDP 是无状态协议，close() 只是释放本端 socket 资源，对端完全无感知。若需模拟“上线/下线”，得靠应用层协议：比如定期发心跳包，超时未收到即判定离线；或额外定义 BYE 类型消息，由双方约定解析。
另一个常见误区是复用已 close() 的 socket 发送数据——会触发 OSError: [Errno 9] Bad file descriptor。Python 不会自动重开，必须重新 socket() + bind()（如需指定端口）。
真正难处理的是“端口被占用”问题：UDP 端口释放后存在 TIME_WAIT 类似行为（虽然标准没定义），Linux 上可通过 sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) 允许快速重启绑定，Windows 下通常不需要。
