常见以太网广播帧场景 | AI生成和翻译
以下是实际网络中最常见的以太网广播帧（目的MAC = FFFF.FFFF.FFFF）发送场景，以及具体由哪个设备将这类帧发送到网络中：
| 场景 | 发送的广播帧类型 | 发送设备 | 发送原因（触发条件） |
|---|---|---|---|
| ARP 请求 | 以太网目的MAC=FFFF.FFFF.FFFF + 以太类型 0x0806 | 需要解析IP地址的主机 | 主机需要访问同一子网下的另一IP地址但尚未知晓其MAC地址 → 向整个二层网络发送ARP请求 |
| DHCP 发现 / DHCP 请求 | 以太网目的MAC=FFFF.FFFF.FFFF + UDP源端口68 → 目的端口67 | 客户端（PC、手机等） | 客户端尚未获取IP地址（或正在续约）并寻找DHCP服务器 |
| IPv6 路由器请求 (RS) | 以太网目的MAC=33:33:00:00:00:02（全路由器组播），但邻居请求（DAD或查找）可能发往33:33:ff:xx:xx:xx；经典RS为组播而非广播 | IPv6主机 | 主机刚启动时需要发现路由器或执行重复地址检测 |
| NetBIOS/WINS 名称解析 | 以太网目的MAC=FFFF.FFFF.FFFF | Windows设备（传统网络） | 传统Windows网络协议尝试解析NetBIOS名称 |
| 网络唤醒（魔术包） | 以太网目的MAC=FFFF.FFFF.FFFF（或定向广播） | 同一网段内的其他主机 | 用于唤醒处于休眠状态的设备 |
| 传统IPX/SPX、AppleTalk等协议 | 以太网目的MAC=FFFF.FFFF.FFFF | 使用这些旧协议的设备 | 非IP协议中的服务发现 |
现代网络中最常见的广播帧场景（占广播帧总量的99%）：
-
ARP 请求 → 由需要获取本地IP对应MAC地址的主机或路由器发送
→ 示例：PC尝试ping 192.168.1.50 → 发送目的MAC为FFFF.FFFF.FFFF的ARP请求“谁有192.168.1.50？” -
DHCP 发现/请求 → 由客户端（笔记本、手机、物联网设备、虚拟机等）在启动或续约时发送
→ 设备在未获取IP地址时发送的第一个数据包几乎总是DHCP发现广播
哪些设备在正常运行时从不发送真实以太网广播？
- 三层交换机/路由器（它们会转发广播帧，但极少主动产生）
- 配置完善的现代服务器（通常使用静态IP，无需DHCP广播，且会缓存ARP表项）
总结
当本地网段中的设备需要与二层网络中的“所有设备”通信时（因为尚未知晓目标具体单播MAC地址，或协议本身设计为广播机制），就会发送广播帧（目的MAC = FFFF.FFFF.FFFF）。
当今最常见的发送者：
- 任何启动时的PC/笔记本/手机（DHCP）
- 任何需要解析IP→MAC映射的设备（ARP）