4、UDP协议模拟：UDP的无连接特性，使用Python实现UDP广播与组播通信
4.1 为什么我们要聊UDP的无连接特性？
说实话，很多刚接触网络编程的朋友，一上来就被TCP的三次握手搞懵了。但UDP不一样，它简单粗暴——想发就发，不需要建立连接。我在项目中遇到过好几次，有些同事总觉得UDP不靠谱，其实不然。
UDP的无连接特性，说白了就是：发送方不需要知道接收方是否在线，直接往网络上丢数据包就行。你想想看，这在某些场景下反而是优势。比如视频直播，你不可能等每个观众都握手确认了再推流吧？
核心要点：UDP没有连接建立和拆除的过程，数据包直接封装在IP层发送。这带来了低延迟，但也意味着不可靠——丢包了不会重传。
4.2 UDP广播——一呼百应的通信方式
广播是什么？就是你对整个局域网喊一嗓子，所有人都能听到。我记得刚做嵌入式开发那会儿，用UDP广播来发现局域网里的设备，省去了手动配置IP的麻烦。
4.2.1 广播地址怎么算？
广播地址通常是子网内的最大地址。比如你的IP是192.168.1.100，子网掩码是255.255.255.0，那广播地址就是192.168.1.255。当然，也有全局广播地址255.255.255.255。
小提示：在Python中，发送广播前一定要设置SO_BROADCAST选项，否则系统会拒绝你的广播请求。我曾经因为这个选项没设置，调试了半天才发现问题。
4.2.2 Python实现UDP广播发送端
import socket
def udp_broadcast_sender():
# 创建UDP套接字
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
# 允许广播——这一步不能少
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
# 广播地址和端口
broadcast_addr = ('192.168.1.255', 8888)
message = b"Hello, this is a broadcast message!"
try:
sock.sendto(message, broadcast_addr)
print(f"广播消息已发送到 {broadcast_addr}")
except Exception as e:
print(f"发送失败: {e}")
finally:
sock.close()
if __name__ == "__main__":
udp_broadcast_sender()4.2.3 Python实现UDP广播接收端
import socket
def udp_broadcast_receiver():
# 创建UDP套接字
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
# 绑定到所有接口的指定端口
sock.bind(('0.0.0.0', 8888))
print("等待广播消息...")
while True:
data, addr = sock.recvfrom(1024)
print(f"收到来自 {addr} 的广播: {data.decode()}")
if __name__ == "__main__":
udp_broadcast_receiver()注意：广播消息会被局域网内所有设备接收。如果设备数量很多，广播风暴会拖垮网络。我在一个工厂项目里就遇到过，200多台设备同时广播，网络直接瘫痪了。后来改成了组播。
4.3 UDP组播——精准投递的通信方式
组播比广播更优雅。它只把数据发给那些「订阅」了特定组播地址的设备。你想想看，就像订阅了一个公众号，只有关注的人才能收到推送。
4.3.1 组播地址范围
组播地址是D类IP地址，范围从224.0.0.0到239.255.255.255。其中：
| 地址范围 | 用途 |
|---|---|
| 224.0.0.0 - 224.0.0.255 | 本地链路组播，路由器不转发 |
| 224.0.1.0 - 238.255.255.255 | 全球范围组播 |
| 239.0.0.0 - 239.255.255.255 | 本地管理组播 |
我的建议：做嵌入式开发时，尽量用239.x.x.x这个范围的地址。它是本地管理的，不会和公网组播冲突。我之前用224.0.0.1，结果和系统预留的组播地址撞车了，排查了好久。
4.3.2 Python实现UDP组播发送端
import socket
import struct
def udp_multicast_sender():
# 创建UDP套接字
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
# 设置TTL（生存时间），控制组播传播范围
ttl = struct.pack('b', 2) # TTL=2，限制在局域网内
sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, ttl)
# 组播地址和端口
multicast_group = ('239.0.0.1', 9999)
message = b"Hello, this is a multicast message!"
try:
sock.sendto(message, multicast_group)
print(f"组播消息已发送到 {multicast_group}")
except Exception as e:
print(f"发送失败: {e}")
finally:
sock.close()
if __name__ == "__main__":
udp_multicast_sender()4.3.3 Python实现UDP组播接收端
import socket
import struct
def udp_multicast_receiver():
# 创建UDP套接字
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
# 允许端口复用——多个接收端可以绑定同一端口
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
# 绑定到所有接口的指定端口
sock.bind(('0.0.0.0', 9999))
# 加入组播组
multicast_group = '239.0.0.1'
# 这个结构体告诉内核：我要加入这个组播组
mreq = struct.pack('4sl', socket.inet_aton(multicast_group), socket.INADDR_ANY)
sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)
print(f"已加入组播组 {multicast_group}:9999，等待消息...")
while True:
data, addr = sock.recvfrom(1024)
print(f"收到来自 {addr} 的组播: {data.decode()}")
if __name__ == "__main__":
udp_multicast_receiver()4.4 广播 vs 组播，怎么选？
这个问题我经常被问到。其实选择很简单：
- 广播：适合小规模局域网，所有设备都需要接收的场景。比如设备发现、时间同步。
- 组播：适合有选择性的通信，只有部分设备需要接收。比如视频会议、数据分发。
经验之谈：能不用广播就不用广播。组播虽然配置稍微复杂一点，但可控性高得多。我在一个智能家居项目里，用组播实现了灯光分组控制——客厅的灯只接收客厅的组播，卧室的灯只接收卧室的组播，互不干扰。
4.5 避坑指南
嗯，这里要说说我踩过的坑：
- 防火墙拦截：Windows和Linux的防火墙默认会拦截UDP广播和组播。我曾经在客户现场调试，死活收不到数据，最后发现是防火墙的问题。
- 路由器隔离：很多家用路由器默认隔离广播域，不同网段之间收不到广播。组播也需要路由器开启IGMP Snooping才能跨网段。
- 端口冲突：多个程序绑定同一个端口会报错。记得用
SO_REUSEADDR选项，允许多个套接字共享端口。 - MTU限制：UDP数据包超过MTU（通常1500字节）会被分片，分片丢失会导致整个包无法重组。我建议UDP数据包控制在1400字节以内。
4.6 小结
UDP的无连接特性，让广播和组播成为可能。广播简单粗暴，适合小范围通知；组播精准高效，适合有选择的分发。在实际项目中，我建议优先考虑组播，除非你真的需要通知所有设备。
下一章我们会聊UDP的另一个重要应用——DNS查询模拟。到时候我会展示如何用Python模拟一个简单的DNS解析器，敬请期待。