Foreword
本文是翻译，原文于此，结合我的实际使用略有改动
https://wyebot.com/2019/02/13/multicast-broadcast-traffic-worry-part1/
多播与广播介绍
多播和广播已经非常常见了，许多设备也会用多播或者广播来发布或者发现服务或者其他设备。类似家庭环境中使用的串流服务，像Bonjour、MDNS的协议，让流媒体传输变得更加简单了。但这样的简单是有代价的，当无线网络上有很多设备进行组播或者广播的时候，很容易引起网络阻塞。按理说基于现在的生成树协议等等手段，应该不至于，但是无线网络与有线网络对于组播和广播的处理并不相同，所以导致了这个问题。
详解多播与广播
在有线网络中，每个设备基本都是全双工连接到交换机的，差一点100M，好一点基本都是G口，有线连接不需要和其他设备分享带宽，基本每个人都相对独立，瓶颈一般都在交换机或者路由这里。但是WIFI就不一样了，他扮演的角色不像交换机，而是像一个HUB，所有连接到他的设备需要共享带宽，这里自然就是指无线带宽了。因此只要是使用同一个信道的设备，就一定会影响该信道的其他设备。这也是为啥经常2.4g的信道基本都卡爆，而5.8g就好一些，多数人都挤在一条路上，能不卡嘛。
多播与广播的处理
如果只是信道问题，那还好解决，大家避开就好了。但是在对于广播和多播帧的处理上实际也有所不同。首先是兼容性的问题，为了保证每个SSID的设备都能正常收到多播和广播数据，AP必须以兼容性的速率来发送这部分数据，而这个兼容速率来自于802.11a/b/g协议（1，2，5.5，6，9，11，12，18，24，36，48，56Mbps）。而我们当前运行的协议可能是802.11n或者ac，相比而言实在是太慢了。本身速率就低，占用的空中时间就够多了，他们还得额外占用更多的连接时间，而在WIFI环境中，就会导致其他设备可用带宽减少，增加了信道拥挤程度。而协议中对于这种情况又是必须得兼容的。
多播与广播的高优先级
这里需要提到另一个情况，如果有客户端此时处于省电状态，AP需要缓存多播和广播数据，直到符合发送的时机才能发送。和这里相关的就是DTIM，AP以DTIM的周期来发送多播和广播数据，而这部分数据相当于是一种突发性流量。与此同时，AP发送缓存数据时的优先级还是明显高于普通单播的数据的，这时会造成单播数据短暂阻塞。
接着之前说的速率问题，可以看到最高时54Mbps，如果任何时候都是以较高的速度发送的话就还好，但是实际上要兼顾各种客户端的信号质量的情况，WIFI速率和距离成反比，一旦有客户端信号比较差，那么为了保证他能收到，必须用最低的速度来发送。这个速率也可以通过AP设置来配置，但是总归是会选择尽可能满足更多的客户端的。
总而言之，广播和多播完成一些特定任务时非常简单，但是当网络条件不够好或者出现了许多测试时没遇到过的问题时，广播和多播可能并不能提升整体的稳定性，反而会带来坏处。
多播与广播的解
依然使用多播与广播，但是某些方法来缓解他带来的问题
- 将每个广播域限制得更小，不能解决本质问题，但是受影响的客户端更少而已
- 某些AP支持直接将多播转换成广播帧进行转发
- 强行提高多播速率
- 某些AP支持动态多播速率，而不是强行限制在某个值
- 动态信道宽度，这基本也必须AP和客户端同时支持，否则也很难弄
- 启用ARP代理，并且主动抑制ARP，ARP众所周知是广播大户
- 某些定制网关专门抑制这种广播或者多播流量的，需要AP支持
- 弃用WIFI，使用有线连接这些需要广播多播的客户端
- 禁用点对点通信，说白了不允许单播
没有完美的办法，这些方法多数会降低某方面的网络性能，但是提高最终的客户端的体验
Summary
无线网络终究还是脆弱一些，不能像有线那样瓶颈都在交换机这里。