1. 从一个“发出去就不管”的协议说起很多人第一次接触网络编程都是从 TCP 开始的三次握手、可靠传输、面向连接听起来就很“正经”。但真到了某些场景比如设备状态广播、局域网服务发现、日志上报、游戏里的位置同步你会发现 TCP 那套握手重传机制反而成了累赘。这时候 UDP 就登场了。UDP 全称是用户数据报协议它最大的特点就一句话发出去就不管了。不建立连接、不保证到达、不保证顺序甚至不保证不重复。听起来很不靠谱但正是这种“不靠谱”换来了极低的延迟和极小的开销。Python 里实现 UDP 通信简单到令人发指标准库socket几行代码就能跑起来不需要装任何第三方包。这篇内容我会把 Python 实现 UDP 通信这件事从头到尾拆开讲为什么选 UDP、socket模块里那几个关键参数到底什么意思、单播广播组播怎么玩、粘包和丢包怎么处理、实际项目里踩过的坑。适合刚学网络编程的新手也适合写了几年业务代码但没怎么碰过底层通信的开发者。看完你至少能做到自己写一个能跑通的 UDP 收发程序并且知道它在什么场景下会出问题、怎么排查。2. 为什么是 UDP而不是 TCP2.1 两者的本质差异决定了适用场景要理解 UDP 的价值得先看清楚它和 TCP 的根本区别。TCP 是面向连接的字节流协议它把数据看成一条源源不断的河流保证每个字节都按顺序到达。UDP 是面向数据报的它把每个数据包看成独立的信件寄出去之后邮局不负责追踪。这个差异带来几个直接后果。TCP 需要三次握手建立连接四次挥手断开这些过程都要消耗时间UDP 直接发没有这些开销。TCP 有拥塞控制网络一堵就主动降速UDP 不管这些你让它发多快它就发多快。TCP 保证可靠丢了会重传UDP 丢了就丢了应用层自己决定要不要管。我经常用寄快递来类比。TCP 像顺丰下单、上门取件、物流跟踪、签收确认一整套流程贵重物品放心。UDP 像往楼下信箱塞传单塞进去就完事对方看没看到、传单有没有被风吹走你都不知道。但如果你只是通知整栋楼“今晚停水”塞传单反而是最高效的方式。2.2 什么场景该用 UDP判断标准其实很简单如果你能容忍偶尔丢一两个包但对延迟极其敏感那就用 UDP。典型的场景有这么几类。第一类是实时音视频丢一帧画面用户可能根本察觉不到但如果为了重传这一帧导致后面卡顿半秒体验就崩了。第二类是游戏同步玩家的位置信息每秒发几十次丢一次无所谓下一次马上就补上了。第三类是服务发现和状态广播比如局域网里找打印机、找设备广播一个探测包谁在线谁回复。第四类是日志和监控数据上报丢几条日志不影响大局但要是每条都握手确认服务器压力会很大。反过来文件传输、网页请求、数据库操作这些绝对不能丢数据的场景老老实实用 TCP。我见过有人为了“性能”把订单数据用 UDP 传结果丢了一单这种坑千万别踩。2.3 Python 标准库的 socket 模块够用吗够用而且相当够用。Python 的socket模块是对操作系统 socket 接口的封装UDP 相关的操作无非就是创建套接字、绑定地址、收发数据这几步。不需要 asyncio 也能写不需要第三方库也能跑。当然如果你要处理高并发比如同时和上千个客户端通信那可能需要考虑asyncio的DatagramProtocol或者selectors模块做多路复用。但那是进阶话题先把基础的阻塞式 UDP 搞明白后面再谈优化。3. 核心 API 拆解每个参数都有它的脾气3.1 socket 创建时的两个关键参数创建 UDP 套接字的标准写法是import socket sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM)这里有两个参数必须搞清楚。第一个AF_INET表示使用 IPv4 地址族如果你要用 IPv6 就换成AF_INET6。第二个SOCK_DGRAM表示数据报套接字也就是 UDP对应的SOCK_STREAM是 TCP。这两个参数组合起来就决定了你拿到的是一个 UDP 套接字。有个细节很多人不知道socket.socket()还有第三个参数proto通常省略不写默认是 0。在 UDP 场景下基本用不到但如果你看到别人代码里写了不用慌那是协议号一般保持默认就行。3.2 bind、sendto、recvfrom 的分工UDP 套接字的核心方法就三个bind()、sendto()、recvfrom()。bind()用于服务端把一个套接字绑定到本机的某个 IP 和端口上。写法是sock.bind((0.0.0.0, 8888))。这里的0.0.0.0表示监听本机所有网卡如果你只想监听某个特定网卡就写那个网卡的 IP。端口号选 1024 以上1024 以下需要管理员权限。sendto()用于发送数据需要指定目标地址和端口sock.sendto(data, (192.168.1.100, 8888))。注意data必须是 bytes 类型字符串要先encode()。recvfrom()用于接收数据它会阻塞直到有数据到达返回一个元组(data, addr)data是收到的字节addr是发送方的地址和端口。这里有个坑recvfrom()需要指定缓冲区大小比如sock.recvfrom(1024)如果发来的数据超过 1024 字节超出的部分会被直接丢弃而且不会有任何提示。3.3 缓冲区大小的选择逻辑缓冲区大小设多少合适这取决于你的业务数据包大小。UDP 理论上最大能发 65507 字节65535 减去 IP 头 20 字节和 UDP 头 8 字节但实际上超过 MTU通常 1500 字节就会被分片分片越多丢包概率越大。我的经验是业务数据包控制在 1400 字节以内最稳妥这样能避免 IP 分片。对应的接收缓冲区设 2048 或 4096 就够了。如果你要传大文件别用 UDP真的用 TCP 或者自己在应用层做分片重组。# 推荐的缓冲区设置 BUFFER_SIZE 2048 data, addr sock.recvfrom(BUFFER_SIZE)注意recvfrom的缓冲区大小和sendto发送的数据大小是两回事。发送方可以发 5000 字节接收方缓冲区只有 1024那接收方只能拿到前 1024 字节剩下的静默丢失。这个坑我在实际项目里见过好几次排查起来很费劲。4. 从零写一个能跑通的 UDP 收发程序4.1 服务端绑定端口循环接收先写服务端。逻辑很简单创建套接字、绑定地址、死循环接收、处理、回复。import socket def udp_server(host0.0.0.0, port8888): sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind((host, port)) print(fUDP 服务端已启动监听 {host}:{port}) while True: data, addr sock.recvfrom(2048) message data.decode(utf-8) print(f收到来自 {addr} 的消息: {message}) # 回复客户端 reply f已收到你的消息: {message}.encode(utf-8) sock.sendto(reply, addr) if __name__ __main__: udp_server()这段代码有几个点值得说。decode(utf-8)是把字节转成字符串如果对方发的不是 UTF-8 编码这里会抛异常。生产环境建议加try-except或者用errorsignore。回复的时候直接用recvfrom返回的addr这样不用手动记录客户端地址。4.2 客户端发送并等待回复客户端更简单创建套接字后直接sendto然后recvfrom等回复。import socket def udp_client(server_host127.0.0.1, server_port8888): sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.settimeout(3) # 设置超时避免永久阻塞 message 你好我是客户端 sock.sendto(message.encode(utf-8), (server_host, server_port)) print(f已发送: {message}) try: data, addr sock.recvfrom(2048) print(f收到来自 {addr} 的回复: {data.decode(utf-8)}) except socket.timeout: print(等待回复超时服务端可能没启动) finally: sock.close() if __name__ __main__: udp_client()这里我加了settimeout(3)这是 UDP 客户端必须做的事。因为 UDP 不保证回复一定到达如果不设超时recvfrom会永远阻塞在那里程序就卡死了。超时时间设多少看业务局域网内 1 到 3 秒足够跨公网可以设 5 秒。4.3 先启动服务端再启动客户端测试的时候顺序不能反。先跑服务端看到“已启动”的打印再跑客户端。如果先跑客户端服务端还没绑定端口客户端的包发出去就丢了然后客户端超时退出。实测下来本机测试用127.0.0.1最稳。如果你想在局域网内两台机器测试服务端绑0.0.0.0客户端填服务端的局域网 IP。记得检查防火墙Windows 默认会拦截入站的 UDP 包第一次运行时会弹窗询问要点允许。5. 单播、广播、组播三种发送模式怎么选5.1 单播一对一最常用单播就是点对点发送sendto的目标地址是一个具体的 IP。这是最常用的模式客户端和服务端之间的通信基本都是单播。单播有个特点目标地址必须是可达的。如果你发到一个不存在的 IP包会在网络里游荡然后被丢弃发送方不会收到任何错误提示。这也是 UDP 让人又爱又恨的地方——它太安静了出错也不告诉你。5.2 广播一对多局域网专用广播是把包发给同一网段内的所有设备。要使用广播需要设置套接字选项sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1) sock.sendto(bhello, (255.255.255.255, 8888))255.255.255.255是受限广播地址只在本地网段有效路由器不会转发。也可以用子网广播地址比如192.168.1.255。广播的典型用途是服务发现。比如你写了一个局域网聊天工具启动时广播一个“谁在线”的包在线的客户端回复自己的信息这样就能自动发现彼此。但广播有个缺点同一网段所有设备都会收到不管它们想不想收所以不能滥用。5.3 组播一对多但更精准组播介于单播和广播之间它把包发给加入特定组播组的所有设备。组播地址范围是224.0.0.0到239.255.255.255。import socket import struct MCAST_GRP 224.1.1.1 MCAST_PORT 8888 sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP) sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock.bind((, MCAST_PORT)) # 加入组播组 mreq struct.pack(4sL, socket.inet_aton(MCAST_GRP), socket.INADDR_ANY) sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq) data, addr sock.recvfrom(2048) print(f收到组播消息: {data.decode()})组播比广播更节省网络资源因为只有加入组的设备才会处理这些包。但组播的配置稍微复杂而且需要网络设备支持。如果你的场景是局域网内几十台设备广播够用如果是上百台甚至跨网段组播更合适。模式目标地址适用范围配置复杂度单播具体 IP点对点通信低广播255.255.255.255 或子网广播地址同一网段中组播224.0.0.0 ~ 239.255.255.255跨网段、大规模高6. 丢包、粘包、乱序UDP 的三大经典问题6.1 丢包不是 bug是特性UDP 丢包是常态不是异常。丢包的原因有很多网络拥塞、接收方缓冲区满、MTU 超限被分片后丢片、防火墙拦截。处理丢包有两种思路。第一种是应用层重传发送方给每个包编号接收方收到后回复确认超时没收到确认就重发。这本质上是在 UDP 上实现了一个简化版的 TCP适合对可靠性有要求但又不想用 TCP 的场景。第二种是容忍丢包实时音视频、游戏同步这类场景丢一两个包无所谓下一个包马上补上不需要重传。我个人的经验是如果业务能容忍丢包就别做重传重传带来的延迟可能比丢包本身更影响体验。如果业务不能容忍丢包先问问自己为什么不用 TCP。6.2 粘包UDP 其实不存在这个问题很多人从 TCP 转过来会担心 UDP 粘包。这里明确说UDP 不存在粘包问题。因为 UDP 是面向数据报的每个sendto对应一个独立的数据报接收方的recvfrom一次只收一个数据报不会把两个包粘在一起。但 UDP 有另一个问题如果发送的数据超过接收缓冲区会被截断。比如发送方发了 3000 字节接收方缓冲区只有 1024那接收方只能拿到前 1024 字节剩下的 1976 字节直接丢失而且recvfrom不会报错。这个坑比粘包更隐蔽因为程序不会崩溃只是数据莫名其妙少了。解决办法很简单发送方和接收方约定好最大包大小接收缓冲区设得比最大包大一些。我一般建议业务包不超过 1400 字节接收缓冲区设 2048。6.3 乱序接收顺序不等于发送顺序UDP 不保证包的到达顺序。发送方按 1、2、3 的顺序发接收方可能按 3、1、2 的顺序收到。这在局域网内很少见但跨公网时概率不低。处理乱序的方法是在应用层给每个包加序号接收方根据序号重新排序。如果业务对顺序敏感比如文件传输那必须做排序如果只是状态更新比如游戏里的位置信息后到的包覆盖先到的包就行不需要排序。# 带序号的 UDP 包结构示例 import json def pack_message(seq, payload): return json.dumps({seq: seq, payload: payload}).encode(utf-8) def unpack_message(data): obj json.loads(data.decode(utf-8)) return obj[seq], obj[payload]用 JSON 做序列化简单直观但体积偏大。如果对性能有要求可以用struct模块做二进制打包或者用msgpack这类高效的序列化库。7. 实战中的坑与排查技巧7.1 端口被占用怎么办启动服务端时如果报OSError: [Errno 98] Address already in use说明端口被占用了。可能是上一个进程没退干净也可能是别的程序在用这个端口。排查方法Linux 下用lsof -i :8888或netstat -anp | grep 8888Windows 下用netstat -ano | findstr 8888。找到占用进程后要么杀掉它要么换个端口。如果确实需要快速重启服务端可以设置SO_REUSEADDRsock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock.bind((0.0.0.0, 8888))这个选项允许套接字绑定到处于 TIME_WAIT 状态的地址对 UDP 来说主要是避免重启时的等待。7.2 收不到数据怎么排查收不到数据是最常见的问题排查思路按顺序来第一步确认服务端真的启动了bind没报错。第二步确认客户端发的目标 IP 和端口正确本机测试用127.0.0.1局域网用服务端的实际 IP。第三步检查防火墙Windows 防火墙和 Linux 的 iptables 都可能拦截 UDP。第四步用抓包工具确认包到底有没有发出去、有没有到达。Linux 下用tcpdump -i any udp port 8888Windows 下用 Wireshark。我踩过最坑的一次是服务端绑定了127.0.0.1客户端从另一台机器发过来包根本到不了。因为127.0.0.1只监听本机回环接口外部流量进不来。改成0.0.0.0就好了。7.3 中文乱码问题UDP 传输的是字节不是字符串。发送方encode用什么编码接收方就得用什么编码decode。如果发送方用 UTF-8接收方用 GBK中文就会乱码。统一用 UTF-8 是最省事的做法。如果对方系统强制用 GBK那就在接收方做兼容处理try: message data.decode(utf-8) except UnicodeDecodeError: message data.decode(gbk, errorsignore)提示errorsignore会丢弃无法解码的字节适合日志类场景。如果数据不能丢用errorsreplace替换成占位符至少能看出哪里出了问题。7.4 常见问题速查表问题现象可能原因排查方法解决方案服务端启动报端口占用端口被其他进程占用netstat查占用进程杀进程或换端口客户端收不到回复服务端没启动或防火墙拦截抓包确认包是否到达检查防火墙、确认服务端运行收到数据不完整接收缓冲区小于发送数据打印数据长度对比增大缓冲区或限制包大小中文乱码编解码不一致检查两端编码设置统一用 UTF-8程序卡死不退出recvfrom永久阻塞加日志确认卡在哪一步设置settimeout局域网内收不到广播广播地址错误或防火墙抓包看广播包用子网广播地址、关防火墙测试8. 几个让代码更稳的实用技巧8.1 用 with 语句管理套接字套接字是系统资源用完必须关闭。虽然 Python 有垃圾回收但显式关闭更稳妥。socket对象支持上下文管理器with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as sock: sock.settimeout(3) sock.sendto(bhello, (127.0.0.1, 8888)) data, addr sock.recvfrom(2048)这样即使中间抛异常套接字也会被正确关闭。8.2 用 selectors 处理多客户端基础的阻塞式 UDP 服务端一次只能处理一个recvfrom如果同时有多个客户端发数据会排队处理。用selectors模块可以做多路复用同时监听多个套接字import selectors import socket sel selectors.DefaultSelector() def handle_read(sock): data, addr sock.recvfrom(2048) print(f收到 {addr} 的数据: {data.decode()}) sock.sendto(back, addr) server socket.socket(socket.AF_INET, socket.SOCK_DGRAM) server.bind((0.0.0.0, 8888)) server.setblocking(False) sel.register(server, selectors.EVENT_READ, handle_read) while True: events sel.select(timeout1) for key, mask in events: callback key.data callback(key.fileobj)这段代码看起来复杂但核心思想很简单把套接字注册到 selector 上selector 告诉你哪个套接字有数据可读你再去读。这样单线程就能处理多个套接字不需要开线程。8.3 心跳机制保持连接感知UDP 没有连接的概念服务端不知道客户端什么时候下线了。如果需要感知客户端状态可以在应用层做心跳客户端每隔几秒发一个心跳包服务端记录每个客户端的最后心跳时间超过一定时间没收到就认为下线。import time clients {} # {addr: last_heartbeat_time} def cleanup_timeout_clients(timeout30): now time.time() offline [addr for addr, t in clients.items() if now - t timeout] for addr in offline: del clients[addr] print(f客户端 {addr} 已超时下线)心跳间隔和超时时间要根据业务定。局域网内可以 5 秒心跳、15 秒超时跨公网建议 10 秒心跳、30 秒超时给网络波动留点余量。8.4 日志记录要包含地址信息UDP 服务端处理多个客户端时日志里一定要带上客户端地址否则出了问题根本不知道是谁发的。我习惯在每条日志里都带上addrimport logging logging.basicConfig(levellogging.INFO, format%(asctime)s - %(message)s) def log_message(addr, message): logging.info(f[{addr[0]}:{addr[1]}] {message})这样排查问题时能快速定位是哪个客户端的行为异常。9. 关于 UDP 通信的一点个人体会写了这么多最后说点实在的。UDP 这东西入门极简精通极难。几行代码就能跑通但要在生产环境用好需要考虑的东西非常多丢包重传策略、乱序处理、拥塞控制、NAT 穿透、安全防护每一个都是深坑。我的建议是如果 TCP 能满足需求就用 TCP。UDP 的优势只在特定场景下才体现得出来不要为了“高性能”而强行用 UDP。真到了必须用 UDP 的时候先把应用层的可靠性机制设计好再动手写代码。另外Python 的socket模块虽然简单但它是阻塞式的高并发场景下性能有限。如果 QPS 上去了可以考虑用asyncio的DatagramProtocol或者用 Go、Rust 这类更适合网络编程的语言重写核心部分。Python 适合做原型验证和中小规模服务这一点要心里有数。最后分享一个我常用的调试技巧写 UDP 程序时先写一个最简单的 echo 服务端和客户端确认能通之后再往上加业务逻辑。每次只改一个地方改完立刻测试。UDP 的问题往往很隐蔽一次性改太多东西出了问题根本不知道是哪一步引入的。这个习惯帮我省了无数排查时间。
1. 从一个“发出去就不管”的协议说起很多人第一次接触网络编程都是从 TCP 开始的三次握手、可靠传输、面向连接听起来就很“正经”。但真到了某些场景比如设备状态广播、局域网服务发现、日志上报、游戏里的位置同步你会发现 TCP 那套握手重传机制反而成了累赘。这时候 UDP 就登场了。UDP 全称是用户数据报协议它最大的特点就一句话发出去就不管了。不建立连接、不保证到达、不保证顺序甚至不保证不重复。听起来很不靠谱但正是这种“不靠谱”换来了极低的延迟和极小的开销。Python 里实现 UDP 通信简单到令人发指标准库socket几行代码就能跑起来不需要装任何第三方包。这篇内容我会把 Python 实现 UDP 通信这件事从头到尾拆开讲为什么选 UDP、socket模块里那几个关键参数到底什么意思、单播广播组播怎么玩、粘包和丢包怎么处理、实际项目里踩过的坑。适合刚学网络编程的新手也适合写了几年业务代码但没怎么碰过底层通信的开发者。看完你至少能做到自己写一个能跑通的 UDP 收发程序并且知道它在什么场景下会出问题、怎么排查。2. 为什么是 UDP而不是 TCP2.1 两者的本质差异决定了适用场景要理解 UDP 的价值得先看清楚它和 TCP 的根本区别。TCP 是面向连接的字节流协议它把数据看成一条源源不断的河流保证每个字节都按顺序到达。UDP 是面向数据报的它把每个数据包看成独立的信件寄出去之后邮局不负责追踪。这个差异带来几个直接后果。TCP 需要三次握手建立连接四次挥手断开这些过程都要消耗时间UDP 直接发没有这些开销。TCP 有拥塞控制网络一堵就主动降速UDP 不管这些你让它发多快它就发多快。TCP 保证可靠丢了会重传UDP 丢了就丢了应用层自己决定要不要管。我经常用寄快递来类比。TCP 像顺丰下单、上门取件、物流跟踪、签收确认一整套流程贵重物品放心。UDP 像往楼下信箱塞传单塞进去就完事对方看没看到、传单有没有被风吹走你都不知道。但如果你只是通知整栋楼“今晚停水”塞传单反而是最高效的方式。2.2 什么场景该用 UDP判断标准其实很简单如果你能容忍偶尔丢一两个包但对延迟极其敏感那就用 UDP。典型的场景有这么几类。第一类是实时音视频丢一帧画面用户可能根本察觉不到但如果为了重传这一帧导致后面卡顿半秒体验就崩了。第二类是游戏同步玩家的位置信息每秒发几十次丢一次无所谓下一次马上就补上了。第三类是服务发现和状态广播比如局域网里找打印机、找设备广播一个探测包谁在线谁回复。第四类是日志和监控数据上报丢几条日志不影响大局但要是每条都握手确认服务器压力会很大。反过来文件传输、网页请求、数据库操作这些绝对不能丢数据的场景老老实实用 TCP。我见过有人为了“性能”把订单数据用 UDP 传结果丢了一单这种坑千万别踩。2.3 Python 标准库的 socket 模块够用吗够用而且相当够用。Python 的socket模块是对操作系统 socket 接口的封装UDP 相关的操作无非就是创建套接字、绑定地址、收发数据这几步。不需要 asyncio 也能写不需要第三方库也能跑。当然如果你要处理高并发比如同时和上千个客户端通信那可能需要考虑asyncio的DatagramProtocol或者selectors模块做多路复用。但那是进阶话题先把基础的阻塞式 UDP 搞明白后面再谈优化。3. 核心 API 拆解每个参数都有它的脾气3.1 socket 创建时的两个关键参数创建 UDP 套接字的标准写法是import socket sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM)这里有两个参数必须搞清楚。第一个AF_INET表示使用 IPv4 地址族如果你要用 IPv6 就换成AF_INET6。第二个SOCK_DGRAM表示数据报套接字也就是 UDP对应的SOCK_STREAM是 TCP。这两个参数组合起来就决定了你拿到的是一个 UDP 套接字。有个细节很多人不知道socket.socket()还有第三个参数proto通常省略不写默认是 0。在 UDP 场景下基本用不到但如果你看到别人代码里写了不用慌那是协议号一般保持默认就行。3.2 bind、sendto、recvfrom 的分工UDP 套接字的核心方法就三个bind()、sendto()、recvfrom()。bind()用于服务端把一个套接字绑定到本机的某个 IP 和端口上。写法是sock.bind((0.0.0.0, 8888))。这里的0.0.0.0表示监听本机所有网卡如果你只想监听某个特定网卡就写那个网卡的 IP。端口号选 1024 以上1024 以下需要管理员权限。sendto()用于发送数据需要指定目标地址和端口sock.sendto(data, (192.168.1.100, 8888))。注意data必须是 bytes 类型字符串要先encode()。recvfrom()用于接收数据它会阻塞直到有数据到达返回一个元组(data, addr)data是收到的字节addr是发送方的地址和端口。这里有个坑recvfrom()需要指定缓冲区大小比如sock.recvfrom(1024)如果发来的数据超过 1024 字节超出的部分会被直接丢弃而且不会有任何提示。3.3 缓冲区大小的选择逻辑缓冲区大小设多少合适这取决于你的业务数据包大小。UDP 理论上最大能发 65507 字节65535 减去 IP 头 20 字节和 UDP 头 8 字节但实际上超过 MTU通常 1500 字节就会被分片分片越多丢包概率越大。我的经验是业务数据包控制在 1400 字节以内最稳妥这样能避免 IP 分片。对应的接收缓冲区设 2048 或 4096 就够了。如果你要传大文件别用 UDP真的用 TCP 或者自己在应用层做分片重组。# 推荐的缓冲区设置 BUFFER_SIZE 2048 data, addr sock.recvfrom(BUFFER_SIZE)注意recvfrom的缓冲区大小和sendto发送的数据大小是两回事。发送方可以发 5000 字节接收方缓冲区只有 1024那接收方只能拿到前 1024 字节剩下的静默丢失。这个坑我在实际项目里见过好几次排查起来很费劲。4. 从零写一个能跑通的 UDP 收发程序4.1 服务端绑定端口循环接收先写服务端。逻辑很简单创建套接字、绑定地址、死循环接收、处理、回复。import socket def udp_server(host0.0.0.0, port8888): sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind((host, port)) print(fUDP 服务端已启动监听 {host}:{port}) while True: data, addr sock.recvfrom(2048) message data.decode(utf-8) print(f收到来自 {addr} 的消息: {message}) # 回复客户端 reply f已收到你的消息: {message}.encode(utf-8) sock.sendto(reply, addr) if __name__ __main__: udp_server()这段代码有几个点值得说。decode(utf-8)是把字节转成字符串如果对方发的不是 UTF-8 编码这里会抛异常。生产环境建议加try-except或者用errorsignore。回复的时候直接用recvfrom返回的addr这样不用手动记录客户端地址。4.2 客户端发送并等待回复客户端更简单创建套接字后直接sendto然后recvfrom等回复。import socket def udp_client(server_host127.0.0.1, server_port8888): sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.settimeout(3) # 设置超时避免永久阻塞 message 你好我是客户端 sock.sendto(message.encode(utf-8), (server_host, server_port)) print(f已发送: {message}) try: data, addr sock.recvfrom(2048) print(f收到来自 {addr} 的回复: {data.decode(utf-8)}) except socket.timeout: print(等待回复超时服务端可能没启动) finally: sock.close() if __name__ __main__: udp_client()这里我加了settimeout(3)这是 UDP 客户端必须做的事。因为 UDP 不保证回复一定到达如果不设超时recvfrom会永远阻塞在那里程序就卡死了。超时时间设多少看业务局域网内 1 到 3 秒足够跨公网可以设 5 秒。4.3 先启动服务端再启动客户端测试的时候顺序不能反。先跑服务端看到“已启动”的打印再跑客户端。如果先跑客户端服务端还没绑定端口客户端的包发出去就丢了然后客户端超时退出。实测下来本机测试用127.0.0.1最稳。如果你想在局域网内两台机器测试服务端绑0.0.0.0客户端填服务端的局域网 IP。记得检查防火墙Windows 默认会拦截入站的 UDP 包第一次运行时会弹窗询问要点允许。5. 单播、广播、组播三种发送模式怎么选5.1 单播一对一最常用单播就是点对点发送sendto的目标地址是一个具体的 IP。这是最常用的模式客户端和服务端之间的通信基本都是单播。单播有个特点目标地址必须是可达的。如果你发到一个不存在的 IP包会在网络里游荡然后被丢弃发送方不会收到任何错误提示。这也是 UDP 让人又爱又恨的地方——它太安静了出错也不告诉你。5.2 广播一对多局域网专用广播是把包发给同一网段内的所有设备。要使用广播需要设置套接字选项sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1) sock.sendto(bhello, (255.255.255.255, 8888))255.255.255.255是受限广播地址只在本地网段有效路由器不会转发。也可以用子网广播地址比如192.168.1.255。广播的典型用途是服务发现。比如你写了一个局域网聊天工具启动时广播一个“谁在线”的包在线的客户端回复自己的信息这样就能自动发现彼此。但广播有个缺点同一网段所有设备都会收到不管它们想不想收所以不能滥用。5.3 组播一对多但更精准组播介于单播和广播之间它把包发给加入特定组播组的所有设备。组播地址范围是224.0.0.0到239.255.255.255。import socket import struct MCAST_GRP 224.1.1.1 MCAST_PORT 8888 sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP) sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock.bind((, MCAST_PORT)) # 加入组播组 mreq struct.pack(4sL, socket.inet_aton(MCAST_GRP), socket.INADDR_ANY) sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq) data, addr sock.recvfrom(2048) print(f收到组播消息: {data.decode()})组播比广播更节省网络资源因为只有加入组的设备才会处理这些包。但组播的配置稍微复杂而且需要网络设备支持。如果你的场景是局域网内几十台设备广播够用如果是上百台甚至跨网段组播更合适。模式目标地址适用范围配置复杂度单播具体 IP点对点通信低广播255.255.255.255 或子网广播地址同一网段中组播224.0.0.0 ~ 239.255.255.255跨网段、大规模高6. 丢包、粘包、乱序UDP 的三大经典问题6.1 丢包不是 bug是特性UDP 丢包是常态不是异常。丢包的原因有很多网络拥塞、接收方缓冲区满、MTU 超限被分片后丢片、防火墙拦截。处理丢包有两种思路。第一种是应用层重传发送方给每个包编号接收方收到后回复确认超时没收到确认就重发。这本质上是在 UDP 上实现了一个简化版的 TCP适合对可靠性有要求但又不想用 TCP 的场景。第二种是容忍丢包实时音视频、游戏同步这类场景丢一两个包无所谓下一个包马上补上不需要重传。我个人的经验是如果业务能容忍丢包就别做重传重传带来的延迟可能比丢包本身更影响体验。如果业务不能容忍丢包先问问自己为什么不用 TCP。6.2 粘包UDP 其实不存在这个问题很多人从 TCP 转过来会担心 UDP 粘包。这里明确说UDP 不存在粘包问题。因为 UDP 是面向数据报的每个sendto对应一个独立的数据报接收方的recvfrom一次只收一个数据报不会把两个包粘在一起。但 UDP 有另一个问题如果发送的数据超过接收缓冲区会被截断。比如发送方发了 3000 字节接收方缓冲区只有 1024那接收方只能拿到前 1024 字节剩下的 1976 字节直接丢失而且recvfrom不会报错。这个坑比粘包更隐蔽因为程序不会崩溃只是数据莫名其妙少了。解决办法很简单发送方和接收方约定好最大包大小接收缓冲区设得比最大包大一些。我一般建议业务包不超过 1400 字节接收缓冲区设 2048。6.3 乱序接收顺序不等于发送顺序UDP 不保证包的到达顺序。发送方按 1、2、3 的顺序发接收方可能按 3、1、2 的顺序收到。这在局域网内很少见但跨公网时概率不低。处理乱序的方法是在应用层给每个包加序号接收方根据序号重新排序。如果业务对顺序敏感比如文件传输那必须做排序如果只是状态更新比如游戏里的位置信息后到的包覆盖先到的包就行不需要排序。# 带序号的 UDP 包结构示例 import json def pack_message(seq, payload): return json.dumps({seq: seq, payload: payload}).encode(utf-8) def unpack_message(data): obj json.loads(data.decode(utf-8)) return obj[seq], obj[payload]用 JSON 做序列化简单直观但体积偏大。如果对性能有要求可以用struct模块做二进制打包或者用msgpack这类高效的序列化库。7. 实战中的坑与排查技巧7.1 端口被占用怎么办启动服务端时如果报OSError: [Errno 98] Address already in use说明端口被占用了。可能是上一个进程没退干净也可能是别的程序在用这个端口。排查方法Linux 下用lsof -i :8888或netstat -anp | grep 8888Windows 下用netstat -ano | findstr 8888。找到占用进程后要么杀掉它要么换个端口。如果确实需要快速重启服务端可以设置SO_REUSEADDRsock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock.bind((0.0.0.0, 8888))这个选项允许套接字绑定到处于 TIME_WAIT 状态的地址对 UDP 来说主要是避免重启时的等待。7.2 收不到数据怎么排查收不到数据是最常见的问题排查思路按顺序来第一步确认服务端真的启动了bind没报错。第二步确认客户端发的目标 IP 和端口正确本机测试用127.0.0.1局域网用服务端的实际 IP。第三步检查防火墙Windows 防火墙和 Linux 的 iptables 都可能拦截 UDP。第四步用抓包工具确认包到底有没有发出去、有没有到达。Linux 下用tcpdump -i any udp port 8888Windows 下用 Wireshark。我踩过最坑的一次是服务端绑定了127.0.0.1客户端从另一台机器发过来包根本到不了。因为127.0.0.1只监听本机回环接口外部流量进不来。改成0.0.0.0就好了。7.3 中文乱码问题UDP 传输的是字节不是字符串。发送方encode用什么编码接收方就得用什么编码decode。如果发送方用 UTF-8接收方用 GBK中文就会乱码。统一用 UTF-8 是最省事的做法。如果对方系统强制用 GBK那就在接收方做兼容处理try: message data.decode(utf-8) except UnicodeDecodeError: message data.decode(gbk, errorsignore)提示errorsignore会丢弃无法解码的字节适合日志类场景。如果数据不能丢用errorsreplace替换成占位符至少能看出哪里出了问题。7.4 常见问题速查表问题现象可能原因排查方法解决方案服务端启动报端口占用端口被其他进程占用netstat查占用进程杀进程或换端口客户端收不到回复服务端没启动或防火墙拦截抓包确认包是否到达检查防火墙、确认服务端运行收到数据不完整接收缓冲区小于发送数据打印数据长度对比增大缓冲区或限制包大小中文乱码编解码不一致检查两端编码设置统一用 UTF-8程序卡死不退出recvfrom永久阻塞加日志确认卡在哪一步设置settimeout局域网内收不到广播广播地址错误或防火墙抓包看广播包用子网广播地址、关防火墙测试8. 几个让代码更稳的实用技巧8.1 用 with 语句管理套接字套接字是系统资源用完必须关闭。虽然 Python 有垃圾回收但显式关闭更稳妥。socket对象支持上下文管理器with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as sock: sock.settimeout(3) sock.sendto(bhello, (127.0.0.1, 8888)) data, addr sock.recvfrom(2048)这样即使中间抛异常套接字也会被正确关闭。8.2 用 selectors 处理多客户端基础的阻塞式 UDP 服务端一次只能处理一个recvfrom如果同时有多个客户端发数据会排队处理。用selectors模块可以做多路复用同时监听多个套接字import selectors import socket sel selectors.DefaultSelector() def handle_read(sock): data, addr sock.recvfrom(2048) print(f收到 {addr} 的数据: {data.decode()}) sock.sendto(back, addr) server socket.socket(socket.AF_INET, socket.SOCK_DGRAM) server.bind((0.0.0.0, 8888)) server.setblocking(False) sel.register(server, selectors.EVENT_READ, handle_read) while True: events sel.select(timeout1) for key, mask in events: callback key.data callback(key.fileobj)这段代码看起来复杂但核心思想很简单把套接字注册到 selector 上selector 告诉你哪个套接字有数据可读你再去读。这样单线程就能处理多个套接字不需要开线程。8.3 心跳机制保持连接感知UDP 没有连接的概念服务端不知道客户端什么时候下线了。如果需要感知客户端状态可以在应用层做心跳客户端每隔几秒发一个心跳包服务端记录每个客户端的最后心跳时间超过一定时间没收到就认为下线。import time clients {} # {addr: last_heartbeat_time} def cleanup_timeout_clients(timeout30): now time.time() offline [addr for addr, t in clients.items() if now - t timeout] for addr in offline: del clients[addr] print(f客户端 {addr} 已超时下线)心跳间隔和超时时间要根据业务定。局域网内可以 5 秒心跳、15 秒超时跨公网建议 10 秒心跳、30 秒超时给网络波动留点余量。8.4 日志记录要包含地址信息UDP 服务端处理多个客户端时日志里一定要带上客户端地址否则出了问题根本不知道是谁发的。我习惯在每条日志里都带上addrimport logging logging.basicConfig(levellogging.INFO, format%(asctime)s - %(message)s) def log_message(addr, message): logging.info(f[{addr[0]}:{addr[1]}] {message})这样排查问题时能快速定位是哪个客户端的行为异常。9. 关于 UDP 通信的一点个人体会写了这么多最后说点实在的。UDP 这东西入门极简精通极难。几行代码就能跑通但要在生产环境用好需要考虑的东西非常多丢包重传策略、乱序处理、拥塞控制、NAT 穿透、安全防护每一个都是深坑。我的建议是如果 TCP 能满足需求就用 TCP。UDP 的优势只在特定场景下才体现得出来不要为了“高性能”而强行用 UDP。真到了必须用 UDP 的时候先把应用层的可靠性机制设计好再动手写代码。另外Python 的socket模块虽然简单但它是阻塞式的高并发场景下性能有限。如果 QPS 上去了可以考虑用asyncio的DatagramProtocol或者用 Go、Rust 这类更适合网络编程的语言重写核心部分。Python 适合做原型验证和中小规模服务这一点要心里有数。最后分享一个我常用的调试技巧写 UDP 程序时先写一个最简单的 echo 服务端和客户端确认能通之后再往上加业务逻辑。每次只改一个地方改完立刻测试。UDP 的问题往往很隐蔽一次性改太多东西出了问题根本不知道是哪一步引入的。这个习惯帮我省了无数排查时间。
