1、广播丢包现象概述
各位好，我是老张。做无线网络这行十几年了，今天咱们聊聊WiFi广播丢包这个话题。说实话，这问题看着简单，坑却不少。我见过不少项目，最后查来查去，根因就是广播丢包。
先问个问题：你手机刷视频卡了，第一反应是什么？多半是“网速不行”。但很多时候，根本不是带宽不够，而是广播包丢了。嗯，这里面的门道，咱们一点点拆开看。
1.1 什么是WiFi广播
WiFi广播，说白了就是“一个人说话，所有人听”。
在802.11协议里，广播帧的目标MAC地址是 FF:FF:FF:FF:FF:FF。只要AP发出这个帧，所有关联的STA都得收。不管你想不想听，都得听。
关键特征：
- 无确认机制：发出去就不管了，没有ACK
- 无重传：丢了就是丢了，不会补发
- 低速率发送：通常用1Mbps或6Mbps基本速率
我刚开始做WiFi时，觉得广播挺省事的。后来才发现，省事的代价就是不可靠。
1.2 广播与单播/组播的区别
这三者的区别，我习惯用一个比喻来解释：
- 单播：像快递员送货上门，签收确认，丢了重发
- 组播：像群发邮件，只有订阅的人收到
- 广播：像大喇叭喊话，谁都能听见，但没人给你回“收到了”
咱们看个表格，对比更清楚：
| 特性 | 单播 | 组播 | 广播 |
|---|---|---|---|
| 目标地址 | 单一MAC | 组播MAC | FF:FF:FF:FF:FF:FF |
| ACK确认 | 有 | 无（通常） | 无 |
| 重传机制 | 有 | 无 | 无 |
| 发送速率 | 可协商（高） | 固定（中低） | 固定（最低） |
| 信道占用 | 按需 | 一次发送 | 一次发送 |
| 可靠性 | 高 | 中 | 低 |
避坑指南：我曾经在一个项目中，把组播当广播用，结果终端设备死活收不到数据。后来才发现，组播需要IGMP snooping配合，不是所有交换机都默认支持。
1.3 广播丢包对业务的影响
广播丢包不是小事。我挑三个最常见的场景说说。
1.3.1 视频监控
监控系统里，很多IPC（网络摄像头）用组播或广播来发现设备。你想想看，如果广播包丢了，NVR就搜不到摄像头。
我遇到过一家工厂，装了50多个摄像头，总有那么几个“掉线”。查了半天，不是摄像头坏了，是广播发现阶段的包丢了。后来改成手动添加IP，问题就解决了。
广播丢包在监控里的典型表现：
- 设备列表刷新不全
- 新加入的摄像头无法自动发现
- ONVIF探测失败
1.3.2 投屏
投屏协议（Miracast、AirPlay、DLNA）在发现阶段，几乎都依赖广播或组播。
你手机搜不到电视，十有八九是广播包丢了。我做过一个测试：在密集WiFi环境（比如办公室），投屏发现成功率不到60%。
注意：投屏的广播丢包，不只是发现阶段。连接后的媒体流如果走组播，丢包会导致画面花屏、声音卡顿。而且因为没重传，这种卡顿是“永久性”的——不会自己恢复。
1.3.3 IoT设备
IoT设备，尤其是智能家居，大量使用广播通信。比如：
- 设备配网（Smart Config）
- 状态同步（灯、开关）
- 固件升级通知
我帮朋友调试过一套智能灯系统，20个灯，总有3-4个不响应。抓包一看，广播包在AP侧就丢了。原因是AP的广播队列满了——嗯，很多家用路由器的广播队列只有几十个包。
IoT设备对广播丢包特别敏感，因为：
- 设备通常休眠，只在特定窗口监听
- 错过广播窗口，就得等下一轮（可能几秒甚至几分钟后）
- 没有重传机制，丢了就真丢了
1.4 广播丢包的核心原因（概览）
咱们先画个图，把广播丢包的根因理一理。后面章节会逐个深入。
这张图我画了好几次才满意。你看，广播丢包不是单一原因造成的。无线环境、协议本身、设备实现，三个维度互相影响。
我个人习惯把排查思路也按这个框架走：先看无线环境有没有干扰，再看协议层面有没有配置问题，最后查设备实现。顺序不能乱，否则容易走弯路。
经验之谈：我遇到过最坑的一次，是某品牌AP的广播队列深度只有16个包。环境里DHCP、ARP、NetBIOS一多，广播包直接溢出。换了个AP就好了。所以，有时候不是技术问题，是硬件抠门。
好了，这一章咱们把广播丢包的基本概念和影响范围理清了。后面的章节，我会逐个深入分析每个原因，并给出具体的排查和优化方法。